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.4---56# arch-epic78After explicit selection, wraps `$arch-step` to execute a multi-plan goal.9Filing or decomposing GitHub issues does not select this lifecycle.10The skill takes a prose goal, proposes a plain-English decomposition11whose count follows proof gates rather than a preset range, gets user approval, and then drives12each sub-plan through arch-step's `new` → `auto-plan` → `implement-loop`13→ `audit-implementation` arc. After each sub-plan completes, a new clean14critic child inspects the shipped work for scope15drift against the approved North Star. If the critic finds missing authorized16work, post-approval proposed expansion, or unauthorized built scope, the skill17halts. It may resume ordinary missing work, but it never enlarges scope from18the critic. A human decides whether to approve expansion and re-approve, or keep19the boundary and require subtraction/redesign.20Otherwise it advances to the next sub-plan.2122The normal lane is interactive and re-entrant: arch-epic invokes or observes23arch-step commands in the visible session one transition at a time.2425The same-session automatic commands are explicit and opt-in:26`auto-plan` is a strict sequential driver over real `$arch-step auto-plan27<SUBPLAN_DOC_PATH>` runs. It handles one approved sub-plan at a time, requires28the generated ArcStep receipt gate to report ready for that exact DOC_PATH, and29only then marks the sub-plan `planned` before moving to the next one.30`auto-implement` is a strict sequential driver over real `$arch-step31auto-implement <SUBPLAN_DOC_PATH>` runs. It handles one planned sub-plan at a32time, lets ArcStep own the full implement/prove/audit loop, runs the epic33critic only after ArcStep's implementation audit says `Verdict (code):34COMPLETE`, and marks the sub-plan `complete` only after that critic passes.3536Role-based automatic execution is transport-aware. After decomposition37approval, arch-epic drives `epic_planner`, `implementation_worker`, and38`critic` roles from durable epic/sub-plan artifacts. Same-host roles normally39start as clean native children. The external-harness lane remains explicit and40opt-in when a different provider, load-bearing exact model/profile, durable or41detached lifecycle, worktree/process isolation, automation surface, structured42receipt, or another real benefit is worth the added process cost. In that lane43the existing script resolves and pins the external role table and owns only44invocation and receipt mechanics. Workers apply arch-step doctrine directly45from disk; they do not invoke nested `auto-plan`, `implement-loop`, or other46automatic continuation commands.4748Planner and implementation worker roles are resumable regardless of transport.49If a new clean critic finds in-scope unfinished work, arch-epic resumes the50exact planner or implementation worker with the critic's observation and51artifact evidence. The critic never prescribes repair steps, and ordinary52repair does not start a separate repair-worker role.5354Progressive lazy planning is the default for interactive and role-based55work: sub-plan N+1 is not planned until sub-plan N is complete. Same-session56`auto-plan` is the deliberate exception: it plans all approved sub-plans first,57but still plans exactly one sub-plan at a time and stops before implementation.58The user approves the decomposition up front, then approves each sub-plan's59North Star when it comes up in interactive mode. In role-based automatic mode,60new clean critics check North Star and Epic Requirement Coverage gates instead of61asking the user on every sub-plan.6263Resume is the only mode — every `$arch-epic` invocation re-reads the64epic doc and sub-plan docs from disk and picks up where things left65off. "Continue my epic", "pick up where we left off", "keep going on66<project>" all work.6768The skill is a thoughtful wrapper — its job is to reduce user69orchestration burden. In interactive mode, user involvement is bounded70to the goal, decomposition, per-sub-plan North Star, and material71scope-preservation decisions. In role-based automatic mode, the user approves72the decomposition up front; an external harness also pins its role table.73Clean critics replace74per-sub-plan North-Star pauses unless a material ambiguity or scope75change requires the user.7677## When to use7879- "This is too big for one arch-step plan. Help me break it into plans80 and run them in order."81- "Orchestrate these sub-plans: X, Y, Z. Check each one before moving82 to the next."83- "Continue my epic at `docs/EPIC_<slug>_<date>.md`."84- "Keep going on the <goal> epic."85- "Pick up where we left off on <project>."86- "Automatically implement this approved epic end to end."87- "Auto-plan every sub-plan before we implement any of them."88- "Run `arch-epic auto-implement` on this approved epic."89- "Run the epic automatically and ask me which models to use for the90 planner, implementation worker, and critics."9192## When not to use9394- Single architecture plan, including single-plan automatic planning through95 implementation: use `$arch-step full-auto` or `$miniarch-step full-auto`.96- One-pass mini plan that hands off to implement: use `$arch-mini-plan`.97- 1–3 phase feature flow: use `$lilarch`.98- Open-ended optimization with bet-and-learn iteration: use native goal mode.99- Read-only routing across arch artifacts: use `$arch-flow`.100- Stepped orchestration in a foreign repo with a per-step critic: use101 `$stepwise`.102- One-shot review of a diff, branch, or completion claim: use ordinary host103 review. Use `$codex-review-yolo` only when the exact external `yolo` profile104 and its receipts are the requested benefit.105- Work that fits in a single orchestrator turn.106107## Non-negotiables108109Must happen every run:110- Pin `raw_goal` verbatim with `sha256` in the epic doc. Any silent111 rewrite clears the decomposition-approved flag.112- Produce a one-sentence-per-sub-plan decomposition and get user113 approval before planning any sub-plan.114- Treat the raw human goal and approved decomposition as the epic baseline.115 Decomposition approval does not authorize hidden infrastructure in later116 sub-plans. Apply `../_shared/scope-and-convergence.md`.117- Apply `../_shared/agent-orchestration-policy.md` whenever a planner,118 worker, or critic is dispatched, and apply `$prompt-authoring` to every119 actual populated first brief or materially reframed follow-up. Prefer a clean120 native child for ordinary same-host work. Use the explicit external harness121 when a concrete provider, exact model/profile, durable or detached lifecycle,122 worktree/process isolation, automation surface, structured receipt, or123 another real benefit is worth the added process and integration cost. These124 examples are recognition aids, not an allowlist.125- Native starting context is explicit. Codex dispatch always sets126 `fork_turns` to `"none"` for clean planner/worker/critic roles, to a positive127 count only for deliberately bounded chat context, or to `"all"` only when128 the full conversation is genuinely required. Claude uses a clean named129 subagent by default; an explicit conversation fork means full inherited130 conversation, while a skill with `context: fork` is an isolated clean131 subagent context. Context is separate from permissions, capabilities, and132 worktree isolation.133- The parent owns sequencing, external topology, and final integration.134 Planner, worker, and critic prompts allow each role its own native sub-agents135 on its own host and forbid starting external agents.136- Each sub-plan inherits its approved epic boundary, records its own initial137 minimal convergence closure during initial architecture, and signs off that138 closure before implementation. After sign-off, only explicit human approval139 may add a path, obligation, sub-plan, mechanism, or proof category.140- Each sub-plan is its own full `$arch-step` canonical DOC_PATH.141 The epic doc does NOT contain plan internals (no Sections 0–10,142 no call-site audit).143- Progressive planning: in interactive and role-based automatic modes, invoke144 `$arch-step new` or planner harness work for sub-plan N+1 only after sub-plan145 N is `complete` per the epic critic. In same-session `auto-plan`, assign or146 create only the scaffold needed for the next sub-plan's canonical DOC_PATH,147 then invoke or continue the real `$arch-step auto-plan <SUBPLAN_DOC_PATH>`148 flow for that exact DOC_PATH. Creation, scaffold repair, copied sections, or149 marker-looking text are never readiness proof.150- In same-session `auto-plan`, update a sub-plan Status to `planned` only after151 `python3 skills/arch-step/scripts/arch_stage_gate.py ready --doc152 <SUBPLAN_DOC_PATH>` exits 0 for that exact DOC_PATH. If the gate is not ready,153 keep or set the sub-plan to `planning` and continue or report the exact154 `$arch-step auto-plan <SUBPLAN_DOC_PATH>` command.155- Per-sub-plan North Star approval uses `$arch-step`'s existing156 North-Star gate. `arch-epic` does not re-invent it — it just157 stops when arch-step stops. In role-based automatic mode, this gate is158 replaced by a new clean North-Star critic after the user-approved159 decomposition is pinned. An external harness also pins its role table. In160 same-session `auto-plan`, the161 approved decomposition can stand in for per-sub-plan user approval only when162 the sub-plan North Star is a direct, unambiguous expansion of the approved163 epic scope; otherwise stop and ask.164- Per-sub-plan implementation runs through165 `$arch-step implement-loop` in interactive mode and real `$arch-step166 auto-implement <SUBPLAN_DOC_PATH>` in same-session `auto-implement`.167 Same-session `auto-implement` is not complete after one invocation; it keeps168 the selected sub-plan at `implementing` and continues the ArcStep169 implement/prove/audit loop until `arch_skill:block:implementation_audit` says170 `Verdict (code): COMPLETE` or a true blocker stops progress. In171 role-based automatic mode, implementation workers execute the approved172 sub-plan directly from arch-step doctrine and the sub-plan doc; the top-level173 orchestrator still does not edit target code itself.174- Epic critic runs once per sub-plan at sub-plan completion and returns175 structured JSON `EpicVerdict`. It is always a new clean child and is never176 resumed. Prefer native dispatch; the external harness remains available for177 deliberate external benefits.178- Permissions and worktree posture are resolved independently from starting179 context. Use enforced read-only capability for critics when available,180 retain the no-edit prompt contract, and compare repository state before and181 after critic work. External harness processes keep the existing dangerous /182 skip-permissions / no-sandbox convention; that convention does not describe183 native children.184- Native role execution needs no invented runtime/model promise. For the185 explicit external harness, the user supplies role execution for186 `epic_planner`, `implementation_worker`, and `critic`; ask once for missing187 load-bearing values. An omitted model on an external Codex role defaults to188 `gpt-6-astra`, and an omitted effort on that Astra role defaults to `xhigh`.189 An external Kimi role defaults to `kimi-code/k3` and the model-default `max`190 effort; other runtimes, Codex models, and efforts never silently default.191 Natural Grok wording resolves to `grok-4.6`, while explicitly named legacy192 Grok ids remain exact. Existing external193 policies with legacy `repair_worker` values may load, but ordinary critic194 failures resume the exact original planner or implementation worker.195 Same-session `auto-plan` needs no role table. Same-session196 `auto-implement` uses the same transport-selected completion-critic policy197 as interactive mode.198- Resume is re-entrant: any invocation against an existing epic doc199 re-reads on-disk state and continues. No dedicated `resume`200 command.201202Must never happen:203- `arch-epic` editing the target repo's code directly. Sub-plans do that via204 arch-step's implement-loop in interactive mode or implementation workers in205 role-based automatic mode.206- Scope reduction. The epic scope is the epic scope. If the critic207 sees a dropped, narrowed, or silently removed requirement from the raw208 goal, approved Decomposition, North Star, Epic Requirement Coverage,209 Section 7, acceptance criteria, or verification obligations, the210 sub-plan fails. A requirement assigned to a named later sub-plan is211 preserved scope, not a failure for the current sub-plan. Agent-written212 Decision Log entries are evidence, not approval to reduce scope.213- Scope expansion by an agent, critic, review, or Decision Log. The same214 symmetry applies to additions: initial sub-plan architecture may record the215 smallest evidenced same-contract closure before sign-off; any later addition216 or new sub-plan needs explicit human approval. A Decision Log entry proves a217 change was recorded, not that it was authorized.218- Auto-acting on materially-different-path detections without user approval.219 Material scope discoveries always halt. The human may approve expansion via220 `extend_current` or `new_sub_plan`, or keep the approved boundary and require221 subtraction/redesign. No critic recommendation is self-authorizing.222- Letting critics author repair steps. Critics report verdict,223 failed checks, evidence, and scope discoveries only. The parent224 routes the result, and the resumed planner or implementation worker225 owns the reasoning for the next attempt.226- Starting a separate repair worker for ordinary in-scope critic failures.227 Exact-role resume is the default repair path; a new clean role child is only228 for unrecoverable handle loss, invalidated inputs, or explicit user override.229- Parallel planning or parallel implementation. Same-session `auto-plan` may230 plan every sub-plan before implementation, but it still handles one sub-plan231 at a time in decomposition order. Implementation always runs one sub-plan at232 a time and advances only after the epic critic passes.233- Marking a same-session `auto-plan` sub-plan `planned` from a consistency234 marker, plausible Section 3-7 content, prior stored status, or ArcEpic-authored235 setup. The ArcStep generated receipt gate is the proof.236- Same-session `auto-implement` starting while any non-complete sub-plan is not237 `planned`. Plan all sub-plans first with `auto-plan`.238- Marking a same-session `auto-implement` sub-plan `complete` from stored239 Status, worklog optimism, local proof, one `$arch-step auto-implement`240 invocation, or ArcStep audit alone. ArcStep audit COMPLETE must come first,241 then the epic critic must return `pass`.242- Running the epic critic while the sub-plan implementation audit is missing,243 NOT COMPLETE, reopened, or otherwise not clean. Continue or report244 `$arch-step auto-implement <SUBPLAN_DOC_PATH>` for that sub-plan instead.245- Two-second child polling. The external-harness lane defaults to 180-second waits246 while waiting for external processes unless the user explicitly pins a247 different cadence in the role policy.248- Calling a slow planner or worker "hung" just because it has no final249 artifact after a few minutes. Native host state or external stream receipts250 may show progress; external children often run for 5+ minutes;251 broad `xhigh` or `max` planner/worker runs can reasonably take 20-40252 minutes. In the external lane use process state plus `events.jsonl`, `stderr.log`,253 `stream.log`, `heartbeat.json`, and `monitor.json`; treat recent254 thinking/tool/output stream activity as progress.255- Terminating an external child before the long-run floors expire unless there256 is clear failure evidence. External defaults are: poll every 180s,257 call a run `quiet` only after 900s without stream activity, and call258 it `needs_attention` only after 1800s without stream activity or after259 the pinned max runtime.260- Passing raw model shorthand to external subprocesses. Resolve it first using261 shared model-resolution doctrine; preserve exact family/version or262 ask for the runnable ID.263- Heuristic keyword mapping for decomposition. Interpretation is264 prose reasoning, taught by `references/decomposition-principles.md`.265- A second "resume" command. The user types what they type; the266 skill figures it out from the epic doc + sub-plan docs.267268## First move2692701. Capture the user's goal verbatim. Compute `sha256`.2712. Resolve or propose the epic doc path272 (`docs/EPIC_<TITLE>_<YYYY-MM-DD>.md`).2733. Read `../_shared/agent-orchestration-policy.md` and274 `references/model-and-effort.md`. Prefer clean native same-host roles. Ask275 one consolidated question only when an explicit external harness or another276 selected external lane lacks load-bearing execution values. Same-session277 `auto-plan` runs no critic during planning.2784. Read `references/decomposition-principles.md`. Draft the279 Decomposition (one-sentence descriptions, assertion-style gates,280 dependency-then-risk ordering, and count chosen from real proof281 boundaries rather than a target range).2825. Read `../_shared/scope-and-convergence.md`.2836. Read `references/epic-doc-contract.md`. Write the epic doc.2847. Surface the Decomposition and ask the user to approve or adjust.285286## Modes (re-entrant; one per turn)287288Detail per mode lives in `references/workflow-contract.md`.2892901. **`start`** — epic doc does not yet exist. Propose the path, resolve the291 intended lane without inventing native model settings, ask only for missing292 external values when an external lane was selected, draft the Decomposition,293 and surface it for approval.2942. **`approve-decomposition`** — epic doc has295 `sub_plans_approved: false`. Apply user adjustments, flip flag,296 set `status: active`.2973. **`run`** — main orchestration pass. Routes per298 `references/arch-step-integration.md` to the next arch-step299 command for the first non-complete sub-plan or runs the critic.3004. **`resume-scope-change`** — epic is `halted` after a critic flagged a301 scope issue; a human has replied. Apply the explicit choice: approve and302 re-approve an `extend_current`/`new_sub_plan` expansion, or keep scope and303 route subtraction/redesign. Log the human decision and resume.3045. **`summary`** — user asked a status question. Render a table of305 sub-plan statuses and the most recent log entries. No state306 changes.3076. **`auto-plan`** — same-session planning driver after decomposition308 approval. Sets up the next sub-plan DOC_PATH, drives real `$arch-step309 auto-plan <SUBPLAN_DOC_PATH>` for that exact doc, runs the ArcStep readiness310 gate, marks it `planned` only when the gate exits 0, then repeats for the311 next sub-plan in decomposition order. It stops before implementation.3127. **`auto-implement`** — same-session implementation driver. Requires every313 non-complete sub-plan to be `planned`, then runs each in order through real314 `$arch-step auto-implement <SUBPLAN_DOC_PATH>` until ArcStep audit is315 COMPLETE, runs the epic critic, and marks the sub-plan `complete` only after316 critic `pass`.3178. **`auto-run`** — role-based automatic execution after decomposition318 approval. Prefer clean native planner/worker/critic children from durable319 artifacts, resume the exact planner or worker for repair, and start every320 critic clean. If the external harness was deliberately selected, resolve321 and pin its role table, initialize its auto run directory, and use the322 script only for external invocation and receipts.323324## Output expectations325326- Epic doc at the user-named (or proposed) path.327- Per-sub-plan canonical arch-step DOC_PATHs under328 `docs/epic/<EPIC_SLUG_WITH_DATE>/PHASE_<NN>_<SUBPLAN_SLUG>_<YYYY-MM-DD>.md`,329 owned by arch-step.330- Same-session `auto-plan` leaves non-complete sub-plans at Status `planned`331 only when their exact DOC_PATH passes the `arch-step` generated receipt gate.332- Native role dispatches record their exact child handles and return evidence333 as compact Orchestration Log pointers. External epic critic artifacts live under334 `<orchestrator repo root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/`335 including the EpicVerdict JSON, the exact invocation.sh, and the336 subprocess stream log.337- External-harness automatic artifacts live under338 `<orchestrator repo root>/.arch_skill/arch-epic/auto/<epic-slug>/run-<ts>/`339 including `state.json`, `execution_policy.json`, worker prompts,340 worker session IDs, latest worker-attempt pointers, critic verdicts, child `events.jsonl`,341 `stderr.log`, `stream.log`, `heartbeat.json`, `monitor.json`, and342 `report.md`.343- Orchestration Log and Decision Log append-only in the epic doc.344- Console summary with the epic doc path, the per-sub-plan status345 table, and the current active sub-plan's next action.346347## Reference map348349- `references/workflow-contract.md` — re-entrant modes with inputs,350 outputs, failure modes, judgment-vs-determinism split.351- `references/epic-doc-contract.md` — epic doc shape, frontmatter,352 section structure, mutation rules, validation on load.353- `references/decomposition-principles.md` — when to split a goal354 into sub-plans. Prose reasoning with worked examples; no keyword355 tables.356- `../_shared/depth-first-planning.md` — destination map, first357 working slice, expansion map, proof gates, and scope-cut distinction358 shared with arch-step and miniarch-step.359- `references/arch-step-integration.md` — sub-plan Status →360 arch-step command mapping. What the skill invokes vs. what the361 user or native goal-mode continuation does.362- `references/scope-change-discipline.md` — approved scope lock,363 materially-different path vs noise, and preservation-only scope364 decisions.365- `references/critic-contract.md` — EpicVerdict JSON schema and366 scope-drift / requirement-coverage checks.367- `references/critic-prompt.md` — verbatim critic prompt body with368 placeholders.369- `references/auto-harness-prompts.md` — transport-neutral role prompt370 contracts for planner, implementation, exact-role continuation, and clean371 critics.372- `references/epic-verdict-schema.json` — JSON schema file used by373 Codex `--output-schema`, inlined into Claude `--json-schema`, and appended374 to Grok and Kimi critic prompts before post-validation.375- `references/model-and-effort.md` — native-first role dispatch plus external376 model shorthand resolution, exact-version preservation, and ask-once377 discipline.378- `references/resume-semantics.md` — how the skill re-derives state379 each turn from the epic doc + sub-plan docs.380- `references/examples.md` — worked examples: happy path,381 scope-change insertion, harmless observations ignored.382383## The external harness adapter384385`scripts/run_arch_epic.py` is deterministic external-lane plumbing. After the386orchestrator deliberately selects the external harness, it resolves the387external role policy, creates run directories, spawns and resumes workers,388spawns structured critics, and writes artifacts. It does NOT choose transport,389interpret decomposition, draft the epic doc, decide verdicts, or route390sub-plan states — those live in the orchestrator's prose reasoning.391392```393python3 scripts/run_arch_epic.py critic-spawn \394 --epic-doc <path> \395 --sub-plan-name "<name>" \396 --sub-plan-doc-path <path> \397 --prompt-file <path> \398 --schema-file references/epic-verdict-schema.json \399 --runtime claude|codex|grok|kimi \400 --model <model> \401 --effort <effort> \402 [--codex-profile <profile>] \403 [--orchestrator-root <dir>]404```405406External-harness examples:407408```409python3 scripts/run_arch_epic.py resolve-execution \410 --policy-file /tmp/arch-epic-auto-policy.json411412python3 scripts/run_arch_epic.py auto-init \413 --epic-doc docs/EPIC_BIG_GOAL_2026-04-26.md \414 --policy-file /tmp/arch-epic-auto-policy.json415416python3 scripts/run_arch_epic.py worker-spawn \417 --run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \418 --target-repo . \419 --role implementation_worker \420 --sub-plan-name "Build the core service" \421 --prompt-file /tmp/worker.prompt.md \422 --run-mode auto423424python3 scripts/run_arch_epic.py worker-resume \425 --run-dir .arch_skill/arch-epic/auto/big-goal/run-2026-04-26T00-00-00Z \426 --target-repo . \427 --role implementation_worker \428 --sub-plan-name "Build the core service" \429 --prompt-file /tmp/continue.prompt.md \430 --session-id <session-id-from-session_id.txt> \431 --try-k 2 \432 --run-mode auto433434python3 scripts/run_arch_epic.py child-status \435 --try-dir <printed-child-run-dir> \436 --json437438python3 scripts/run_arch_epic.py child-tail \439 --try-dir <printed-child-run-dir> \440 --lines 80441442python3 scripts/run_arch_epic.py child-finalize \443 --try-dir <printed-child-run-dir>444```445446Foreground child runs print the session ID or verdict path after completion.447Detached child runs print the child run directory immediately; use448`child-status`, `child-tail`, and `child-finalize` to monitor and finalize449them. Writes:450- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/prompt.md`451- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/invocation.sh`452- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stdout.final.json`453- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/events.jsonl`454- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stderr.log`455- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/stream.log`456- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/heartbeat.json`457- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/monitor.json`458- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/verdict.json`459- `<orch-root>/.arch_skill/arch-epic/critics/<slug>/run-<ts>/start_ts` / `end_ts` / `exit_code`