# Go

> Main entry point for end-to-end feature work. Start a full task with /superharness:go 'requirement', a lite task with /superharness:go [lite] 'requirement', or resume with /superharness:go --task {task-id}.

- Skill: `mrlyk/go` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mrlyk/go`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrlyk/go/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mrlyk (https://skillmd.com/u/mrlyk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrlyk/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

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

<IMPORTANT>
The profile decision belongs to the user, never to you. `[lite]` as the first literal token is the only trigger for the lite profile; without it the task runs full, no matter how small or simple the requirement looks. Never infer, recommend-then-assume, or silently downgrade to lite. If lite seems like a better fit, mention it once and keep executing as full unless the user explicitly restarts with `[lite]`.
</IMPORTANT>

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

```text
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