/go
Execute a refined 3-doc (handoff, spec, plan) produced by ready: wave-based parallel implementation with right-sized verification (test-first where it fits), spec-first review, and integration gates. Use when the user invokes the `go` skill after `ready` wrote the 3-doc.
$ npx -y skills add fn-opt/dryforge --skill go --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/go
Context preview
The summary Claude sees to decide when to auto-load this skill.
Execute a refined 3-doc (handoff, spec, plan) produced by ready: wave-based parallel implementation with right-sized verification (test-first where it fits), spec-first review, and integration gates. Use when the user invokes the `go` skill after `ready` wrote the 3-doc.
SKILL.md
go.SKILL.mdname: go
description: >
Execute a refined 3-doc (handoff, spec, plan) produced by ready:
wave-based parallel implementation with right-sized verification (test-first where it fits),
spec-first review, and integration gates. Use when the user invokes the `go` skill after `ready` wrote the 3-doc. Requires git.
disable-model-invocation: true
allowed-tools: Read, Edit, Write, Bash, Grep, Glob, Agent, AskUserQuestion
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
Read more
name: go description: > Execute a refined 3-doc (handoff, spec, plan) produced by ready: wave-based parallel implementation with right-sized verification (test-first where it fits), spec-first review, and integration gates. Use when the user invokes the `go` skill after `ready` wrote the 3-doc. Requires git. disable-model-invocation: true allowed-tools: Read, Edit, Write, Bash, Grep, Glob, Agent, AskUserQuestion
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
Showing the first part of this file.
Dryforge : New generation of harness engineering - Claude Code & Codex Plugin.
Other skills on dryforge.
- /migration
Convert an existing project into the dryforge documentation system: read the codebase, elicit what code can't reveal, and generate a project harness (CLAUDE.md / AGENTS.md + docs/ + per-module AGENTS.md). Use when the user invokes the `migration` skill on an existing project.
Open skill - /ready
From any input — a natural-language goal, existing docs (spec / plan / brain-dump), notes, or a mix — interactively elicit and validate intent and produce an execution-ready 3-doc (handoff, spec, plan) for go, replacing third-party brainstorming + planning in one skill. Input
Open skill - /migration
Convert an existing project into the dryforge documentation system: read the codebase, elicit what code can't reveal, and generate a project harness (CLAUDE.md / AGENTS.md + docs/ + per-module AGENTS.md). Use when the user invokes the `migration` skill on an existing project.
Open skill - /ready
From any input — a natural-language goal, existing docs (spec / plan / brain-dump), notes, or a mix — interactively elicit and validate intent and produce an execution-ready 3-doc (handoff, spec, plan) for go, replacing third-party brainstorming + planning in one skill. Input
Open skill - /migration
Convert an existing project into the dryforge documentation system: read the codebase, elicit what code can't reveal, and generate a project harness (CLAUDE.md / AGENTS.md + docs/ + per-module AGENTS.md). Use when the user invokes the `migration` skill on an existing project.
Open skill - /ready
From any input — a natural-language goal, existing docs (spec / plan / brain-dump), notes, or a mix — interactively elicit and validate intent and produce an execution-ready 3-doc (handoff, spec, plan) for go, replacing third-party brainstorming + planning in one skill. Input
Open skill

