AFK Implementation

AFK phase delivery runs a bounded delivery objective through phase wrappers, usually from a /goal prompt.

The operator defines the goal before the run starts. The agent then works without manual review in the middle. The substitute for those mid-run checkpoints is a clear goal boundary, automatic checks, review, runtime evidence when needed, docs ingest, and a final report detailed enough for the operator to inspect after the run.

Use this when: a scoped goal is clear enough to run without mid-run human decisions.
It gives you: goal-mode delivery with automatic checks, review, optional debugging, and docs closeout.
It ends with: final evidence, changed paths, blockers, residual risk, and docs ingest result.
Wrapped phase/skills: $goalify, $delivery-phase, $review-phase, optional $debugging-phase, $docs-ingest-phase.

Runtime Graph

AFK delivery trades mid-run approvals for a stronger starting contract. The graph shows the autonomous path: package the goal, run the delivery wrapper, prove the work, report back with evidence.

Reading The Autonomous Run

$goalify is the compression step. It turns messy scope into objective, boundaries, sources, proof, and stop conditions.
$delivery-phase owns the inner sequence. The operator does not approve spec, plan, and implementation one by one.
Validation and review replace mid-run steering. The final report must carry the evidence the operator skipped seeing live.
Debugging needs runtime proof. Uncertainty alone is a blocker or a follow-up, not permission to widen the run.
Docs ingest belongs in closeout when knowledge changed. Otherwise the no-op is part of the evidence.

Entrypoints

$goalify: compile messy scope into a durable /goal prompt.
$delivery-phase: main AFK implementation wrapper. It composes $create-spec, $create-plan, $implement-spec, $review-phase, optional $debugging-phase, and $docs-ingest-phase.
Goal Mode And AFK: use this for the outer /goal contract.
Implementation: use this path when the operator wants to inspect spec, plan, implementation, review, or docs ingest artifacts before the next step.

Readiness Rule

AFK delivery is safe only when the prompt names one durable objective, exact scope and non-goals, read-first sources, relevant skills, proof expectations, blocker conditions, and final report expectations.

If the run needs a human decision to continue, that is a blocker. The agent should report it rather than simulating the decision.

When backlog context exists, the goal must name the target EPIC and require the agent to read all child stories or sub-issues under that EPIC before creating or updating SPEC.md. The AFK run must not collapse sibling stories into an EPIC summary or implement only one story while claiming the EPIC is done.

When backlog context includes a dependency on an open parent PR, $delivery-phase stays stack-aware as an inner mechanism. The dependency decision still starts in $create-spec through Dependency Readiness; AFK delivery should block if dependency evidence is missing, preserve recorded Branch/Base Intent, and use stack sync --dry-run before any stack mutation.

Flow

Run autonomous delivery like this:

Invoke $goalify if the scope is messy or needs compaction-safe packaging.
Put $delivery-phase in the /goal prompt as the execution wrapper.
Give $delivery-phase the target EPIC and its child stories or sub-issues as source context when backlog context exists.
Let $delivery-phase run its inner skills inside the goal boundary.
Keep sequential delivery as the default.
Use parallel waves when the plan defines disjoint write scopes and independent gates.
Let $delivery-phase run validation and $review-phase.
Enter $debugging-phase for evidence-backed runtime failures.
Run $docs-ingest-phase for docs-affecting changes.
Stop when the goal is achieved or a concrete blocker invalidates continued autonomous work.

Decision Points

If the goal lacks source truth or acceptance criteria, stop and ask rather than guessing.
If the goal names an EPIC but not its child stories or sub-issues, inspect the backlog source for all children before drafting the spec; stop if that source is unavailable.
If parallel execution would touch shared files, return to sequential delivery.
If a validation tool is missing, report the blocker and avoid claiming the gate passed.
If implementation reveals a broader issue outside goal scope, capture debt or a follow-up instead of widening the run silently.

Terminal Outcome

The goal stops with implemented scope, validation evidence, review status, docs ingest result, and a concise blocker list when anything remains.

Validation

The final report must include changed paths, checks run, browser or manual evidence when relevant, docs metadata changes, and gaps.

See Validation Gates and Sequential And Parallel Delivery for proof and delivery-shape boundaries.

On this page