| name | work-on-build |
| description | Build a Forge issue from Codex using Codex-native worktrees and Forge-aware subcommand routing. |
Forge Repo Adapter: work-on/build
Use commands/work-on/build.md as the authoritative build-phase workflow, with these Forge repo overrides:
- Default repo context is
RapierCraftStudios/forge.
- Rewrite any
.claude/worktrees/... path assumption to /home/mrdubey/projects/forge/.codex/worktrees/....
- Ensure
/home/mrdubey/projects/forge/.codex/worktrees exists before creating worktrees.
- Keep milestone/staging branch behavior from the shared workflow unless the issue explicitly says otherwise.
Subcommand Mapping
Use these adapters when the shared workflow invokes nested skills:
work-on:build:context -> installed forge-work-on-build-contextwork-on:build:architect -> installed forge-work-on-build-architectwork-on:build:implement -> installed forge-work-on-build-implementwork-on:build:validate -> repo-local .agents/skills/work-on/build/validate/SKILL.mdquality-gate -> repo-local .agents/skills/quality-gate/SKILL.md
Forge Repo Build Scope
For Forge issues, expected deliverables usually live in:
commands/**/*.md.agents/skills/**/*.mddocs/**/*.mdscripts/**/*.shinstall.sh, install-codex.sh, AGENTS.md, CLAUDE.md, CHANGELOG.md
Preserve the shared builder contract, context, architect, implement, and validate sequencing from commands/work-on/build.md. Only the repo defaults, worktree root, and nested-skill mapping change here.
Continuation Rule
Outputting BUILD_RESULT: does NOT terminate the pipeline. This result block is an intermediate signal for the work-on.md routing loop — not a final answer. After this subcommand completes, control returns to the routing loop in commands/work-on.md, which re-reads GitHub state and dispatches to the next phase (review). Do not treat the result block as a completion signal — the pipeline continues.
