Skip to content
Code Review
Skill

/go

Carry out the intent approved in `ready`, as meant, and prove it with checks that actually ran. Comes back to you if the work would change what you approved, keeps the project docs in step, and never merges on its own. Use when the user invokes the `go` skill after `ready`.

BOOST
From plugin
prekuter-dryforge-2
4213 skills
Install
$ npx -y skills add prekuter/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.

Carry out the intent approved in `ready`, as meant, and prove it with checks that actually ran. Comes back to you if the work would change what you approved, keeps the project docs in step, and never merges on its own. Use when the user invokes the `go` skill after `ready`.

SKILL.md

go.SKILL.md
name: go
description: >
  Carry out the intent approved in `ready`, as meant, and prove it with checks that actually ran.
  Comes back to you if the work would change what you approved, keeps the project docs in step,
  and never merges on its own. Use when the user invokes the `go` skill after `ready`. Requires
  git.
disable-model-invocation: true

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 a stronger model where the platform allows it, 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 instructi

Read more
Ships withprekuter-dryforge-2

Claude Code Install: Update: Auto-update: off by default. Turn it on in /plugin → Marketplaces → dryforge → Enable auto-update. Codex Install: Update: Auto-update: on. New releases load at the start of each session. Grok Build Install: Update: Auto-update: on.

Get the whole plugin
Stats
422
Stars
40
Forks
Active
Maintenance
Python
Language
Apache-2.0
License
2d ago
Last commit
4mo ago
Created
1d ago
Added

Repo: prekuter/dryforge

Other skills on prekuter-dryforge-2.