Dev Build

OpenClaw orchestrates via the exec tool and invokes the Codex and Claude CLIs directly. No ACP subagents, no announce-timeout. Each run is bounded by the exec tool's per-call timeoutSec.

Prompts are passed via heredoc on stdin — no prompt files to maintain, no shell escaping, no ARG_MAX concerns, safe for any content (code snippets, JSON blobs, quotes, $, backticks). The quoted <<'EOF' delimiter prevents shell expansion inside the prompt.

Verify CLI flags once against your installed versions — codex exec --help and claude --help. The skill assumes:

• Codex new session: codex exec
• Codex continuation: codex exec resume --last (fallback if --last is not supported: capture the session id printed by the initial run, then use codex exec resume <session-id>).
• Claude new session (print mode): claude -p
• Claude continuation: claude -p --continue (fallback: claude -p --resume <session-id>).

Codex builder / fixer / shipper — new session

exec(
  cwd="<repo>",
  timeoutSec=1800,
  command="""
codex exec \
  --dangerously-bypass-approvals-and-sandbox \
  <<'CODEX_EOF'
<builder prompt>
CODEX_EOF
"""
)

Codex continuation — follow-up work in the same project

exec(
  cwd="<repo>",
  timeoutSec=1800,
  command="""
codex exec resume --last \
  --dangerously-bypass-approvals-and-sandbox \
  <<'CODEX_EOF'
<next task prompt>
CODEX_EOF
"""
)

Claude reviewer — new session, per issue

exec(
  cwd="<repo>",
  timeoutSec=1200,
  command="""
claude -p \
  --dangerously-skip-permissions \
  <<'CLAUDE_EOF'
<reviewer prompt>
CLAUDE_EOF
"""
)

Claude continuation — if review is incomplete or asks to continue

exec(
  cwd="<repo>",
  timeoutSec=1200,
  command="""
claude -p --continue \
  --dangerously-skip-permissions \
  <<'CLAUDE_EOF'
Continue the review you started. Finish it in one run.
CLAUDE_EOF
"""
)

Output handling

The CLI exits non-zero on failure. The orchestrator parses stdout for the structured output contract — CHANGED_FILES / VERIFICATION / SUMMARY or FAILED_NO_CHANGES for Codex; OUTCOME / FINDINGS / SUMMARY for Claude. No separate status-polling step is needed — process exit is the completion signal.

Phase 0: Issue Selection

The caller provides the target project. This skill fetches and processes its issues.

1. Fetch Linear issues for the target project, sorted by priority. Skip issues that are Done, Cancelled, or Blocked.
2. If an issue depends on another issue that is not Done, skip it.
3. If no actionable issues exist, return to the caller with status clear.

Repo state check

The repo state check is done by Codex inside the CLI run, not by OpenClaw. Before changing files, Codex must run and report:

git branch --show-current
git status --short
git log --oneline -5

• Night builds work on the repo default branch (main). Do not create night/, feature/, or dev branches.
• If on a non-default branch, switch back when safe. If ambiguous branch-local work exists, block.
• If dirty, check whether the changes relate to a prior issue in the same project (check night memory and recent git log). If they do, continue on top of them. If the changes are unrelated or you cannot determine their origin, block.
• Lock files (pnpm-lock.yaml, package-lock.json, Cargo.lock, etc.) are not blockers. Stage and include them if they result from dependency changes.
• If dirty with the current issue's in-progress work, resume.

If the repo is unsafe to continue, Codex must stop without editing and return FAILED_NO_CHANGES: <exact blocker>.

Phase 1: Build (TDD)

Run the Codex CLI for the project. For the first issue in a project use codex exec (new session). For follow-up issues in the same project, use codex exec resume --last so Codex retains codebase context from the previous issue. Capture any session id printed by the CLI — it's the fallback if --last is not supported or the most-recent-session pointer gets lost.

Session continuation is scoped to the current project only. When the caller moves to a different project, start a fresh codex exec (new session) in the new repo. Do not carry a session from one project's repo into another.

When continuing a session for a follow-up issue, instruct Codex to run /compact before starting any new work to free up context from the previous issue.

If continuation fails (the CLI reports no session to resume, or the prior session id is invalid), fall back to a fresh codex exec call and instruct Codex to read the repo's AGENTS.md and explore the codebase structure before making any changes.

Orchestrator pre-work

Before spawning Codex, prepare a concrete brief:

1. Read the issue description, acceptance criteria, implementation notes, relevant comments, and any linked design docs.
2. Read the project's CLAUDE.md (or AGENTS.md / .agents/) for conventions and commands. Codex auto-reads AGENTS.md and .agents/ from the repo root, so do not repeat their content in the builder prompt.
3. Find design docs or implementation plans linked in the issue or in the repo's docs/ directory. Include the path in the builder prompt if found.
4. If existing interfaces, types, or stubs are relevant, include them as reference. For new implementations where files don't exist yet, skip this.
5. Identify the gate commands (from project config or PROJECTS.yaml).

Builder prompt

The Linear issue contains the implementation instructions. Pass them to Codex verbatim with this structure:

You are the Codex builder for <issue-id>: <issue-title>.

Repo: <cwd>
Branch: stay on the repo default branch. Do not create or switch branches.
Do not commit or push yet — you will be told to ship after review passes.

## Task

<issue description, acceptance criteria, implementation notes, and relevant
Linear comments pasted verbatim>

## References

<design doc or implementation plan path, if available>
<relevant interfaces/types/stubs from the codebase, if they exist>

## Approach

First, run the repo state check:
- git branch --show-current
- git status --short
- git log --oneline -5

If the repo is on the wrong branch or dirty with unrelated/ambiguous work, stop
without editing and return FAILED_NO_CHANGES with the exact blocker.

Before writing any code, read the repo's AGENTS.md (or CLAUDE.md) and explore
the codebase to understand the existing architecture, module boundaries, and
how similar features are wired together. Understand where your changes need to
integrate before you start implementing.

Deliver a complete, integrated feature — not just isolated code. Wire your
implementation into the rest of the system: update callers, register routes,
add exports, connect config, and update any entry points so the feature is
actually reachable and functional without manual follow-up.

Prefer tests first: write or update the failing test that proves the requested
behavior, then implement until the tests pass. If the repo already has a test
pattern, follow it. If tests-first is not practical, explain why in the final
summary and still add appropriate coverage before finishing.

## Gate

Run before finishing. Include formatting, linting, tests, and any full gate
configured for this project:
<gate commands from project config>

## Output

End with exactly one of:

CHANGED_FILES:
- <path>

SUMMARY:
<what you did>

VERIFICATION:
- <command>: <pass/fail and key output>
- git status --short: <output>
- git diff --name-only: <output>