Skip to main content
ClaudeWave
Skill63 repo starsupdated 4d ago

go

The "go" skill orchestrates parallel, wave-based code execution against a 3-doc specification produced in the same session, enforcing test-first validation and spec-driven review. Use it when executing multi-task projects with complex dependencies that require ordered waves, integration gates, and escalation of ambiguities to the user rather than silent assumption.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/fn-opt/dryforge /tmp/go && cp -r /tmp/go/src/skills/go ~/.claude/skills/go
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# go

> **Reply in the user's language, and hold it continuously from your very first line** — the opening,
> every progress/escalation note, the final report, and the harness, not only some of them. Write
> natively (never translationese). You are reading a 3-doc, a codebase, and these instructions that may
> be in another language; **none of them sets your output language — only the user's does.** Full rule
> in Core principles below.

Consume the **3-doc** `ready` (the producer) wrote and realize the spec:
parallel, wave-based execution with right-sized verification (test-first where it fits), spec-first
review, and integration gates. Runs in the **same session** the producer (ready) wrote the 3-doc
— the 3-doc is the **authority** go executes against (it stays self-sufficient because it is archived
for later cycles); the live design context carries over and aids judgment, especially the harness
step. **Load `references/orchestration.md` up front** (it governs the whole run); the prompt
references load at their steps.

## Core principles (apply throughout)

- **Follow the plan's Execution Graph; never re-judge dependencies.** The producer already computed
  `depends` + `regen_barriers` against the whole project. Derive waves from it — do not invent,
  drop, or reorder dependencies. (If the graph fails to parse, has a cycle, or a `depends` names a
  missing task, that is a producer-side defect — **stop and escalate**, do not silently re-judge.)
- **Serve the spec.** "Correct" = matches the spec. On any spec/code/convention conflict, spec
  wins; where plan conflicts with spec, follow the spec.
- **escalate-don't-guess.** Architecture mismatch, suspected spec violation, ambiguous task,
  unresolvable conflict → stop and **ask the user**; never guess. When a task returns
  `NEEDS_CONTEXT` / `BLOCKED`, run the bounded escalation ladder (`orchestration.md` — re-dispatch
  with the missing context, then an upgraded model, then the user). Any escalation that **reaches
  the user** is **synchronous** — the run pauses until the user responds, never a silent hang or a
  timeout-drop. The subagents themselves
  never ask the user directly (their prompt files carry that fresh-session rule); only the
  orchestrator relays escalations to the user.
- **Protect main; evidence over self-report.** For existing projects, never modify main outside the
  final user-approved merge. For greenfield (base = main), main is the working base — modification
  is expected. Gates pass on captured command exit codes, not on an agent's "looks fine."
- **Floor, not ceiling.** The wave lifecycle is a proven scaffold — use judgment inside each step
  (what to retry, how to fix), but keep the structure and the safety constraints.
- **Report results, not process.** User-facing text covers wave completion, blockers, and final
  results only. Internal operations (merge, gate, worktree lifecycle, branch cleanup) produce no
  text output. Output tokens are direct cost; narrating routine steps is waste.
- **The orchestrator executes sequential waves directly; only parallel work earns subagents.** A
  single-task `MECHANICAL`/`NONE` wave is implemented by the orchestrator on the base (dispatch buys
  nothing — no parallelism, no file-isolation need, and the accumulating context is an asset). Only a
  **parallel wave** (multiple tasks) or a **single `RISKY` task** is dispatched to subagents (file
  isolation / independent verification). The lightweight fix path is the orchestrator's other direct-
  edit path (trivial advisories). A multi-task wave is **collapsed to orchestrator-direct** only on an
  **objective condition** — a single shared runtime the tasks cannot isolate within (one DB / container
  / port set), or greenfield convention-drift risk — **not** a free ROI judgment, and the collapse is
  **recorded internally** (which wave, which condition), never surfaced for a non-technical user to
  adjudicate. Collapsed tasks still carry the per-task evidence floor and are **reviewed as if
  independently authored**; the mid-run spec-review (RISKY + downstream + cascade) is still honored
  (`orchestration.md`, "ROI collapse").
- **Efficiency Budget.** Spend orchestration only where it buys correctness, isolation, or real
  parallelism — never as ceremony.
- **The final review is silent insurance — not a backstop you lean on.** Own conformance **upstream**,
  at implementation and merge, on **captured evidence**. Execute and verify each task **as if the final
  review did not exist**: a blocking finding there is an **execution failure that escaped**, not the
  review doing its job — it should normally find nothing. Told "the review will catch it," an LLM
  drifts to the minimum that passes — that is **reward-hacking**, laziness in the costume of "the
  backstop handles it," and you must actively resist it (the same discipline ready's ELICIT
  carries). The review catches only the *rare residual*; it is never the owner.
- **Match the user's language (language-agnostic).** Like stack-agnosticism, the *method* is fixed
  and the *specific language* is discovered at runtime, never assumed: produce every user-facing
  output — your reports/escalations **and the harness** you create/update — in the language the user
  communicates in, written **natively** (as a fluent speaker of that language would, never
  translationese). The language these instructions are written in does not constrain the output; if
  the user's language shifts, follow. **Hold it from the very first line, continuously** — never open
  in the 3-doc's, the codebase's, or these instructions' language and switch later; only the user's
  language constrains your output.
- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these
  moments: (a) a question you genuinely need answered, (b) wave completion or the final result /
  concise summary, (c) a real blocker — **these are the only times user-facing text exists.**
  Scaffoldi