Harness Intelligence Wiki
HarnessExecution Modes

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 those boundaries to the prompt and the named phase wrapper until the run is done or blocked.

Phase Wrapper Inventory

  • requirements-phase: runs requirements discovery through requirements-grill and write-backlog.
  • delivery-phase: runs create-spec, create-plan, implement-spec, review-phase, optional debugging-phase, and docs-ingest-phase.
  • review-phase: performs findings-first review.
  • 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.

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, 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. The selected sequential or parallel delivery shape should stay stable through implementation and debugging.

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.

Human review returns after completion. The operator can ask for a thoughtful review of the outcome, evidence, tradeoffs, and gaps, but that review is not a mid-run checkpoint.

On this page