Goal Mode And AFK
Long-running phase execution through bounded goal prompts
Goal mode is for bounded absence.
The operator gives the agent one durable objective, enough context to survive compaction, automatic validation commands, and concrete stop conditions. The run can be unattended because its boundaries are explicit.
/goal is the outer AFK execution mode. goalify compiles the durable prompt. The named phase wrapper owns the lifecycle slice inside that prompt, such as delivery, debugging, review, docs ingest, or debt resolution.
Goal Prompt Contract
A usable goal prompt names:
- one objective
- repository, branch, environment, and exact scope when known
- non-goals and write boundaries
- read-first sources
- required phase wrappers and inner skills
- tools and plugins expected for validation
- automatic validation commands
- blocker conditions that should stop the run
- final report expectations
goalify should produce a compact prompt, not a replacement spec, transcript, or essay. The current /goal prompt ceiling is 4,000 characters, so the prompt must compress context into dense scope, constraints, evidence, and stop conditions.
If the run needs a human decision to continue, that is a blocker. AFK goal flows report the blocker instead of inventing the missing decision.
Manual HITL Flow and AFK modes can run the same underlying workflow. Manual flow keeps the operator between skill boundaries. Goal mode delegates bounded work to the named phase wrapper, but the explicit review boundary always returns control to the operator.
Phase Wrapper Inventory
requirements-phase: closes bounded decisions throughrequirements-grill, then compiles the confirmed result throughcreate-spec.delivery-phase: projects an agent-ready spec throughwrite-backlogwhen needed, runscreate-planandimplement-spec, then persistsreview_dueand stops.review-phase: explicit-only readonly review that returns retainedreview_routedand stops.debugging-phase: gathers runtime evidence, patches bounded failures, and reruns regression checks.bug-discovery-phase: runs AFK ClawPatch discovery, report generation, and triage without default source mutation.bug-resolution-phase: classifies and resolves selected ClawPatch findings or bounded batches.docs-ingest-phase: updates routed wiki/project docs, navigation metadata, and root docs when proven changes affect knowledge.resolve-debt-phase: resolves one concrete debt artifact through the delivery workflow.
ClawPatch discovery goals must name scope, report path, --limit, --jobs, and whether provider/model is the automatic current agent/launcher default or an explicit override. Default command paths omit --provider and --model; add those flags only when the operator selected an override.
At the review boundary, $delivery-phase persists review_due and stops. The operator explicitly
invokes $review-phase; review returns retained review_routed and stops. The operator then
explicitly resumes $delivery-phase, which consumes that route and owns repair, debugging, debt,
documentation, or closeout. An AFK prompt cannot cross either explicit boundary by itself.
AFK Guardrails
AFK execution runs on automatic evidence: tests, typechecks, linting, static validation, browser automation when available, logs, and command output.
The run stops when the objective is complete, the named phase reaches its stop condition, delivery reaches review_due, review returns review_routed, validation cannot be completed, required tools or context are missing, evidence contradicts the goal premise, or continuing would expand scope.
Unclear requirements should go through requirements discovery before they become an AFK implementation goal. Implementation uses full-parallel worker waves with disjoint ownership and plan-derived dependencies.
ClawPatch goals should keep discover and resolve separate by default. Use Massive Bug Hunt And Fix for the staged discover, inspect, choose, resolve path.
Done Signal
A goal-mode run closes when the phase stop condition is satisfied, automatic validation evidence is recorded, docs ingest is completed or skipped with reason, and the final report explains changed files, checks, blockers, and remaining risks.
Review is a required explicit operator boundary. Completion past review_due requires a separate review invocation and a separate delivery resume; the retained report and route preserve evidence between those runs.