Go

Superharness Workflow

Route new requirements through superharness:batch-grill-me and superharness:to-prd, then continue from the phase and task items stored in task.json.

Arguments

/superharness:go "requirement"
/superharness:go [lite] "requirement"
/superharness:go --task {task-id}

Only --task selects an existing task. It accepts exactly one task-id and cannot be combined with [lite] or requirement text. Without --task, treat the complete argument as a new requirement even when it matches an existing task directory name. When --task is present, require .superharness/tasks/{task-id}/task.json to exist; report a missing or invalid task-id without starting a new requirement. Never scan for a likely task.

Exact Task Resume

1. Read task.json, prd.md, contract.md, and plan.md when present.
2. Stop for discarded unless the user explicitly requests inspection. For a completed task, run superharness task evidence {task-id} --json: a valid chain and clean worktree stop unless delivery or inspection was requested. Diagnose any other completed evidence shape before continuing.
3. Use the stored profile as authority; task resume does not accept or require [lite].
4. Consume the task worktree_path to locate the single task checkout. A non-empty persisted path, whether legacy or flat-v1, is authoritative: reuse it exactly and never recompute its layout. Only an empty path may invoke superharness:using-git-worktrees, which creates or reuses the checkout through superharness task worktree create {task-id} --json.
5. Select the first task whose status is not "completed". Never redispatch a completed item.
6. Inspect git status, diff, log, and the selected task's focused verification before continuing. Do not rerun completed tasks' focused verifications on resume — the finishing gate covers the whole set once at the end.

When resuming check, no final-review verdict file exists. If final review is interrupted before finishing starts, rerun the whole-task final review. Do not create a final-review result file or another reviewer artifact to make this recovery durable.

When the selected item is in_progress and the worktree is dirty, keep every existing edit. Full dispatches a fresh recovery agent with the task directory, plan task id, worktree path, focused test evidence, and concise interface context. Lite continues recovery on the main thread. Ask the user when ownership is unclear. Never reset or stash during recovery.

New Requirement

If .superharness/spec/ still contains only skeleton placeholders, mention once that superharness:setup-superharness can populate conventions, then continue.

Resolve and Persist Requirements

Invoke superharness:batch-grill-me until every decision branch is resolved and confirmed. Invoke superharness:to-prd once with explicit profile: full or profile: lite, taken from the user's invocation: profile: lite only when the user passed the [lite] marker, otherwise profile: full. Task simplicity is never a reason to pass lite. New task.json files capture implementation.base_sha.

Full Profile

1. Invoke superharness:writing-plans and obtain approval for the public seams and behavior slices.
2. Run superharness task transition {task-id} implement once.
3. Invoke superharness:subagent-driven-development. The controller reads depends_on, starts each ready item, dispatches independent implementers in parallel in one shared task worktree, records each single-commit result with task item complete, and runs typecheck only after every wave. Parallelism and conflict handling are the model's own decisions.
4. After every task is completed, enter the shared final check.

Lite Profile

Lite does not create plan or implementation protocol files. Lite task.json must already contain the approved 1–3 task items before implementation begins; superharness:to-prd atomically created their id, name, status, seams, and behavior_slices from the confirmed acceptance slices. Stop when those items are absent or malformed. Do not write or reshape task items after the task has entered implement. Decide worktree isolation once based on checkout ownership.

For each task item on the main thread:

1. Run superharness task item {task-id} {task-number} start.
2. Invoke superharness:test-driven-development and complete one public seam at a time with red-before-green focused tests.
3. Commit the task once its focused verification passes.
4. Run superharness task item {task-id} {task-number} complete --commit {full-sha}.

Lite skips implement subagents and per-task reviewers. It remains serial. Tests, commits, the shared whole-task review, final verification, and finishing remain required.

Shared Final Check

After all task items are completed, Full, Lite, and executing-plans meet here. Both profiles run N implementers + 1 two-axis review, dispatched directly — there is no review CLI:

1. Run superharness task transition {task-id} check once.
2. Shell preflight: git rev-parse must resolve implementation.base_sha, and git diff {base}...HEAD --numstat must be non-empty with total changed lines within 12000. Over the limit: stop for explicit user direction (suggest reviewing per task item manually) — finishing cannot be entered.
3. In one message, dispatch the Spec axis and the Standards axis check agents in parallel per superharness:subagent-driven-development's Final Check, and present the two reports separately.
4. Any Critical/Major finding is blocking: transition back to implement, project the blocking findings into a task-local JSON per SDD's Final Check, repair through superharness task group-findings groups (Full) or one conservative serial group (Lite), land the repairs as commits, return to check, and recheck the fix diff. A recheck that still finds Critical/Major stops for the user.
5. Invoke superharness:finishing-a-development-branch while phase is still check. It owns fresh final verification, the review discipline recorded in verification.md (reviewed HEAD, post-review fix rechecks, effective HEAD), and the transition to complete.

Lifecycle

plan → implement → check → complete

The normal Full path performs only those three lifecycle transitions. Review or verification fixes use the existing legal check → implement → check round trip. The parent controller owns phase transitions and task item commands; implement agents never edit task.json.

Red Flags

• Guessing the task-id or changing the stored profile
• Selecting the lite profile without the user's explicit [lite] marker, however simple the task looks
• Starting implementation before the PRD approval gate
• Creating implementation protocol files for new Full or Lite tasks
• Running a per-task reviewer
• Resetting or stashing a dirty recovery worktree
• Entering final check before every task item has a validated full commit SHA
• Skipping the whole-task review, fresh verification, or finishing