Skip to content

/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.

shell
$ npx -y skills add fn-opt/dryforge --skill go --agent claude-code

How 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
How auto-invocation works

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.md
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

Read more
Read it on GitHub ↗

Showing the first part of this file.

Ships withdryforge

Dryforge : New generation of harness engineering - Claude Code & Codex Plugin.

Get the whole plugin, auto-invoked
Stats
114
Stars
0
Views
14
Forks
Active
Maintenance
Shell
Language
MIT
License
15d ago
Last commit
2mo ago
Created

Repo: fn-opt/dryforge

Other skills on dryforge.