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…
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.
/goContext 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.
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
> **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.
`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.)
wins; where plan conflicts with spec, follow the spec.
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.
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."
(what to retry, how to fix), but keep the structure and the safety constraints.
results only. Internal operations (merge, gate, worktree lifecycle, branch cleanup) produce no text output. Output tokens are direct cost; narrating routine steps is waste.
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").
parallelism — never as ceremony.
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.
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
A bounded-autonomy architecture plugin harness for Claude Code and Codex