Skip to content
Development
Skill

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

From plugin
dryforge
1683 skills
Install
$ 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.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • 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.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
Ships withdryforge

A bounded-autonomy architecture plugin harness for Claude Code and Codex

Get the whole plugin
Stats
242
Stars
23
Forks
Active
Maintenance
Shell
Language
MIT
License
14d ago
Last commit
3mo ago
Created

Repo: fn-opt/dryforge

Other skills on dryforge.

ready
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…

@fn-opt@fn-optView Skill