arch-epic
After explicit selection, wraps $arch-step to execute a multi-plan goal.
Filing or decomposing GitHub issues does not select this lifecycle.
The skill takes a prose goal, proposes a plain-English decomposition
whose count follows proof gates rather than a preset range, gets user approval, and then drives
each sub-plan through arch-step's new → auto-plan → implement-loop
→ audit-implementation arc. After each sub-plan completes, a new clean
critic child inspects the shipped work for scope
drift against the approved North Star. If the critic finds missing authorized
work, post-approval proposed expansion, or unauthorized built scope, the skill
halts. It may resume ordinary missing work, but it never enlarges scope from
the critic. A human decides whether to approve expansion and re-approve, or keep
the boundary and require subtraction/redesign.
Otherwise it advances to the next sub-plan.
The normal lane is interactive and re-entrant: arch-epic invokes or observes
arch-step commands in the visible session one transition at a time.
The same-session automatic commands are explicit and opt-in:
auto-plan is a strict sequential driver over real $arch-step auto-plan <SUBPLAN_DOC_PATH> runs. It handles one approved sub-plan at a time, requires
the generated ArcStep receipt gate to report ready for that exact DOC_PATH, and
only then marks the sub-plan planned before moving to the next one.
auto-implement is a strict sequential driver over real $arch-step auto-implement <SUBPLAN_DOC_PATH> runs. It handles one planned sub-plan at a
time, lets ArcStep own the full implement/prove/audit loop, runs the epic
critic only after ArcStep's implementation audit says Verdict (code): COMPLETE, and marks the sub-plan complete only after that critic passes.
Role-based automatic execution is transport-aware. After decomposition
approval, arch-epic drives epic_planner, implementation_worker, and
critic roles from durable epic/sub-plan artifacts. Same-host roles normally
start as clean native children. The external-harness lane remains explicit and
opt-in when a different provider, load-bearing exact model/profile, durable or
detached lifecycle, worktree/process isolation, automation surface, structured
receipt, or another real benefit is worth the added process cost. In that lane
the existing script resolves and pins the external role table and owns only
invocation and receipt mechanics. Workers apply arch-step doctrine directly
from disk; they do not invoke nested auto-plan, implement-loop, or other
automatic continuation commands.
Planner and implementation worker roles are resumable regardless of transport.
If a new clean critic finds in-scope unfinished work, arch-epic resumes the
exact planner or implementation worker with the critic's observation and
artifact evidence. The critic never prescribes repair steps, and ordinary
repair does not start a separate repair-worker role.
Progressive lazy planning is the default for interactive and role-based
work: sub-plan N+1 is not planned until sub-plan N is complete. Same-session
auto-plan is the deliberate exception: it plans all approved sub-plans first,
but still plans exactly one sub-plan at a time and stops before implementation.
The user approves the decomposition up front, then approves each sub-plan's
North Star when it comes up in interactive mode. In role-based automatic mode,
new clean critics check North Star and Epic Requirement Coverage gates instead of
asking the user on every sub-plan.
Resume is the only mode — every $arch-epic invocation re-reads the
epic doc and sub-plan docs from disk and picks up where things left
off. "Continue my epic", "pick up where we left off", "keep going on
" all work.
The skill is a thoughtful wrapper — its job is to reduce user
orchestration burden. In interactive mode, user involvement is bounded
to the goal, decomposition, per-sub-plan North Star, and material
scope-preservation decisions. In role-based automatic mode, the user approves
the decomposition up front; an external harness also pins its role table.
Clean critics replace
per-sub-plan North-Star pauses unless a material ambiguity or scope
change requires the user.
When to use
- "This is too big for one arch-step plan. Help me break it into plans
and run them in order."
- "Orchestrate these sub-plans: X, Y, Z. Check each one before moving
to the next."
- "Continue my epic at
docs/EPIC_<slug>_<date>.md."
- "Keep going on the epic."
- "Pick up where we left off on ."
- "Automatically implement this approved epic end to end."
- "Auto-plan every sub-plan before we implement any of them."
- "Run
arch-epic auto-implement on this approved epic."
- "Run the epic automatically and ask me which models to use for the
planner, implementation worker, and critics."
When not to use
- Single architecture plan, including single-plan automatic planning through
implementation: use
$arch-step full-auto or $miniarch-step full-auto.
- One-pass mini plan that hands off to implement: use
$arch-mini-plan.
- 1–3 phase feature flow: use
$lilarch.
- Open-ended optimization with bet-and-learn iteration: use native goal mode.
- Read-only routing across arch artifacts: use
$arch-flow.
- Stepped orchestration in a foreign repo with a per-step critic: use
$stepwise.
- One-shot review of a diff, branch, or completion claim: use ordinary host
review. Use
$codex-review-yolo only when the exact external yolo profile
and its receipts are the requested benefit.
- Work that fits in a single orchestrator turn.
Non-negotiables
Must happen every run:
- Pin
raw_goal verbatim with sha256 in the epic doc. Any silent
rewrite clears the decomposition-approved flag.
- Produce a one-sentence-per-sub-plan decomposition and get user
approval before planning any sub-plan.
- Treat the raw human goal and approved decomposition as the epic baseline.
Decomposition approval does not authorize hidden infrastructure in later
sub-plans. Apply
../_shared/scope-and-convergence.md.
- Apply
../_shared/agent-orchestration-policy.md whenever a planner,
worker, or critic is dispatched, and apply $prompt-authoring to every
actual populated first brief or materially reframed follow-up. Prefer a clean
native child for ordinary same-host work. Use the explicit external harness
when a concrete provider, exact model/profile, durable or detached lifecycle,
worktree/process isolation, automation surface, structured receipt, or
another real benefit is worth the added process and integration cost. These
examples are recognition aids, not an allowlist.
- Native starting context is explicit. Codex dispatch always sets
fork_turns to "none" for clean planner/worker/critic roles, to a positive
count only for deliberately bounded chat context, or to "all" only when
the full conversation is genuinely required. Claude uses a clean named
subagent by default; an explicit conversation fork means full inherited
conversation, while a skill with context: fork is an isolated clean
subagent context. Context is separate from permissions, capabilities, and
worktree isolation.
- The parent owns sequencing, external topology, and final integration.
Planner, worker, and critic prompts allow each role its own native sub-agents
on its own host and forbid starting external agents.
- Each sub-plan inherits its approved epic boundary, records its own initial
minimal convergence closure during initial architecture, and signs off that
closure before implementation. After sign-off, only explicit human approval
may add a path, obligation, sub-plan, mechanism, or proof category.
- Each sub-plan is its own full
$arch-step canonical DOC_PATH.
The epic doc does NOT contain plan internals (no Sections 0–10,
no call-site audit).
- Progressive planning: in interactive and role-based automatic modes, invoke
$arch-step new or planner harness work for sub-plan N+1 only after sub-plan
N is complete per the epic critic. In same-session auto-plan, assign or
create only the scaffold needed for the next sub-plan's canonical DOC_PATH,
then invoke or continue the real $arch-step auto-plan <SUBPLAN_DOC_PATH>
flow for that exact DOC_PATH. Creation, scaffold repair, copied sections, or
marker-looking text are never readiness proof.
- In same-session
auto-plan, update a sub-plan Status to planned only after
python3 skills/arch-step/scripts/arch_stage_gate.py ready --doc <SUBPLAN_DOC_PATH> exits 0 for that exact DOC_PATH. If the gate is not ready,
keep or set the sub-plan to planning and continue or report the exact
$arch-step auto-plan <SUBPLAN_DOC_PATH> command.
- Per-sub-plan North Star approval uses
$arch-step's existing
North-Star gate. arch-epic does not re-invent it — it just
stops when arch-step stops. In role-based automatic mode, this gate is
replaced by a new clean North-Star critic after the user-approved
decomposition is pinned. An external harness also pins its role table. In
same-session auto-plan, the
approved decomposition can stand in for per-sub-plan user approval only when
the sub-plan North Star is a direct, unambiguous expansion of the approved
epic scope; otherwise stop and ask.
- Per-sub-plan implementation runs through
$arch-step implement-loop in interactive mode and real $arch-step auto-implement <SUBPLAN_DOC_PATH> in same-session auto-implement.
Same-session auto-implement is not complete after one invocation; it keeps
the selected sub-plan at implementing and continues the ArcStep
implement/prove/audit loop until arch_skill:block:implementation_audit says
Verdict (code): COMPLETE or a true blocker stops progress. In
role-based automatic mode, implementation workers execute the approved
sub-plan directly from arch-step doctrine and the sub-plan doc; the top-level
orchestrator still does not edit target code itself.
- Epic critic runs once per sub-plan at sub-plan completion and returns
structured JSON
EpicVerdict. It is always a new clean child and is never
resumed. Prefer native dispatch; the external harness remains available for
deliberate external benefits.
- Permissions and worktree posture are resolved independently from starting
context. Use enforced read-only capability for critics when available,
retain the no-edit prompt contract, and compare repository state before and
after critic work. External harness processes keep the existing dangerous /
skip-permissions / no-sandbox convention; that convention does not describe
native children.
- Native role execution needs no invented runtime/model promise. For the
explicit external harness, the user supplies role execution for
epic_planner, implementation_worker, and critic; ask once for missing
load-bearing values. An omitted model on an external Codex role defaults to
gpt-6-astra, and an omitted effort on that Astra role defaults to xhigh.
An external Kimi role defaults to kimi-code/k3 and the model-default max
effort; other runtimes, Codex models, and efforts never silently default.
Natural Grok wording resolves to grok-4.6, while explicitly named legacy
Grok ids remain exact. Existing external
policies with legacy repair_worker values may load, but ordinary critic
failures resume the exact original planner or implementation worker.
Same-session auto-plan needs no role table. Same-session
auto-implement uses the same transport-selected completion-critic policy
as interactive mode.
- Resume is re-entrant: any invocation against an existing epic doc
re-reads on-disk state and continues. No dedicated
resume
command.
Must never happen:
arch-epic editing the target repo's code directly. Sub-plans do that via
arch-step's implement-loop in interactive mode or implementation workers in
role-based automatic mode.
- Scope reduction. The epic scope is the epic scope. If the critic
sees a dropped, narrowed, or silently removed requirement from the raw
goal, approved Decomposition, North Star, Epic Requirement Coverage,
Section 7, acceptance criteria, or verification obligations, the
sub-plan fails. A requirement assigned to a named later sub-plan is
preserved scope, not a failure for the current sub-plan. Agent-written
Decision Log entries are evidence, not approval to reduce scope.
- Scope expansion by an agent, critic, review, or Decision Log. The same
symmetry applies to additions: initial sub-plan architecture may record the
smallest evidenced same-contract closure before sign-off; any later addition
or new sub-plan needs explicit human approval. A Decision Log entry proves a
change was recorded, not that it was authorized.
- Auto-acting on materially-different-path detections without user approval.
Material scope discoveries always halt. The human may approve expansion via
extend_current or new_sub_plan, or keep the approved boundary and require
subtraction/redesign. No critic recommendation is self-authorizing.
- Letting critics author repair steps. Critics report verdict,
failed checks, evidence, and scope discoveries only. The parent
routes the result, and the resumed planner or implementation worker
owns the reasoning for the next attempt.
- Starting a separate repair worker for ordinary in-scope critic failures.
Exact-role resume is the default repair path; a new clean role child is only
for unrecoverable handle loss, invalidated inputs, or explicit user override.
- Parallel planning or parallel implementation. Same-session
auto-plan may
plan every sub-plan before implementation, but it still handles one sub-plan
at a time in decomposition order. Implementation always runs one sub-plan at
a time and advances only after the epic critic passes.
- Marking a same-session
auto-plan sub-plan planned from a consistency
marker, plausible Section 3-7 content, prior stored status, or ArcEpic-authored
setup. The ArcStep generated receipt gate is the proof.
- Same-session
auto-implement starting while any non-complete sub-plan is not
planned. Plan all sub-plans first with auto-plan.
- Marking a same-session
auto-implement sub-plan complete from stored
Status, worklog optimism, local proof, one $arch-step auto-implement
invocation, or ArcStep audit alone. ArcStep audit COMPLETE must come first,
then the epic critic must return pass.
- Running the epic critic while the sub-plan implementation audit is missing,
NOT COMPLETE, reopened, or otherwise not clean. Continue or report
$arch-step auto-implement <SUBPLAN_DOC_PATH> for that sub-plan instead.
- Two-second child polling. The external-harness lane defaults to 180-second waits
while waiting for external processes unless the user explicitly pins a
different cadence in the role policy.
- Calling a slow planner or worker "hung" just because it has no final
artifact after a few minutes. Native host state or external stream receipts
may show progress; external children often run for 5+ minutes;
broad
xhigh or max planner/worker runs can reasonably take 20-40
minutes. In the external lane use process state plus events.jsonl, stderr.log,
stream.log, heartbeat.json, and monitor.json; treat recent
thinking/tool/output stream activity as progress.
- Terminating an external child before the long-run floors expire unless there
is clear failure evidence. External defaults are: poll every 180s,
call a run
quiet only after 900s without stream activity, and call
it needs_attention only after 1800s without stream activity or after
the pinned max runtime.
- Passing raw model shorthand to external subprocesses. Resolve it first using
shared model-resolution doctrine; preserve exact family/version or
ask for the runnable ID.
- Heuristic keyword mapping for decomposition. Interpretation is
prose reasoning, taught by
references/decomposition-principles.md.
- A second "resume" command. The user types what they type; the
skill figures it out from the epic doc + sub-plan docs.
First move
- Capture the user's goal verbatim. Compute
sha256.
- Resolve or propose the epic doc path
(
docs/EPIC_<TITLE>_<YYYY-MM-DD>.md).
- Read
../_shared/agent-orchestration-policy.md and
references/model-and-effort.md. Prefer clean native same-host roles. Ask
one consolidated question only when an explicit external harness or another
selected external lane lacks load-bearing execution values. Same-session
auto-plan runs no critic during planning.
- Read
references/decomposition-principles.md. Draft the
Decomposition (one-sentence descriptions, assertion-style gates,
dependency-then-risk ordering, and count chosen from real proof
boundaries rather than a target range).
- Read
../_shared/scope-and-convergence.md.
- Read
references/epic-doc-contract.md. Write the epic doc.
- Surface the Decomposition and ask the user to approve or adjust.
Modes (re-entrant; one per turn)
Detail per mode lives in references/workflow-contract.md.
start — epic doc does not yet exist. Propose the path, resolve the
intended lane without inventing native model settings, ask only for missing
external values when an external lane was selected, draft the Decomposition,
and surface it for approval.
approve-decomposition — epic doc has
sub_plans_approved: false. Apply user adjustments, flip flag,
set status: active.
run — main orchestration pass. Routes per
references/arch-step-integration.md to the next arch-step
command for the first non-complete sub-plan or runs the critic.
resume-scope-change — epic is halted after a critic flagged a
scope issue; a human has replied. Apply the explicit choice: approve and
re-approve an extend_current/new_sub_plan expansion, or keep scope and
route subtraction/redesign. Log the human decision and resume.
summary — user asked a status question. Render a table of
sub-plan statuses and the most recent log entries. No state
changes.
auto-plan — same-session planning driver after decomposition
approval. Sets up the next sub-plan DOC_PATH, drives real $arch-step auto-plan <SUBPLAN_DOC_PATH> for that exact doc, runs the ArcStep readiness
gate, marks it planned only when the gate exits 0, then repeats for the
next sub-plan in decomposition order. It stops before implementation.
auto-implement — same-session implementation driver. Requires every
non-complete sub-plan to be planned, then runs each in order through real
$arch-step auto-implement <SUBPLAN_DOC_PATH> until ArcStep audit is
COMPLETE, runs the epic critic, and marks the sub-plan complete only after
critic pass.
auto-run — role-based automatic execution after decomposition
approval. Prefer clean native planner/worker/critic children from durable
artifacts, resume the exact planner or worker for repair, and start every
critic clean. If the external harness was deliberately selected, resolve
and pin its role table, initialize its auto run directory, and use the
script only for external invocation and receipts.
Output expectations
- Epic doc at the user-named (or proposed) path.
- Per-sub-plan canonical arch-step DOC_PATHs under
docs/epic/<EPIC_SLUG_WITH_DATE>/PHASE_<NN>_<SUBPLAN_SLUG>_<YYYY-MM-DD>.md,
owned by arch-step.
- Same-session
auto-plan leaves non-complete sub-plans at Status planned
only when their exact DOC_PATH passes the arch-step generated receipt gate.
- Native role dispatches record their exact child handles and return evidence
as compact Orchestration Log pointers. External epic critic artifacts live under
<orchestrator repo root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/
including the EpicVerdict JSON, the exact invocation.sh, and the
subprocess stream log.
- External-harness automatic artifacts live under
<orchestrator repo root>/.arch_skill/arch-epic/auto/<epic-slug>/run-<ts>/
including state.json, execution_policy.json, worker prompts,
worker session IDs, latest worker-attempt pointers, critic verdicts, child events.jsonl,
stderr.log, stream.log, heartbeat.json, monitor.json, and
report.md.
- Orchestration Log and Decision Log append-only in the epic doc.
- Console summary with the epic doc path, the per-sub-plan status
table, and the current active sub-plan's next action.
Reference map
references/workflow-contract.md — re-entrant modes with inputs,
outputs, failure modes, judgment-vs-determinism split.
references/epic-doc-contract.md — epic doc shape, frontmatter,
section structure, mutation rules, validation on load.
references/decomposition-principles.md — when to split a goal
into sub-plans. Prose reasoning with worked examples; no keyword
tables.
../_shared/depth-first-planning.md — destination map, first
working slice, expansion map, proof gates, and scope-cut distinction
shared with arch-step and miniarch-step.
references/arch-step-integration.md — sub-plan Status →
arch-step command mapping. What the skill invokes vs. what the
user or native goal-mode continuation does.
references/scope-change-discipline.md — approved scope lock,
materially-different path vs noise, and preservation-only scope
decisions.
references/critic-contract.md — EpicVerdict JSON schema and
scope-drift / requirement-coverage checks.
references/critic-prompt.md — verbatim critic prompt body with
placeholders.
references/auto-harness-prompts.md — transport-neutral role prompt
contracts for planner, implementation, exact-role continuation, and clean
critics.
references/epic-verdict-schema.json — JSON schema file used by
Codex --output-schema, inlined into Claude --json-schema, and appended
to Grok and Kimi critic prompts before post-validation.
references/model-and-effort.md — native-first role dispatch plus external
model shorthand resolution, exact-version preservation, and ask-once
discipline.
references/resume-semantics.md — how the skill re-derives state
each turn from the epic doc + sub-plan docs.
references/examples.md — worked examples: happy path,
scope-change insertion, harmless observations ignored.
The external harness adapter
scripts/run_arch_epic.py is deterministic external-lane plumbing. After the
orchestrator deliberately selects the external harness, it resolves the
external role policy, creates run directories, spawns and resumes workers,
spawns structured critics, and writes artifacts. It does NOT choose transport,
interpret decomposition, draft the epic doc, decide verdicts, or route
sub-plan states — those live in the orchestrator's prose reasoning.
python3 scripts/run_arch_epic.py critic-spawn \
--epic-doc <path> \
--sub-plan-name "<name>" \
--sub-plan-doc-path <path> \
--prompt-file <path> \
--schema-file references/epic-verdict-schema.json \
--runtime claude|codex|grok|kimi \
--model <model> \
--effort <effort> \
[--codex-profile <profile>] \
[--orchestrator-root <dir>]
External-harness examples:
python3 scripts/run_arch_epic.py resolve-execution \
--policy-file /tmp/arch-epic-auto-policy.json
python3 scripts/run_arch_epic.py auto-init \
--epic-doc docs/EPIC_BIG_GOAL_2026-04-26.md \
--policy-file /tmp/arch-epic-auto-policy.json
python3 scripts/run_arch_epic.py worker-spawn \
--run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \
--target-repo . \
--role implementation_worker \
--sub-plan-name "Build the core service" \
--prompt-file /tmp/worker.prompt.md \
--run-mode auto
python3 scripts/run_arch_epic.py worker-resume \
--run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \
--target-repo . \
--role implementation_worker \
--sub-plan-name "Build the core service" \
--prompt-file /tmp/continue.prompt.md \
--session-id <session-id-from-session_id.txt> \
--try-k 2 \
--run-mode auto
python3 scripts/run_arch_epic.py child-status \
--try-dir <printed-child-run-dir> \
--json
python3 scripts/run_arch_epic.py child-tail \
--try-dir <printed-child-run-dir> \
--lines 80
python3 scripts/run_arch_epic.py child-finalize \
--try-dir <printed-child-run-dir>
Foreground child runs print the session ID or verdict path after completion.
Detached child runs print the child run directory immediately; use
child-status, child-tail, and child-finalize to monitor and finalize
them. Writes:
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/prompt.md
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/invocation.sh
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stdout.final.json
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/events.jsonl
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stderr.log
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stream.log
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/heartbeat.json
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/monitor.json
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/verdict.json
<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/start_ts / end_ts / exit_code
1---2name: arch-epic3description: "Explicitly selected multi-plan execution lifecycle: decompose an authorized goal into approved ordered arch-step sub-plans, then plan, implement, and review them. Use when the user chooses $arch-epic or binding task instructions require it. Filing or decomposing GitHub issues, mentioning an epic, or asking for status does not select execution."4metadata:5 short-description: "Multi-plan orchestrator wrapping arch-step with decomposition approval, progressive North-Star gates, and a per-sub-plan scope-drift critic"6---78# arch-epic910After explicit selection, wraps `$arch-step` to execute a multi-plan goal.11Filing or decomposing GitHub issues does not select this lifecycle.12The skill takes a prose goal, proposes a plain-English decomposition13whose count follows proof gates rather than a preset range, gets user approval, and then drives14each sub-plan through arch-step's `new` → `auto-plan` → `implement-loop`15→ `audit-implementation` arc. After each sub-plan completes, a new clean16critic child inspects the shipped work for scope17drift against the approved North Star. If the critic finds missing authorized18work, post-approval proposed expansion, or unauthorized built scope, the skill19halts. It may resume ordinary missing work, but it never enlarges scope from20the critic. A human decides whether to approve expansion and re-approve, or keep21the boundary and require subtraction/redesign.22Otherwise it advances to the next sub-plan.2324The normal lane is interactive and re-entrant: arch-epic invokes or observes25arch-step commands in the visible session one transition at a time.2627The same-session automatic commands are explicit and opt-in:28`auto-plan` is a strict sequential driver over real `$arch-step auto-plan29<SUBPLAN_DOC_PATH>` runs. It handles one approved sub-plan at a time, requires30the generated ArcStep receipt gate to report ready for that exact DOC_PATH, and31only then marks the sub-plan `planned` before moving to the next one.32`auto-implement` is a strict sequential driver over real `$arch-step33auto-implement <SUBPLAN_DOC_PATH>` runs. It handles one planned sub-plan at a34time, lets ArcStep own the full implement/prove/audit loop, runs the epic35critic only after ArcStep's implementation audit says `Verdict (code):36COMPLETE`, and marks the sub-plan `complete` only after that critic passes.3738Role-based automatic execution is transport-aware. After decomposition39approval, arch-epic drives `epic_planner`, `implementation_worker`, and40`critic` roles from durable epic/sub-plan artifacts. Same-host roles normally41start as clean native children. The external-harness lane remains explicit and42opt-in when a different provider, load-bearing exact model/profile, durable or43detached lifecycle, worktree/process isolation, automation surface, structured44receipt, or another real benefit is worth the added process cost. In that lane45the existing script resolves and pins the external role table and owns only46invocation and receipt mechanics. Workers apply arch-step doctrine directly47from disk; they do not invoke nested `auto-plan`, `implement-loop`, or other48automatic continuation commands.4950Planner and implementation worker roles are resumable regardless of transport.51If a new clean critic finds in-scope unfinished work, arch-epic resumes the52exact planner or implementation worker with the critic's observation and53artifact evidence. The critic never prescribes repair steps, and ordinary54repair does not start a separate repair-worker role.5556Progressive lazy planning is the default for interactive and role-based57work: sub-plan N+1 is not planned until sub-plan N is complete. Same-session58`auto-plan` is the deliberate exception: it plans all approved sub-plans first,59but still plans exactly one sub-plan at a time and stops before implementation.60The user approves the decomposition up front, then approves each sub-plan's61North Star when it comes up in interactive mode. In role-based automatic mode,62new clean critics check North Star and Epic Requirement Coverage gates instead of63asking the user on every sub-plan.6465Resume is the only mode — every `$arch-epic` invocation re-reads the66epic doc and sub-plan docs from disk and picks up where things left67off. "Continue my epic", "pick up where we left off", "keep going on68<project>" all work.6970The skill is a thoughtful wrapper — its job is to reduce user71orchestration burden. In interactive mode, user involvement is bounded72to the goal, decomposition, per-sub-plan North Star, and material73scope-preservation decisions. In role-based automatic mode, the user approves74the decomposition up front; an external harness also pins its role table.75Clean critics replace76per-sub-plan North-Star pauses unless a material ambiguity or scope77change requires the user.7879## When to use8081- "This is too big for one arch-step plan. Help me break it into plans82 and run them in order."83- "Orchestrate these sub-plans: X, Y, Z. Check each one before moving84 to the next."85- "Continue my epic at `docs/EPIC_<slug>_<date>.md`."86- "Keep going on the <goal> epic."87- "Pick up where we left off on <project>."88- "Automatically implement this approved epic end to end."89- "Auto-plan every sub-plan before we implement any of them."90- "Run `arch-epic auto-implement` on this approved epic."91- "Run the epic automatically and ask me which models to use for the92 planner, implementation worker, and critics."9394## When not to use9596- Single architecture plan, including single-plan automatic planning through97 implementation: use `$arch-step full-auto` or `$miniarch-step full-auto`.98- One-pass mini plan that hands off to implement: use `$arch-mini-plan`.99- 1–3 phase feature flow: use `$lilarch`.100- Open-ended optimization with bet-and-learn iteration: use native goal mode.101- Read-only routing across arch artifacts: use `$arch-flow`.102- Stepped orchestration in a foreign repo with a per-step critic: use103 `$stepwise`.104- One-shot review of a diff, branch, or completion claim: use ordinary host105 review. Use `$codex-review-yolo` only when the exact external `yolo` profile106 and its receipts are the requested benefit.107- Work that fits in a single orchestrator turn.108109## Non-negotiables110111Must happen every run:112- Pin `raw_goal` verbatim with `sha256` in the epic doc. Any silent113 rewrite clears the decomposition-approved flag.114- Produce a one-sentence-per-sub-plan decomposition and get user115 approval before planning any sub-plan.116- Treat the raw human goal and approved decomposition as the epic baseline.117 Decomposition approval does not authorize hidden infrastructure in later118 sub-plans. Apply `../_shared/scope-and-convergence.md`.119- Apply `../_shared/agent-orchestration-policy.md` whenever a planner,120 worker, or critic is dispatched, and apply `$prompt-authoring` to every121 actual populated first brief or materially reframed follow-up. Prefer a clean122 native child for ordinary same-host work. Use the explicit external harness123 when a concrete provider, exact model/profile, durable or detached lifecycle,124 worktree/process isolation, automation surface, structured receipt, or125 another real benefit is worth the added process and integration cost. These126 examples are recognition aids, not an allowlist.127- Native starting context is explicit. Codex dispatch always sets128 `fork_turns` to `"none"` for clean planner/worker/critic roles, to a positive129 count only for deliberately bounded chat context, or to `"all"` only when130 the full conversation is genuinely required. Claude uses a clean named131 subagent by default; an explicit conversation fork means full inherited132 conversation, while a skill with `context: fork` is an isolated clean133 subagent context. Context is separate from permissions, capabilities, and134 worktree isolation.135- The parent owns sequencing, external topology, and final integration.136 Planner, worker, and critic prompts allow each role its own native sub-agents137 on its own host and forbid starting external agents.138- Each sub-plan inherits its approved epic boundary, records its own initial139 minimal convergence closure during initial architecture, and signs off that140 closure before implementation. After sign-off, only explicit human approval141 may add a path, obligation, sub-plan, mechanism, or proof category.142- Each sub-plan is its own full `$arch-step` canonical DOC_PATH.143 The epic doc does NOT contain plan internals (no Sections 0–10,144 no call-site audit).145- Progressive planning: in interactive and role-based automatic modes, invoke146 `$arch-step new` or planner harness work for sub-plan N+1 only after sub-plan147 N is `complete` per the epic critic. In same-session `auto-plan`, assign or148 create only the scaffold needed for the next sub-plan's canonical DOC_PATH,149 then invoke or continue the real `$arch-step auto-plan <SUBPLAN_DOC_PATH>`150 flow for that exact DOC_PATH. Creation, scaffold repair, copied sections, or151 marker-looking text are never readiness proof.152- In same-session `auto-plan`, update a sub-plan Status to `planned` only after153 `python3 skills/arch-step/scripts/arch_stage_gate.py ready --doc154 <SUBPLAN_DOC_PATH>` exits 0 for that exact DOC_PATH. If the gate is not ready,155 keep or set the sub-plan to `planning` and continue or report the exact156 `$arch-step auto-plan <SUBPLAN_DOC_PATH>` command.157- Per-sub-plan North Star approval uses `$arch-step`'s existing158 North-Star gate. `arch-epic` does not re-invent it — it just159 stops when arch-step stops. In role-based automatic mode, this gate is160 replaced by a new clean North-Star critic after the user-approved161 decomposition is pinned. An external harness also pins its role table. In162 same-session `auto-plan`, the163 approved decomposition can stand in for per-sub-plan user approval only when164 the sub-plan North Star is a direct, unambiguous expansion of the approved165 epic scope; otherwise stop and ask.166- Per-sub-plan implementation runs through167 `$arch-step implement-loop` in interactive mode and real `$arch-step168 auto-implement <SUBPLAN_DOC_PATH>` in same-session `auto-implement`.169 Same-session `auto-implement` is not complete after one invocation; it keeps170 the selected sub-plan at `implementing` and continues the ArcStep171 implement/prove/audit loop until `arch_skill:block:implementation_audit` says172 `Verdict (code): COMPLETE` or a true blocker stops progress. In173 role-based automatic mode, implementation workers execute the approved174 sub-plan directly from arch-step doctrine and the sub-plan doc; the top-level175 orchestrator still does not edit target code itself.176- Epic critic runs once per sub-plan at sub-plan completion and returns177 structured JSON `EpicVerdict`. It is always a new clean child and is never178 resumed. Prefer native dispatch; the external harness remains available for179 deliberate external benefits.180- Permissions and worktree posture are resolved independently from starting181 context. Use enforced read-only capability for critics when available,182 retain the no-edit prompt contract, and compare repository state before and183 after critic work. External harness processes keep the existing dangerous /184 skip-permissions / no-sandbox convention; that convention does not describe185 native children.186- Native role execution needs no invented runtime/model promise. For the187 explicit external harness, the user supplies role execution for188 `epic_planner`, `implementation_worker`, and `critic`; ask once for missing189 load-bearing values. An omitted model on an external Codex role defaults to190 `gpt-6-astra`, and an omitted effort on that Astra role defaults to `xhigh`.191 An external Kimi role defaults to `kimi-code/k3` and the model-default `max`192 effort; other runtimes, Codex models, and efforts never silently default.193 Natural Grok wording resolves to `grok-4.6`, while explicitly named legacy194 Grok ids remain exact. Existing external195 policies with legacy `repair_worker` values may load, but ordinary critic196 failures resume the exact original planner or implementation worker.197 Same-session `auto-plan` needs no role table. Same-session198 `auto-implement` uses the same transport-selected completion-critic policy199 as interactive mode.200- Resume is re-entrant: any invocation against an existing epic doc201 re-reads on-disk state and continues. No dedicated `resume`202 command.203204Must never happen:205- `arch-epic` editing the target repo's code directly. Sub-plans do that via206 arch-step's implement-loop in interactive mode or implementation workers in207 role-based automatic mode.208- Scope reduction. The epic scope is the epic scope. If the critic209 sees a dropped, narrowed, or silently removed requirement from the raw210 goal, approved Decomposition, North Star, Epic Requirement Coverage,211 Section 7, acceptance criteria, or verification obligations, the212 sub-plan fails. A requirement assigned to a named later sub-plan is213 preserved scope, not a failure for the current sub-plan. Agent-written214 Decision Log entries are evidence, not approval to reduce scope.215- Scope expansion by an agent, critic, review, or Decision Log. The same216 symmetry applies to additions: initial sub-plan architecture may record the217 smallest evidenced same-contract closure before sign-off; any later addition218 or new sub-plan needs explicit human approval. A Decision Log entry proves a219 change was recorded, not that it was authorized.220- Auto-acting on materially-different-path detections without user approval.221 Material scope discoveries always halt. The human may approve expansion via222 `extend_current` or `new_sub_plan`, or keep the approved boundary and require223 subtraction/redesign. No critic recommendation is self-authorizing.224- Letting critics author repair steps. Critics report verdict,225 failed checks, evidence, and scope discoveries only. The parent226 routes the result, and the resumed planner or implementation worker227 owns the reasoning for the next attempt.228- Starting a separate repair worker for ordinary in-scope critic failures.229 Exact-role resume is the default repair path; a new clean role child is only230 for unrecoverable handle loss, invalidated inputs, or explicit user override.231- Parallel planning or parallel implementation. Same-session `auto-plan` may232 plan every sub-plan before implementation, but it still handles one sub-plan233 at a time in decomposition order. Implementation always runs one sub-plan at234 a time and advances only after the epic critic passes.235- Marking a same-session `auto-plan` sub-plan `planned` from a consistency236 marker, plausible Section 3-7 content, prior stored status, or ArcEpic-authored237 setup. The ArcStep generated receipt gate is the proof.238- Same-session `auto-implement` starting while any non-complete sub-plan is not239 `planned`. Plan all sub-plans first with `auto-plan`.240- Marking a same-session `auto-implement` sub-plan `complete` from stored241 Status, worklog optimism, local proof, one `$arch-step auto-implement`242 invocation, or ArcStep audit alone. ArcStep audit COMPLETE must come first,243 then the epic critic must return `pass`.244- Running the epic critic while the sub-plan implementation audit is missing,245 NOT COMPLETE, reopened, or otherwise not clean. Continue or report246 `$arch-step auto-implement <SUBPLAN_DOC_PATH>` for that sub-plan instead.247- Two-second child polling. The external-harness lane defaults to 180-second waits248 while waiting for external processes unless the user explicitly pins a249 different cadence in the role policy.250- Calling a slow planner or worker "hung" just because it has no final251 artifact after a few minutes. Native host state or external stream receipts252 may show progress; external children often run for 5+ minutes;253 broad `xhigh` or `max` planner/worker runs can reasonably take 20-40254 minutes. In the external lane use process state plus `events.jsonl`, `stderr.log`,255 `stream.log`, `heartbeat.json`, and `monitor.json`; treat recent256 thinking/tool/output stream activity as progress.257- Terminating an external child before the long-run floors expire unless there258 is clear failure evidence. External defaults are: poll every 180s,259 call a run `quiet` only after 900s without stream activity, and call260 it `needs_attention` only after 1800s without stream activity or after261 the pinned max runtime.262- Passing raw model shorthand to external subprocesses. Resolve it first using263 shared model-resolution doctrine; preserve exact family/version or264 ask for the runnable ID.265- Heuristic keyword mapping for decomposition. Interpretation is266 prose reasoning, taught by `references/decomposition-principles.md`.267- A second "resume" command. The user types what they type; the268 skill figures it out from the epic doc + sub-plan docs.269270## First move2712721. Capture the user's goal verbatim. Compute `sha256`.2732. Resolve or propose the epic doc path274 (`docs/EPIC_<TITLE>_<YYYY-MM-DD>.md`).2753. Read `../_shared/agent-orchestration-policy.md` and276 `references/model-and-effort.md`. Prefer clean native same-host roles. Ask277 one consolidated question only when an explicit external harness or another278 selected external lane lacks load-bearing execution values. Same-session279 `auto-plan` runs no critic during planning.2804. Read `references/decomposition-principles.md`. Draft the281 Decomposition (one-sentence descriptions, assertion-style gates,282 dependency-then-risk ordering, and count chosen from real proof283 boundaries rather than a target range).2845. Read `../_shared/scope-and-convergence.md`.2856. Read `references/epic-doc-contract.md`. Write the epic doc.2867. Surface the Decomposition and ask the user to approve or adjust.287288## Modes (re-entrant; one per turn)289290Detail per mode lives in `references/workflow-contract.md`.2912921. **`start`** — epic doc does not yet exist. Propose the path, resolve the293 intended lane without inventing native model settings, ask only for missing294 external values when an external lane was selected, draft the Decomposition,295 and surface it for approval.2962. **`approve-decomposition`** — epic doc has297 `sub_plans_approved: false`. Apply user adjustments, flip flag,298 set `status: active`.2993. **`run`** — main orchestration pass. Routes per300 `references/arch-step-integration.md` to the next arch-step301 command for the first non-complete sub-plan or runs the critic.3024. **`resume-scope-change`** — epic is `halted` after a critic flagged a303 scope issue; a human has replied. Apply the explicit choice: approve and304 re-approve an `extend_current`/`new_sub_plan` expansion, or keep scope and305 route subtraction/redesign. Log the human decision and resume.3065. **`summary`** — user asked a status question. Render a table of307 sub-plan statuses and the most recent log entries. No state308 changes.3096. **`auto-plan`** — same-session planning driver after decomposition310 approval. Sets up the next sub-plan DOC_PATH, drives real `$arch-step311 auto-plan <SUBPLAN_DOC_PATH>` for that exact doc, runs the ArcStep readiness312 gate, marks it `planned` only when the gate exits 0, then repeats for the313 next sub-plan in decomposition order. It stops before implementation.3147. **`auto-implement`** — same-session implementation driver. Requires every315 non-complete sub-plan to be `planned`, then runs each in order through real316 `$arch-step auto-implement <SUBPLAN_DOC_PATH>` until ArcStep audit is317 COMPLETE, runs the epic critic, and marks the sub-plan `complete` only after318 critic `pass`.3198. **`auto-run`** — role-based automatic execution after decomposition320 approval. Prefer clean native planner/worker/critic children from durable321 artifacts, resume the exact planner or worker for repair, and start every322 critic clean. If the external harness was deliberately selected, resolve323 and pin its role table, initialize its auto run directory, and use the324 script only for external invocation and receipts.325326## Output expectations327328- Epic doc at the user-named (or proposed) path.329- Per-sub-plan canonical arch-step DOC_PATHs under330 `docs/epic/<EPIC_SLUG_WITH_DATE>/PHASE_<NN>_<SUBPLAN_SLUG>_<YYYY-MM-DD>.md`,331 owned by arch-step.332- Same-session `auto-plan` leaves non-complete sub-plans at Status `planned`333 only when their exact DOC_PATH passes the `arch-step` generated receipt gate.334- Native role dispatches record their exact child handles and return evidence335 as compact Orchestration Log pointers. External epic critic artifacts live under336 `<orchestrator repo root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/`337 including the EpicVerdict JSON, the exact invocation.sh, and the338 subprocess stream log.339- External-harness automatic artifacts live under340 `<orchestrator repo root>/.arch_skill/arch-epic/auto/<epic-slug>/run-<ts>/`341 including `state.json`, `execution_policy.json`, worker prompts,342 worker session IDs, latest worker-attempt pointers, critic verdicts, child `events.jsonl`,343 `stderr.log`, `stream.log`, `heartbeat.json`, `monitor.json`, and344 `report.md`.345- Orchestration Log and Decision Log append-only in the epic doc.346- Console summary with the epic doc path, the per-sub-plan status347 table, and the current active sub-plan's next action.348349## Reference map350351- `references/workflow-contract.md` — re-entrant modes with inputs,352 outputs, failure modes, judgment-vs-determinism split.353- `references/epic-doc-contract.md` — epic doc shape, frontmatter,354 section structure, mutation rules, validation on load.355- `references/decomposition-principles.md` — when to split a goal356 into sub-plans. Prose reasoning with worked examples; no keyword357 tables.358- `../_shared/depth-first-planning.md` — destination map, first359 working slice, expansion map, proof gates, and scope-cut distinction360 shared with arch-step and miniarch-step.361- `references/arch-step-integration.md` — sub-plan Status →362 arch-step command mapping. What the skill invokes vs. what the363 user or native goal-mode continuation does.364- `references/scope-change-discipline.md` — approved scope lock,365 materially-different path vs noise, and preservation-only scope366 decisions.367- `references/critic-contract.md` — EpicVerdict JSON schema and368 scope-drift / requirement-coverage checks.369- `references/critic-prompt.md` — verbatim critic prompt body with370 placeholders.371- `references/auto-harness-prompts.md` — transport-neutral role prompt372 contracts for planner, implementation, exact-role continuation, and clean373 critics.374- `references/epic-verdict-schema.json` — JSON schema file used by375 Codex `--output-schema`, inlined into Claude `--json-schema`, and appended376 to Grok and Kimi critic prompts before post-validation.377- `references/model-and-effort.md` — native-first role dispatch plus external378 model shorthand resolution, exact-version preservation, and ask-once379 discipline.380- `references/resume-semantics.md` — how the skill re-derives state381 each turn from the epic doc + sub-plan docs.382- `references/examples.md` — worked examples: happy path,383 scope-change insertion, harmless observations ignored.384385## The external harness adapter386387`scripts/run_arch_epic.py` is deterministic external-lane plumbing. After the388orchestrator deliberately selects the external harness, it resolves the389external role policy, creates run directories, spawns and resumes workers,390spawns structured critics, and writes artifacts. It does NOT choose transport,391interpret decomposition, draft the epic doc, decide verdicts, or route392sub-plan states — those live in the orchestrator's prose reasoning.393394```395python3 scripts/run_arch_epic.py critic-spawn \396 --epic-doc <path> \397 --sub-plan-name "<name>" \398 --sub-plan-doc-path <path> \399 --prompt-file <path> \400 --schema-file references/epic-verdict-schema.json \401 --runtime claude|codex|grok|kimi \402 --model <model> \403 --effort <effort> \404 [--codex-profile <profile>] \405 [--orchestrator-root <dir>]406```407408External-harness examples:409410```411python3 scripts/run_arch_epic.py resolve-execution \412 --policy-file /tmp/arch-epic-auto-policy.json413414python3 scripts/run_arch_epic.py auto-init \415 --epic-doc docs/EPIC_BIG_GOAL_2026-04-26.md \416 --policy-file /tmp/arch-epic-auto-policy.json417418python3 scripts/run_arch_epic.py worker-spawn \419 --run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \420 --target-repo . \421 --role implementation_worker \422 --sub-plan-name "Build the core service" \423 --prompt-file /tmp/worker.prompt.md \424 --run-mode auto425426python3 scripts/run_arch_epic.py worker-resume \427 --run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \428 --target-repo . \429 --role implementation_worker \430 --sub-plan-name "Build the core service" \431 --prompt-file /tmp/continue.prompt.md \432 --session-id <session-id-from-session_id.txt> \433 --try-k 2 \434 --run-mode auto435436python3 scripts/run_arch_epic.py child-status \437 --try-dir <printed-child-run-dir> \438 --json439440python3 scripts/run_arch_epic.py child-tail \441 --try-dir <printed-child-run-dir> \442 --lines 80443444python3 scripts/run_arch_epic.py child-finalize \445 --try-dir <printed-child-run-dir>446```447448Foreground child runs print the session ID or verdict path after completion.449Detached child runs print the child run directory immediately; use450`child-status`, `child-tail`, and `child-finalize` to monitor and finalize451them. Writes:452- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/prompt.md`453- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/invocation.sh`454- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stdout.final.json`455- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/events.jsonl`456- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stderr.log`457- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stream.log`458- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/heartbeat.json`459- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/monitor.json`460- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/verdict.json`461- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/start_ts` / `end_ts` / `exit_code`