Epic Dev

Epic Development Workflow

Codex entrypoint for the same phased epic workflow exposed to Claude Code as /epic-dev. Use workflow-reference for command snippets, state shape, and variation details, then follow this procedure as the execution contract.

Operating Rules

• Execute repository detection, GitHub lookups, worktree setup, tests, commits, PR creation, and cleanup directly when prerequisites are valid.
• Ask before strategic points only: epic plan approval, per-phase implementation plan approval, an accepted Critical finding that cannot be fixed within the phase, and final epic merge.
• When anything blocks progress, follow the project:engineering-loop skill's unblock-rules.md reference: every wait has a limit and a next action.
• Use absolute paths in shell commands. Do not rely on a previous cd.
• Track progress with the active planning tool when available.
• Do not use codex/ branch prefixes. Prefer feature/issue-{N}-..., patch/..., or chore/... per project rules.
• Do not use emojis in issues, PRs, commits, or generated state.
• Route models per agent-fanout. A Luna (max) driver orchestrates and delegates epic design, unresolved architecture, and high-risk invariants to Sol (xhigh); Luna (max) implements, reviews, and validates. Terra may elaborate an approved phase architecture.
• Semantic line breaks remain the default for prose source, except text posted to GitHub (issue and pull-request bodies, comments, reviews, and discussions). There, keep each paragraph and list item on one source line, separate paragraphs with blank lines, and do not insert sentence- or clause-level newlines inside a paragraph.

Phase 0: Repository Detection

1. Invoke the project-preflight skill's bundled <project-plugin-root>/bin/project-preflight --format json executable by absolute path from the target repository. Do not assume the plugin's bin/ directory is on PATH. This is a read-only startup probe for the repository, shell, terminal, GitHub CLI, and native-agent surface. It never spawns agents or prints credentials.
2. Validate required values before continuing:
   • INTEGRATION_BRANCH
   • REPO_ROOT
   • CURRENT_BRANCH
3. If preflight reports ERROR or a required field is empty, report the exact diagnostic and stop. Optional capability states (gh_*, native_agent_*) are diagnostics, not repository-detection failures.
4. Before a GitHub operation, require has_gh=true. If it is false, use the separate gh_command_status, gh_network_status, gh_auth_status, and gh_token_status fields to tell the user whether to install gh, repair network access, or run gh auth login; never collapse a network failure into a generic unauthenticated message. If gh_child_credential_status=mismatch, explain that the current shell and its child do not see the same credentials.
5. If the project requires sub-issue operations and gh-sub-issue is absent, install it with gh extension install agbiotech/gh-sub-issue after normal approval rules for networked commands.
6. Read existing state from .claude/epic.local.md if present. New Codex runs may continue using that file for compatibility with the Claude command.

Mode Parsing

Interpret the user request:

For resume modes, validate state fields before acting: epic_issue, epic_branch, integration_branch, phases, and current_phase.

Phase 1: Epic Setup

1. Gather the epic description and phase breakdown. Suggest phases when the user has not provided them, using the sizing rule in workflow-reference (one phase = one independently reviewable and testable PR, roughly one subsystem or up to ~500 net changed lines; if two candidate phases can only be tested together, they are one phase). If the description contains only one such unit, use the single-phase shortcut.

2. Present the plan for confirmation:

   textCopy code
   Epic: {title}
   Integration branch: {INTEGRATION_BRANCH}
   Epic branch: feature/issue-{N}-epic-{slug}
   
   Phases:
   1. {phase 1 title}
   2. {phase 2 title}
   
   Proceed?
   

3. After confirmation, create the epic issue, phase sub-issues, and links:

   • gh issue create --title "Epic: {title}" --label "feature"
   • gh issue create --title "Phase {X}: {title}" --label "feature"
   • gh sub-issue add {epic_issue} --sub-issue-number {phase_issue}

4. Create the epic worktree from the integration branch unless this is a single-phase feature.

5. Write .claude/epic.local.md using the format in workflow-reference.

6. Ensure .claude/*.local.md is ignored without overwriting existing .gitignore customizations.

For a single-phase feature, skip the epic worktree and sub-issues. Create one feature branch from the integration branch and target the integration branch directly.

Phase 2: Sprint Execution

For each phase, starting from the current state:

1. Create or reuse the phase worktree from the epic branch.

2. Mark the phase in_progress.

3. Have the lead define the phase architecture and open judgment calls. After approval, a Terra phase planner may expand it into exact files, decisions, tests, and gates. Ask for approval of the worker-executable plan.

4. Delegate implementation in the isolated phase worktree to a named Luna worker using the full lifecycle brief from agent-fanout. The lead does not hand over unresolved design choices.

5. Add focused tests for changed behavior and run the relevant verification.

6. Commit atomic changes with concise messages.

7. Push and create a PR targeting the epic branch:

   bashCopy code
   git -C "{phase_worktree}" push -u origin {phase_branch}
   gh pr create --base {epic_branch} --title "Phase {X}: {title}" --body "{body}"
   

8. Review the phase PR with pr-review-toolkit and follow its review-convergence.md reference: one full round, fixes committed on the phase branch (a large fix: one fix PR based on the phase branch), a delta round only if round 1 was substantial, no third round. Send security, concurrency, authorization, data-integrity, or architectural findings to Sol before fixing them.

9. Squash merge the phase PR when the convergence merge gate passes. Do not ask the user.

10. Update state, remove the phase worktree, close/remove completed one-off agent threads, and continue to the next phase.

Phase 3: Epic Finalization

1. Create the final PR from the epic branch to the integration branch.
2. Run project tests or the best available integration verification from the epic worktree.
3. Review the final PR with one integration-scoped reviewer (pr-review-toolkit): cross-phase integration only, not content the phase reviews covered; same two-round limit.
4. Present the final review summary and ask for merge approval.
5. Merge the final PR with a regular merge (--merge) to preserve per-phase history; only squash if the user explicitly asks.
6. Close the epic issue if GitHub did not close it automatically.
7. Remove the epic worktree.
8. Close/remove completed one-off agent threads, then archive or delete the local state file after confirming the workflow is complete.

Error Handling

• Detection failure: stop with the exact project-preflight error for missing repository fields; preserve the separate GitHub and optional-agent diagnostics for repair guidance.
• Git conflict: merge or rebase the base branch, resolve, and rerun gates. Ask the user only when a resolution needs a product decision.
• Test or CI failure: fix and rerun (two attempts), escalate to Sol with the log, then hand off with the failing command and output.
• GitHub API failure: retry twice; then show what was already created and ask whether to retry or abort.
• Merge failure: do not update state or clean up worktrees. Leave the phase marked in_progress.
• Dirty worktree cleanup: do not force-remove without explicit user approval.
• Corrupt state: show the invalid fields and ask whether to repair state or start a new epic.

References

• workflow-reference skill: branch strategy, state file format, worktree commands, GitHub commands, and variation handling.
• pr-review-toolkit skill: phase and final PR review before merge.