[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MKY8MT4BCWT8JFS12MA20N":3,"skill-same:01M6MKY8MT4BCWT8JFS12MA20N":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":51,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":68},"01M6MKY8MT4BCWT8JFS12MA20N","go",null,"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.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1575,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"prove it","docs","project docs","when","prove","true","you","with","it","as","project","back","intent","ready","never","use","user","work","git","change","2026-11-10 10:12:30",false,"---\nname: go\ndescription: >\n  Carry out the intent approved in `ready`, as meant, and prove it with checks that actually ran.\n  Comes back to you if the work would change what you approved, keeps the project docs in step,\n  and never merges on its own. Use when the user invokes the `go` skill after `ready`. Requires\n  git.\ndisable-model-invocation: true\n---\n\n# go\n\n> **Reply in the user's language, and hold it continuously from your very first line** — the opening,\n> every progress\u002Fescalation note, the final report, and the harness, not only some of them. Write\n> natively (never translationese). You are reading a 3-doc, a codebase, and these instructions that may\n> be in another language; **none of them sets your output language — only the user's does.** Full rule\n> in Core principles below.\n\nConsume the **3-doc** `ready` (the producer) wrote and realize the spec:\nparallel, wave-based execution with right-sized verification (test-first where it fits), spec-first\nreview, and integration gates. Runs in the **same session** the producer (ready) wrote the 3-doc\n— the 3-doc is the **authority** go executes against (it stays self-sufficient because it is archived\nfor later cycles); the live design context carries over and aids judgment, especially the harness\nstep. **Load `references\u002Forchestration.md` up front** (it governs the whole run); the prompt\nreferences load at their steps.\n\n## Core principles (apply throughout)\n\n- **Follow the plan's Execution Graph; never re-judge dependencies.** The producer already computed\n  `depends` + `regen_barriers` against the whole project. Derive waves from it — do not invent,\n  drop, or reorder dependencies. (If the graph fails to parse, has a cycle, or a `depends` names a\n  missing task, that is a producer-side defect — **stop and escalate**, do not silently re-judge.)\n- **Serve the spec.** \"Correct\" = matches the spec. On any spec\u002Fcode\u002Fconvention conflict, spec\n  wins; where plan conflicts with spec, follow the spec.\n- **escalate-don't-guess.** Architecture mismatch, suspected spec violation, ambiguous task,\n  unresolvable conflict → stop and **ask the user**; never guess. When a task returns\n  `NEEDS_CONTEXT` \u002F `BLOCKED`, run the bounded escalation ladder (`orchestration.md` — re-dispatch\n  with the missing context, then a stronger model where the platform allows it, then the user). Any\n  escalation that **reaches the user** is **synchronous** — the run pauses until the user responds,\n  never a silent hang or a timeout-drop. The subagents themselves never ask the user directly (their\n  prompt files carry that fresh-session rule); only the orchestrator relays escalations to the user.\n- **Protect main; evidence over self-report.** For existing projects, never modify main outside the\n  final user-approved merge. For greenfield (base = main), main is the working base — modification\n  is expected. Gates pass on captured command exit codes, not on an agent's \"looks fine.\"\n- **Floor, not ceiling.** The wave lifecycle is a proven scaffold — use judgment inside each step\n  (what to retry, how to fix), but keep the structure and the safety constraints.\n- **Report results, not process.** User-facing text covers wave completion, blockers, and final\n  results only. Internal operations (merge, gate, worktree lifecycle, branch cleanup) produce no\n  text output. Output tokens are direct cost; narrating routine steps is waste.\n- **The orchestrator executes sequential waves directly; only parallel work earns subagents.** A\n  single-task `MECHANICAL`\u002F`NONE` wave is implemented by the orchestrator on the base (dispatch buys\n  nothing — no parallelism, no file-isolation need, and the accumulating context is an asset). Only a\n  **parallel wave** (multiple tasks) or a **single `RISKY` task** is dispatched to subagents (file\n  isolation \u002F independent verification). The lightweight fix path is the orchestrator's other direct-\n  edit path (trivial advisories). A multi-task wave is **collapsed to orchestrator-direct** only on an\n  **objective condition** — a single shared runtime the tasks cannot isolate within (one DB \u002F container\n  \u002F port set), or greenfield convention-drift risk — **not** a free ROI judgment, and the collapse is\n  **recorded internally** (which wave, which condition), never surfaced for a non-technical user to\n  adjudicate. Collapsed tasks still carry the per-task evidence floor and are **reviewed as if\n  independently authored**; the mid-run spec-review (RISKY + downstream + cascade) is still honored\n  (`orchestration.md`, \"ROI collapse\").\n- **Efficiency Budget.** Spend orchestration only where it buys correctness, isolation, or real\n  parallelism — never as ceremony.\n- **The final review is silent insurance — not a backstop you lean on.** Own conformance **upstream**,\n  at implementation and merge, on **captured evidence**. Execute and verify each task **as if the final\n  review did not exist**: a blocking finding there is an **execution failure that escaped**, not the\n  review doing its job — it should normally find nothing. Told \"the review will catch it,\" an LLM\n  drifts to the minimum that passes — that is **reward-hacking**, laziness in the costume of \"the\n  backstop handles it,\" and you must actively resist it (the same discipline ready's ELICIT\n  carries). The review catches only the *rare residual*; it is never the owner.\n- **Match the user's language (language-agnostic).** Like stack-agnosticism, the *method* is fixed\n  and the *specific language* is discovered at runtime, never assumed: produce every user-facing\n  output — your reports\u002Fescalations **and the harness** you create\u002Fupdate — in the language the user\n  communicates in, written **natively** (as a fluent speaker of that language would, never\n  translationese). The language these instructions are written in does not constrain the output; if\n  the user's language shifts, follow. **Hold it from the very first line, continuously** — never open\n  in the 3-doc's, the codebase's, or these instructions' language and switch later; only the user's\n  language constrains your output.\n- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these\n  moments: (a) a question you genuinely need answered, (b) wave completion or the final result \u002F\n  concise summary, (c) a real blocker — **these are the only times user-facing text exists.**\n  Scaffolding, reading the 3-doc\u002Freferences\u002Fcode, implementing, merging, gating, dispatching the\n  review, and writing the harness are **silent**: the UI already shows the activity, so narrating it\n  is pure leak. If what you are about to emit is none of (a)\u002F(b)\u002F(c), the correct output is **nothing**.\n  **Between those beats, stay silent** — reading references, reading code, and internal\n  operations are not narrated. **No transition lines** (\"now I'll...\", \"먼저 ...\", \"let me read...\", \"Now the ...\" announcing each write) — at\n  those plumbing moments your voice slips into the instructions' language (English) or internal tokens;\n  emit *nothing* there, don't translate it. When you *do* speak (a\u002Fb\u002Fc), use a **plain, non-technical\n  register** in the user's language — the words a non-engineer would understand. This is your default\n  voice, not a per-line check, so it costs nothing. **Never surface internal tokens:** dryforge mechanism \u002F coined terms (wave,\n  worktree, harness, delta, 3-doc, gate, seam, ROI collapse, spec-review, grounding, lens,\n  invariant), task \u002F step \u002F risk labels (`T1`, `Wave 2`, RISKY \u002F MECHANICAL \u002F NONE), or\n  project-internal jargon a non-engineer wouldn't recognize (library\u002Ftool names, config flags,\n  test-framework internals). **Don't soften internal logic into user-ish words — just omit it.** E.g.\n  \"Starting a git repo here.\" — not \"Since go will later need git for worktrees, I'll initialize one.\"\n  This is \"Report results, not process\" applied to narration.\n\n## Input & preconditions\n\n- Invocation: the user invokes the `go` skill.\n  Load the 3-doc (handoff → spec → plan) from the project's\n  `.dryforge\u002F` (project-root-relative). If absent, ask for the path.\n- **git required** — worktree isolation depends on it. If not a repo, offer `git init` **and make an\n  initial commit** (an empty repo has no HEAD, so no worktree\u002Fbranch can be created). If git is not\n  installed, stop and say so.\n- **Base determination.** Identify the project's main branch (docs \u002F remote default \u002F ask — do not\n  guess). Verify `main` has no unpushed commits (when it tracks a remote — a purely local repo has\n  nothing unpushed) and the working tree has no modified\u002Fstaged **tracked**\n  files; if either fails, **stop and report**. Then classify:\n  - **Greenfield** (main has no application code — only an init commit, `.gitignore`, or\n    producer-generated `.dryforge\u002F`): **base = main**. No feature branch — there is no production\n    code to protect.\n  - **Existing project** (main has meaningful committed code): **base = feature branch** created\n    from main (`git checkout -b dryforge\u002F\u003Cfeature>`). Protects main from incomplete work.\n  - **`.dryforge\u002F` as untracked files** is the expected handoff state from the producer — do not\n    treat it as a dirty tree. Anything else untracked or modified is foreign work → stop and report.\n  - **You own the `.dryforge\u002F` git mechanics.** On the base, add `.dryforge\u002F` to `.gitignore` and\n    commit. For existing projects this stays on the feature branch (never on main); for greenfield\n    it is on main (acceptable — main has no meaningful history to protect). If a prior run left\n    `.dryforge\u002F` *tracked*, run `git rm -r --cached .dryforge\u002F` first.\n- **Verify commands** — the project's build\u002Ftest\u002Flint commands are typically declared in the handoff\n  (hard gates section) or discovered during scaffold from the project's build scripts. Identify them\n  before the first wave; they are used in every integration gate and the completion gate.\n- Read **handoff first** (it governs: document roles, hard gates, execution shape), then spec and\n  plan. **First-cycle precondition (check now, not at the end):** if this is a first cycle (no\n  `.dryforge\u002Fstatus.json` marker — the discriminator is the marker, not harness files on disk;\n  `harness-lifecycle.md`) and the handoff has **no** Project Foundation section, that is a **precondition violation** —\n  **stop here and ask the user to regenerate the 3-doc via `ready`**, *before* any implementation. Do\n  not discover this at step 9 after a wasted run (`harness-lifecycle.md`). **If the handoff has a Project\n  Foundation section** (first cycle — `references\u002Ffoundation-format.md`), read it as **non-executable\n  project context**: it informs implementation judgment (design the task to fit the project's wider\n  domain\u002Fdecisions) and is a source for the harness at the end — it is *not* an implementation target. Build the spec's task, using the Foundation as context. Parse the\n  plan's Execution Graph **per `references\u002Fgraph-contract.md`** — the consumer-side schema (what the\n  YAML fields mean and the rules go must hold when reading them). It mirrors the producer's authoring\n  schema; if the plan's graph contradicts it, that is a producer-side defect → stop and escalate.\n\n## Graph validation (before any irreversible worktree creation)\n\nValidate the plan's Execution Graph **before creating the base** — it is cheap and safe\nto fail (no git state mutated yet), so catch a malformed graph before any worktree exists to unwind.\nParse the YAML, then confirm the graph is **acyclic**, that every `depends` \u002F `after` id **names a\nreal task** (no dangling reference), and that the plan body and the graph **agree on the task id set**\n(no graph task missing from the plan body, none in the body absent from the graph). `graph-contract.md`\nis the authoritative rule set for these checks. On any failure, **report the specific error** — which\ncheck failed and where (the offending id \u002F cycle \u002F mismatch) — and the recovery: the user fixes the\nplan YAML and invokes dryforge `go` again, which re-validates from scratch (no partial state is left behind,\nsince validation precedes worktree creation).\n\n## Flow\n\nParse the graph → topological sort into waves (batches of **≤8 concurrent**). Set up the **base**\n(per Base determination): for existing projects create the feature branch, for greenfield stay on\nmain. On the base, set up `.dryforge\u002F` (gitignore + commit — the 3-doc is already in place from the\nproducer; same working tree, nothing to copy). The orchestrator reads\n`.dryforge\u002F` here — task subagents do **not**; they receive spec slices inline (`orchestration.md`).\nA task whose declared work targets are **state\u002Fexternal only** (no file diff) is handled on the base\nsequentially, **never dispatched into a parallel worktree** — the file-diff merge-gate cannot verify\nit and worktree isolation buys it nothing (`orchestration.md`, Wave scheduling). Then, per wave:\n\n**Scaffold (inline, before dispatch).** Project initialization — manifests, dependencies, directory\nlayout, build config, server\u002Fclient entry points, shared types — is the orchestrator's job, not a\ntask. On the base, perform scaffold inline: read the spec's tech decisions and set up the project so\nimplementers start in a working skeleton. Scaffold is not in the Execution Graph. **Batch file\nwrites** — scaffold typically creates many independent files; write 4–5 per tool-call turn instead\nof one at a time. Each extra turn adds thinking overhead and an API round-trip. Exception: if scaffold requires **investigation or trial-and-error** to get right (e.g. container\norchestration, CI pipeline configuration, or 30+ files across 3+ workspaces), dispatch it as an\nimplementer before the first wave.\n\n**Review policy (natural language, orchestrator judgment).**\nDefault: a single **final review** after all waves merge — one subagent checks the full diff for\nspec conformance + code quality (`reviewer-prompt.md`), plus the harness (content + format) when it\nwas created\u002Fupdated this cycle (step 9). This replaces per-task spec-review and per-wave code-review\nfor most graphs. Mid-run review is added only when the orchestrator judges\nthat **a RISKY task with downstream dependents could cascade a deviation** — then that task gets a\nspec-review before merge. The judgment comes from the Execution Graph: `risk` + `depends`.\n**Lightweight fix path:** after the final review, the orchestrator MUST triage each advisory finding:\ntrivial (1–2 files, non-behavioral, e.g. a missing `step` attribute, a test warning, a one-line\ncomment) → edit directly on the base, commit, re-run the completion gate. Substantive (structural,\nmulti-file, behavioral) → fix-dispatch subagent. The default is lightweight — only escalate to\nfix-dispatch when the change warrants independent review. Do not skip advisories as \"accepted\"\nwhen a lightweight fix would take seconds.\n\n**Sequential wave** (single task — the common case). Execution mode is set by the task's `risk`\n(full rules in `references\u002Forchestration.md`):\n\n1. **Pick the mode by `risk`.**\n   - **`MECHANICAL` \u002F `NONE` (file-diff task) → orchestrator-direct.** The orchestrator\n     reads the task's behavioral contract + spec slice itself and implements **directly on the base**\n     — no dispatch, no worktree, no prompt authoring. **The same captured-evidence floor that binds a\n     dispatched implementer binds you here** (`implementer-prompt.md`): right-sized but *real*\n     verification (command + **captured** exit code; **real testable behavior left untested = not\n     done**, never a \"right-size\" excuse). Commit on the base. **You own conformance on this path — the\n     final review is insurance, not your check.** If the task proves ambiguous, behavioral, multi-file,\n     or riskier than declared, treat it as a runtime risk upgrade (`graph-contract.md`) and strengthen\n     verification.\n   - **Omitted `risk` (producer did not judge) → unclassified, *not* `MECHANICAL`.** Do **not** default\n     it to the direct path: judge at read time and **bias toward dispatch \u002F stronger verification** the\n     moment any behavioral surface appears (`orchestration.md`, `graph-contract.md` —\n     degrade-don't-corrupt).\n   - **`RISKY` (file-diff task) → one subagent in a worktree** (`implementer-prompt.md`), then\n     **merge-gate** into the base — independent verification, so the final review is not the only\n     check on risky work.\n   - **No-file-diff task (any risk) → base-pinned subagent**, verified by commit message + captured\n     external evidence.\n2. **Collect or record** — for a subagent, keep its structured summary; for orchestrator-direct work,\n   record files changed, commands run, and concerns in the same shape.\n3. **Spec review** (conditional, `spec-review-prompt.md`, **before merge**) — only when the review\n   policy calls for it (RISKY task with downstream dependents): review the task branch's diff before\n   the merge-gate, so a deviation never lands on the base.\n4. **Land + verify** — confirm the commit on the base (`git log`, diff touches declared targets;\n   no-file-diff: commit message + captured external evidence). RISKY worktree: merge-gate into the\n   base. Then run **regen barriers** and **deferred wiring** if applicable, committed on the base.\n   No integration gate — the self-checks on the cumulative base are sufficient for a single-task\n   wave. → next wave.\n\n**Parallel wave** (multiple tasks — worktree isolation required):\n\n0. **Worktree pool** (first parallel wave only) — if the graph has multiple parallel waves,\n   pre-create `max(wave sizes)` worktrees once **under `.dryforge\u002Fworktrees\u002F`**; recycle between waves\n   instead of remove+recreate (see `orchestration.md`). For a single parallel wave, create on demand.\n1. **Create task worktrees** — serially (avoid `.git\u002Fconfig.lock` contention), **under\n   `.dryforge\u002Fworktrees\u002F\u003Ctask-id>`** (inside the gitignored `.dryforge\u002F`, so they never sprawl into\n   the project tree or get tracked), each branched off the base (or reset a pooled worktree to the\n   current base tip). **If the project has an installable dependency tree**, install or share it\n   (sharing guidance in `orchestration.md`).\n2. **Dispatch implementers** — one subagent per task, in parallel, ≤8 at a time\n   (`implementer-prompt.md`): right-sized verification, shared-write constraints, pinned worktree\n   path. Dispatch every implementer and reviewer as a **general-purpose** subagent (full\n   read\u002Fedit\u002Frun tools — never a plan-only or search-only agent type: an implementer must edit and\n   run, a reviewer must read and cross-check).\n3. **Collect** — each returns a structured summary.\n4. **Spec review** (conditional, **before merge**) — only when the review policy calls for it.\n5. **Merge serially** into the base. **Merge-gate per task (objective, not existence-only):** the task\n   branch is strictly **ahead** of the base (`git rev-list base..task` non-empty) AND its diff is\n   non-empty and touches declared targets — checked with three-dot diff (`git diff base...task`).\n   The **merge commit message must satisfy the project's commit-msg hooks**. Then run **regen\n   barriers**, then **deferred wiring** (check-before-append, idempotent; conflicts → escalate) and\n   **commit wiring on the base**.\n6. **Integration gate** — run the project's verify commands on the merged result **after** wiring is\n   committed; **green = exit 0, output captured**. This catches cross-task interactions that no single\n   implementer could see. Failure → analyze → fix-dispatch or escalate.\n7. **Clean up or recycle** task worktrees. If a later parallel wave exists, **recycle** pooled\n   worktrees (`git checkout \u003Cbase-tip> && git reset --hard`) instead of removing. If no later\n   parallel wave needs them, **defer cleanup** to after the completion gate — batch-remove all\n   worktrees at once. Only remove after asserting each task's commit is an ancestor of the base\n   (`git merge-base --is-ancestor`); if not, **do not remove** — escalate. Prefer safe `git worktree\n   remove` (no `--force`). Remove dependency-share symlinks first (slash-less `\u003Cdir>` pattern).\n   Delete merged task branches (`git branch -d`). A failed task's worktree and branch are preserved\n   for diagnosis. After the final batch-remove, also delete the now-empty `.dryforge\u002Fworktrees\u002F`\n   directory and any task temp dirs — `.dryforge\u002F` should hold only the active 3-doc, `NNN\u002F` archives,\n   `status.json`, and `backup\u002F` (no litter). → next wave.\n\n**After all waves:**\n\n8. **Completion gate** — the full verify set on the base. **SHA reuse rule:** if the last parallel\n   wave's integration gate passed, **ran the full verify set** (not the affected-only subset), AND the\n   base tip SHA has not changed since that gate (no lightweight fix, no wiring, no regen committed\n   after it), the completion gate is satisfied by the prior gate's captured result — do not re-run.\n   If any commit landed after the last gate, **or that gate was affected-only**, re-run the full verify set.\n\n9. **Harness create \u002F update** (`references\u002Fharness-lifecycle.md` + `references\u002Fharness-format.md`,\n   force-load). After the completion gate, before the final review: **re-read the 3-doc** (mandatory —\n   the session is now code-biased), then act on the local marker `.dryforge\u002Fstatus.json`:\n   - **First cycle** (marker absent): create the whole harness — CLAUDE.md \u002F AGENTS.md + `docs\u002F` +\n     module AGENTS.md — from the handoff's Project Foundation + spec + code. The Foundation is a\n     **first-cycle invariant** (`ready` always writes it); if a first-cycle handoff has **no\n     Foundation section**, do **not** guess one from spec + code — **stop and ask the user to\n     regenerate the 3-doc via `ready`** (`harness-lifecycle.md`, fail-fast precondition). Back up +\n     critically rework any existing CLAUDE.md \u002F AGENTS.md with user approval.\n   - **Delta** (marker present): update only the changed-scope `docs\u002F` (read all current docs first;\n     escalate an in-scope conflict; new module → new AGENTS.md + navigation-tree update).\n   See `harness-lifecycle.md` for the marker rule and the clobber safety guard.\n   **Write every file silently** — do not announce each file or section as you go (\"Now the docs...\",\n   \"이제 모듈 노트를...\", \"Now the module roadmap note in `X`\"); the UI already shows each write. This\n   multi-file writing sequence is the last place narration leaks — emit nothing between writes.\n\n10. **Final review** — one subagent checks the **full diff on the base** for spec conformance + code\n    quality, **and the harness** (when created\u002Fupdated this cycle) against `references\u002Fharness-review.md`\n    (`reviewer-prompt.md`, four lenses). **Clear = zero blocking findings, recorded.**\n\n11. **Fix if needed** — lightweight fix path for trivial advisories (MUST triage); fix-dispatch\n    substantive findings. Fixes may touch **code or harness**. Re-run per `harness-lifecycle.md`:\n    code changed → re-run completion gate; harness changed → re-run harness review; both → both. A\n    finding about a doc\u002Fcode mismatch **outside this cycle's change scope** is not fixed here — record\n    it in `docs\u002Ftracking\u002Ffindings.md` and defer (scope-limited delta).\n\n12. **User gate.** Present for approval. **First cycle:** present the code result **and** the harness\n    as a reconciliation against the decisions the user took part in — *\"the [X] we agreed is\n    recorded in the harness as [this]\"* — **not** a raw document dump. **Later cycle:** include a\n    harness-change summary in the result report.\n\n13. **Archive (move) + mark.** On approval, **move** the active 3-doc into `.dryforge\u002FNNN\u002F` — copy\n    `.dryforge\u002F{handoff,spec,plan}.md` into the new highest+1 dir, **then delete them from the\n    `.dryforge\u002F` root** (archiving is a move, not a copy — leave no stale active 3-doc at root). Write\n    `.dryforge\u002Fstatus.json` (`{ \"initialized\": true }`) if absent — the local marker that makes the\n    next cycle a delta.\n\n**Advancing waves.** Sequential waves advance immediately after commit verification — no gate to\nwait for. For parallel waves, the next wave's provisioning SHOULD overlap the current wave's\nintegration gate (`orchestration.md`, Advancing waves), but dispatch waits for a green gate.\nFall back to fully serial advance if uncertain.\n\nMechanics, subagent dispatch constraints, status protocol, context budget, and failure handling live in\n`references\u002Forchestration.md`.\n\n## Completion gate (avoid self-judgment A=A)\n\nDone only when ALL hold — on **evidence**, not assertion:\n- every wave merged; every spec requirement traced to a merged task; zero open\n  `BLOCKED` \u002F needs-fix. **\"Zero open BLOCKED\" is not \"counted as done\"** — each BLOCKED task must have\n  **completed escalation to the user** (the user has been told and has resolved its disposition) with\n  its **worktree preserved** for diagnosis; a BLOCKED task may never be silently tallied into \"done\".\n- every `DONE_WITH_CONCERNS` concern **resolved (fix-dispatched) or explicitly accepted and\n  recorded** (at code-review or by the user) — a flagged concern is never silently carried into\n  \"done\".\n- a **final full check** — **all** of the project's verify commands (whatever the stack actually has\n  — e.g. typecheck \u002F lint \u002F test \u002F build, or fewer; including any genuinely expensive end-only step\n  deferred from the per-wave gate) on the integrated base **exit 0, with the commands and\n  exit codes captured and shown** (not \"looks green\"). **Why re-run everything when each wave already\n  passed:** a per-wave gate proves each wave green *in isolation*, but the integrated result can break\n  on **cross-wave interactions** that no single wave's gate could see — so the completion gate re-runs\n  the full verify set against the whole base as the final, all-together check. Running the\n  full verify set every wave is the **safe baseline**; narrowing to an **affected-only** subset is an\n  optional efficiency lever for **intermediate (per-wave) gates only** — never for the completion\n  gate. Affected-only is permitted when the project's test runner supports change-based filtering\n  (e.g. the test runner's change-based filter — `--changed`, `--since`, `--lf`, or equivalent). When\n  using\n  affected-only, record what was skipped so the completion gate's full run covers it. The\n  **completion gate always runs the full verify set** — it is the cross-wave safety net.\n- **runtime smoke** — **in addition to** the verify commands above (which prove the code compiles\n  and tests pass): when the spec declares a running server or service, start it, send one\n  health-check or minimal request, confirm a 2xx response, then stop. A green build proves the\n  code compiles; a runtime smoke proves it boots and responds. Skip only when the project has no\n  runnable server component.\n- **An unevaluable check is a fail, not a pass.** A verify or smoke command counts as green only when\n  its **assertion itself evaluated and reported success** — exit 0 *from the assertion*, or the\n  expected output actually observed. If the assertion could not run (the command errored before\n  asserting, the server never came up, the matched output was empty, the response couldn't be parsed),\n  that is a **failure** — diagnose it, fix the check (or the code), and re-run until the assertion\n  genuinely passes. **Never infer a pass from side-effects** (\"the server logged the request\", \"a file\n  appeared\", \"no error printed\") when the declared assertion did not itself succeed; a check you can't\n  evaluate is not evidence. (This is A=A self-judgment applied to the gate's own evidence — see header.)\n- no residual escalation outstanding — every task that returned `NEEDS_CONTEXT` \u002F `BLOCKED` was\n  resolved through the bounded escalation ladder, and any escalation that **reached the user** was\n  **synchronous** (the orchestrator pauses the run and waits for the user's\n  response — never a silent hang or a timeout-drop). Subagents themselves never ask the user directly\n  (the prompt files carry that fresh-session rule); only the orchestrator relays escalations to the user.\n\n## Finish\n\nAfter the harness step, final review, user approval, and 3-doc archiving (steps 9–13 above):\n\n- **Greenfield (base = main) →** work is already on main. Notify the user that the project is\n  complete on main. No merge needed.\n- **Existing project (base = feature branch) →** ask the user **how to integrate**:\n  - **Merge to main →** fetch and confirm main has not moved (if it has, re-integrate \u002F escalate);\n    merge the feature branch with **`--no-ff`** **from a checkout on the main branch**. **On\n    conflict, abort and escalate.** After confirming the merge, clean up branches.\n  - **Open a PR \u002F push →** push the feature branch; leave integration to the project's review flow.\n  - **Hand off only →** keep the feature branch intact.\n  Never integrate on your own.\n","# go\n\n> **Reply in the user's language, and hold it continuously from your very first line** — the opening,\n> every progress\u002Fescalation note, the final report, and the harness, not only some of them. Write\n> natively (never translationese). You are reading a 3-doc, a codebase, and these instructions that may\n> be in another language; **none of them sets your output language — only the user's does.** Full rule\n> in Core principles below.\n\nConsume the **3-doc** `ready` (the producer) wrote and realize the spec:\nparallel, wave-based execution with right-sized verification (test-first where it fits), spec-first\nreview, and integration gates. Runs in the **same session** the producer (ready) wrote the 3-doc\n— the 3-doc is the **authority** go executes against (it stays self-sufficient because it is archived\nfor later cycles); the live design context carries over and aids judgment, especially the harness\nstep. **Load `references\u002Forchestration.md` up front** (it governs the whole run); the prompt\nreferences load at their steps.\n\n## Core principles (apply throughout)\n\n- **Follow the plan's Execution Graph; never re-judge dependencies.** The producer already computed\n  `depends` + `regen_barriers` against the whole project. Derive waves from it — do not invent,\n  drop, or reorder dependencies. (If the graph fails to parse, has a cycle, or a `depends` names a\n  missing task, that is a producer-side defect — **stop and escalate**, do not silently re-judge.)\n- **Serve the spec.** \"Correct\" = matches the spec. On any spec\u002Fcode\u002Fconvention conflict, spec\n  wins; where plan conflicts with spec, follow the spec.\n- **escalate-don't-guess.** Architecture mismatch, suspected spec violation, ambiguous task,\n  unresolvable conflict → stop and **ask the user**; never guess. When a task returns\n  `NEEDS_CONTEXT` \u002F `BLOCKED`, run the bounded escalation ladder (`orchestration.md` — re-dispatch\n  with the missing context, then a stronger model where the platform allows it, then the user). Any\n  escalation that **reaches the user** is **synchronous** — the run pauses until the user responds,\n  never a silent hang or a timeout-drop. The subagents themselves never ask the user directly (their\n  prompt files carry that fresh-session rule); only the orchestrator relays escalations to the user.\n- **Protect main; evidence over self-report.** For existing projects, never modify main outside the\n  final user-approved merge. For greenfield (base = main), main is the working base — modification\n  is expected. Gates pass on captured command exit codes, not on an agent's \"looks fine.\"\n- **Floor, not ceiling.** The wave lifecycle is a proven scaffold — use judgment inside each step\n  (what to retry, how to fix), but keep the structure and the safety constraints.\n- **Report results, not process.** User-facing text covers wave completion, blockers, and final\n  results only. Internal operations (merge, gate, worktree lifecycle, branch cleanup) produce no\n  text output. Output tokens are direct cost; narrating routine steps is waste.\n- **The orchestrator executes sequential waves directly; only parallel work earns subagents.** A\n  single-task `MECHANICAL`\u002F`NONE` wave is implemented by the orchestrator on the base (dispatch buys\n  nothing — no parallelism, no file-isolation need, and the accumulating context is an asset). Only a\n  **parallel wave** (multiple tasks) or a **single `RISKY` task** is dispatched to subagents (file\n  isolation \u002F independent verification). The lightweight fix path is the orchestrator's other direct-\n  edit path (trivial advisories). A multi-task wave is **collapsed to orchestrator-direct** only on an\n  **objective condition** — a single shared runtime the tasks cannot isolate within (one DB \u002F container\n  \u002F port set), or greenfield convention-drift risk — **not** a free ROI judgment, and the collapse is\n  **recorded internally** (which wave, which condition), never surfaced for a non-technical user to\n  adjudicate. Collapsed tasks still carry the per-task evidence floor and are **reviewed as if\n  independently authored**; the mid-run spec-review (RISKY + downstream + cascade) is still honored\n  (`orchestration.md`, \"ROI collapse\").\n- **Efficiency Budget.** Spend orchestration only where it buys correctness, isolation, or real\n  parallelism — never as ceremony.\n- **The final review is silent insurance — not a backstop you lean on.** Own conformance **upstream**,\n  at implementation and merge, on **captured evidence**. Execute and verify each task **as if the final\n  review did not exist**: a blocking finding there is an **execution failure that escaped**, not the\n  review doing its job — it should normally find nothing. Told \"the review will catch it,\" an LLM\n  drifts to the minimum that passes — that is **reward-hacking**, laziness in the costume of \"the\n  backstop handles it,\" and you must actively resist it (the same discipline ready's ELICIT\n  carries). The review catches only the *rare residual*; it is never the owner.\n- **Match the user's language (language-agnostic).** Like stack-agnosticism, the *method* is fixed\n  and the *specific language* is discovered at runtime, never assumed: produce every user-facing\n  output — your reports\u002Fescalations **and the harness** you create\u002Fupdate — in the language the user\n  communicates in, written **natively** (as a fluent speaker of that language would, never\n  translationese). The language these instructions are written in does not constrain the output; if\n  the user's language shifts, follow. **Hold it from the very first line, continuously** — never open\n  in the 3-doc's, the codebase's, or these instructions' language and switch later; only the user's\n  language constrains your output.\n- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these\n  moments: (a) a question you genuinely need answered, (b) wave completion or the final result \u002F\n  concise summary, (c) a real blocker — **these are the only times user-facing text exists.**\n  Scaffolding, reading the 3-doc\u002Freferences\u002Fcode, implementing, merging, gating, dispatching the\n  review, and writing the harness are **silent**: the UI already shows the activity, so narrating it\n  is pure leak. If what you are about to emit is none of (a)\u002F(b)\u002F(c), the correct output is **nothing**.\n  **Between those beats, stay silent** — reading references, reading code, and internal\n  operations are not narrated. **No transition lines** (\"now I'll...\", \"먼저 ...\", \"let me read...\", \"Now the ...\" announcing each write) — at\n  those plumbing moments your voice slips into the instructions' language (English) or internal tokens;\n  emit *nothing* there, don't translate it. When you *do* speak (a\u002Fb\u002Fc), use a **plain, non-technical\n  register** in the user's language — the words a non-engineer would understand. This is your default\n  voice, not a per-line check, so it costs nothing. **Never surface internal tokens:** dryforge mechanism \u002F coined terms (wave,\n  worktree, harness, delta, 3-doc, gate, seam, ROI collapse, spec-review, grounding, lens,\n  invariant), task \u002F step \u002F risk labels (`T1`, `Wave 2`, RISKY \u002F MECHANICAL \u002F NONE), or\n  project-internal jargon a non-engineer wouldn't recognize (library\u002Ftool names, config flags,\n  test-framework internals). **Don't soften internal logic into user-ish words — just omit it.** E.g.\n  \"Starting a git repo here.\" — not \"Since go will later need git for worktrees, I'll initialize one.\"\n  This is \"Report results, not process\" applied to narration.\n\n## Input & preconditions\n\n- Invocation: the user invokes the `go` skill.\n  Load the 3-doc (handoff → spec → plan) from the project's\n  `.dryforge\u002F` (project-root-relative). If absent, ask for the path.\n- **git required** — worktree isolation depends on it. If not a repo, offer `git init` **and make an\n  initial commit** (an empty repo has no HEAD, so no worktree\u002Fbranch can be created). If git is not\n  installed, stop and say so.\n- **Base determination.** Identify the project's main branch (docs \u002F remote default \u002F ask — do not\n  guess). Verify `main` has no unpushed commits (when it tracks a remote — a purely local repo has\n  nothing unpushed) and the working tree has no modified\u002Fstaged **tracked**\n  files; if either fails, **stop and report**. Then classify:\n  - **Greenfield** (main has no application code — only an init commit, `.gitignore`, or\n    producer-generated `.dryforge\u002F`): **base = main**. No feature branch — there is no production\n    code to protect.\n  - **Existing project** (main has meaningful committed code): **base = feature branch** created\n    from main (`git checkout -b dryforge\u002F\u003Cfeature>`). Protects main from incomplete work.\n  - **`.dryforge\u002F` as untracked files** is the expected handoff state from the producer — do not\n    treat it as a dirty tree. Anything else untracked or modified is foreign work → stop and report.\n  - **You own the `.dryforge\u002F` git mechanics.** On the base, add `.dryforge\u002F` to `.gitignore` and\n    commit. For existing projects this stays on the feature branch (never on main); for greenfield\n    it is on main (acceptable — main has no meaningful history to protect). If a prior run left\n    `.dryforge\u002F` *tracked*, run `git rm -r --cached .dryforge\u002F` first.\n- **Verify commands** — the project's build\u002Ftest\u002Flint commands are typically declared in the handoff\n  (hard gates section) or discovered during scaffold from the project's build scripts. Identify them\n  before the first wave; they are used in every integration gate and the completion gate.\n- Read **handoff first** (it governs: document roles, hard gates, execution shape), then spec and\n  plan. **First-cycle precondition (check now, not at the end):** if this is a first cycle (no\n  `.dryforge\u002Fstatus.json` marker — the discriminator is the marker, not harness files on disk;\n  `harness-lifecycle.md`) and the handoff has **no** Project Foundation section, that is a **precondition violation** —\n  **stop here and ask the user to regenerate the 3-doc via `ready`**, *before* any implementation. Do\n  not discover this at step 9 after a wasted run (`harness-lifecycle.md`). **If the handoff has a Project\n  Foundation section** (first cycle — `references\u002Ffoundation-format.md`), read it as **non-executable\n  project context**: it informs implementation judgment (design the task to fit the project's wider\n  domain\u002Fdecisions) and is a source for the harness at the end — it is *not* an implementation target. Build the spec's task, using the Foundation as context. Parse the\n  plan's Execution Graph **per `references\u002Fgraph-contract.md`** — the consumer-side schema (what the\n  YAML fields mean and the rules go must hold when reading them). It mirrors the producer's authoring\n  schema; if the plan's graph contradicts it, that is a producer-side defect → stop and escalate.\n\n## Graph validation (before any irreversible worktree creation)\n\nValidate the plan's Execution Graph **before creating the base** — it is cheap and safe\nto fail (no git state mutated yet), so catch a malformed graph before any worktree exists to unwind.\nParse the YAML, then confirm the graph is **acyclic**, that every `depends` \u002F `after` id **names a\nreal task** (no dangling reference), and that the plan body and the graph **agree on the task id set**\n(no graph task missing from the plan body, none in the body absent from the graph). `graph-contract.md`\nis the authoritative rule set for these checks. On any failure, **report the specific error** — which\ncheck failed and where (the offending id \u002F cycle \u002F mismatch) — and the recovery: the user fixes the\nplan YAML and invokes dryforge `go` again, which re-validates from scratch (no partial state is left behind,\nsince validation precedes worktree creation).\n\n## Flow\n\nParse the graph → topological sort into waves (batches of **≤8 concurrent**). Set up the **base**\n(per Base determination): for existing projects create the feature branch, for greenfield stay on\nmain. On the base, set up `.dryforge\u002F` (gitignore + commit — the 3-doc is already in place from the\nproducer; same working tree, nothing to copy). The orchestrator reads\n`.dryforge\u002F` here — task subagents do **not**; they receive spec slices inline (`orchestration.md`).\nA task whose declared work targets are **state\u002Fexternal only** (no file diff) is handled on the base\nsequentially, **never dispatched into a parallel worktree** — the file-diff merge-gate cannot verify\nit and worktree isolation buys it nothing (`orchestration.md`, Wave scheduling). Then, per wave:\n\n**Scaffold (inline, before dispatch).** Project initialization — manifests, dependencies, directory\nlayout, build config, server\u002Fclient entry points, shared types — is the orchestrator's job, not a\ntask. On the base, perform scaffold inline: read the spec's tech decisions and set up the project so\nimplementers start in a working skeleton. Scaffold is not in the Execution Graph. **Batch file\nwrites** — scaffold typically creates many independent files; write 4–5 per tool-call turn instead\nof one at a time. Each extra turn adds thinking overhead and an API round-trip. Exception: if scaffold requires **investigation or trial-and-error** to get right (e.g. container\norchestration, CI pipeline configuration, or 30+ files across 3+ workspaces), dispatch it as an\nimplementer before the first wave.\n\n**Review policy (natural language, orchestrator judgment).**\nDefault: a single **final review** after all waves merge — one subagent checks the full diff for\nspec conformance + code quality (`reviewer-prompt.md`), plus the harness (content + format) when it\nwas created\u002Fupdated this cycle (step 9). This replaces per-task spec-review and per-wave code-review\nfor most graphs. Mid-run review is added only when the orchestrator judges\nthat **a RISKY task with downstream dependents could cascade a deviation** — then that task gets a\nspec-review before merge. The judgment comes from the Execution Graph: `risk` + `depends`.\n**Lightweight fix path:** after the final review, the orchestrator MUST triage each advisory finding:\ntrivial (1–2 files, non-behavioral, e.g. a missing `step` attribute, a test warning, a one-line\ncomment) → edit directly on the base, commit, re-run the completion gate. Substantive (structural,\nmulti-file, behavioral) → fix-dispatch subagent. The default is lightweight — only escalate to\nfix-dispatch when the change warrants independent review. Do not skip advisories as \"accepted\"\nwhen a lightweight fix would take seconds.\n\n**Sequential wave** (single task — the common case). Execution mode is set by the task's `risk`\n(full rules in `references\u002Forchestration.md`):\n\n1. **Pick the mode by `risk`.**\n   - **`MECHANICAL` \u002F `NONE` (file-diff task) → orchestrator-direct.** The orchestrator\n     reads the task's behavioral contract + spec slice itself and implements **directly on the base**\n     — no dispatch, no worktree, no prompt authoring. **The same captured-evidence floor that binds a\n     dispatched implementer binds you here** (`implementer-prompt.md`): right-sized but *real*\n     verification (command + **captured** exit code; **real testable behavior left untested = not\n     done**, never a \"right-size\" excuse). Commit on the base. **You own conformance on this path — the\n     final review is insurance, not your check.** If the task proves ambiguous, behavioral, multi-file,\n     or riskier than declared, treat it as a runtime risk upgrade (`graph-contract.md`) and strengthen\n     verification.\n   - **Omitted `risk` (producer did not judge) → unclassified, *not* `MECHANICAL`.** Do **not** default\n     it to the direct path: judge at read time and **bias toward dispatch \u002F stronger verification** the\n     moment any behavioral surface appears (`orchestration.md`, `graph-contract.md` —\n     degrade-don't-corrupt).\n   - **`RISKY` (file-diff task) → one subagent in a worktree** (`implementer-prompt.md`), then\n     **merge-gate** into the base — independent verification, so the final review is not the only\n     check on risky work.\n   - **No-file-diff task (any risk) → base-pinned subagent**, verified by commit message + captured\n     external evidence.\n2. **Collect or record** — for a subagent, keep its structured summary; for orchestrator-direct work,\n   record files changed, commands run, and concerns in the same shape.\n3. **Spec review** (conditional, `spec-review-prompt.md`, **before merge**) — only when the review\n   policy calls for it (RISKY task with downstream dependents): review the task branch's diff before\n   the merge-gate, so a deviation never lands on the base.\n4. **Land + verify** — confirm the commit on the base (`git log`, diff touches declared targets;\n   no-file-diff: commit message + captured external evidence). RISKY worktree: merge-gate into the\n   base. Then run **regen barriers** and **deferred wiring** if applicable, committed on the base.\n   No integration gate — the self-checks on the cumulative base are sufficient for a single-task\n   wave. → next wave.\n\n**Parallel wave** (multiple tasks — worktree isolation required):\n\n0. **Worktree pool** (first parallel wave only) — if the graph has multiple parallel waves,\n   pre-create `max(wave sizes)` worktrees once **under `.dryforge\u002Fworktrees\u002F`**; recycle between waves\n   instead of remove+recreate (see `orchestration.md`). For a single parallel wave, create on demand.\n1. **Create task worktrees** — serially (avoid `.git\u002Fconfig.lock` contention), **under\n   `.dryforge\u002Fworktrees\u002F\u003Ctask-id>`** (inside the gitignored `.dryforge\u002F`, so they never sprawl into\n   the project tree or get tracked), each branched off the base (or reset a pooled worktree to the\n   current base tip). **If the project has an installable dependency tree**, install or share it\n   (sharing guidance in `orchestration.md`).\n2. **Dispatch implementers** — one subagent per task, in parallel, ≤8 at a time\n   (`implementer-prompt.md`): right-sized verification, shared-write constraints, pinned worktree\n   path. Dispatch every implementer and reviewer as a **general-purpose** subagent (full\n   read\u002Fedit\u002Frun tools — never a plan-only or search-only agent type: an implementer must edit and\n   run, a reviewer must read and cross-check).\n3. **Collect** — each returns a structured summary.\n4. **Spec review** (conditional, **before merge**) — only when the review policy calls for it.\n5. **Merge serially** into the base. **Merge-gate per task (objective, not existence-only):** the task\n   branch is strictly **ahead** of the base (`git rev-list base..task` non-empty) AND its diff is\n   non-empty and touches declared targets — checked with three-dot diff (`git diff base...task`).\n   The **merge commit message must satisfy the project's commit-msg hooks**. Then run **regen\n   barriers**, then **deferred wiring** (check-before-append, idempotent; conflicts → escalate) and\n   **commit wiring on the base**.\n6. **Integration gate** — run the project's verify commands on the merged result **after** wiring is\n   committed; **green = exit 0, output captured**. This catches cross-task interactions that no single\n   implementer could see. Failure → analyze → fix-dispatch or escalate.\n7. **Clean up or recycle** task worktrees. If a later parallel wave exists, **recycle** pooled\n   worktrees (`git checkout \u003Cbase-tip> && git reset --hard`) instead of removing. If no later\n   parallel wave needs them, **defer cleanup** to after the completion gate — batch-remove all\n   worktrees at once. Only remove after asserting each task's commit is an ancestor of the base\n   (`git merge-base --is-ancestor`); if not, **do not remove** — escalate. Prefer safe `git worktree\n   remove` (no `--force`). Remove dependency-share symlinks first (slash-less `\u003Cdir>` pattern).\n   Delete merged task branches (`git branch -d`). A failed task's worktree and branch are preserved\n   for diagnosis. After the final batch-remove, also delete the now-empty `.dryforge\u002Fworktrees\u002F`\n   directory and any task temp dirs — `.dryforge\u002F` should hold only the active 3-doc, `NNN\u002F` archives,\n   `status.json`, and `backup\u002F` (no litter). → next wave.\n\n**After all waves:**\n\n8. **Completion gate** — the full verify set on the base. **SHA reuse rule:** if the last parallel\n   wave's integration gate passed, **ran the full verify set** (not the affected-only subset), AND the\n   base tip SHA has not changed since that gate (no lightweight fix, no wiring, no regen committed\n   after it), the completion gate is satisfied by the prior gate's captured result — do not re-run.\n   If any commit landed after the last gate, **or that gate was affected-only**, re-run the full verify set.\n\n9. **Harness create \u002F update** (`references\u002Fharness-lifecycle.md` + `references\u002Fharness-format.md`,\n   force-load). After the completion gate, before the final review: **re-read the 3-doc** (mandatory —\n   the session is now code-biased), then act on the local marker `.dryforge\u002Fstatus.json`:\n   - **First cycle** (marker absent): create the whole harness — CLAUDE.md \u002F AGENTS.md + `docs\u002F` +\n     module AGENTS.md — from the handoff's Project Foundation + spec + code. The Foundation is a\n     **first-cycle invariant** (`ready` always writes it); if a first-cycle handoff has **no\n     Foundation section**, do **not** guess one from spec + code — **stop and ask the user to\n     regenerate the 3-doc via `ready`** (`harness-lifecycle.md`, fail-fast precondition). Back up +\n     critically rework any existing CLAUDE.md \u002F AGENTS.md with user approval.\n   - **Delta** (marker present): update only the changed-scope `docs\u002F` (read all current docs first;\n     escalate an in-scope conflict; new module → new AGENTS.md + navigation-tree update).\n   See `harness-lifecycle.md` for the marker rule and the clobber safety guard.\n   **Write every file silently** — do not announce each file or section as you go (\"Now the docs...\",\n   \"이제 모듈 노트를...\", \"Now the module roadmap note in `X`\"); the UI already shows each write. This\n   multi-file writing sequence is the last place narration leaks — emit nothing between writes.\n\n10. **Final review** — one subagent checks the **full diff on the base** for spec conformance + code\n    quality, **and the harness** (when created\u002Fupdated this cycle) against `references\u002Fharness-review.md`\n    (`reviewer-prompt.md`, four lenses). **Clear = zero blocking findings, recorded.**\n\n11. **Fix if needed** — lightweight fix path for trivial advisories (MUST triage); fix-dispatch\n    substantive findings. Fixes may touch **code or harness**. Re-run per `harness-lifecycle.md`:\n    code changed → re-run completion gate; harness changed → re-run harness review; both → both. A\n    finding about a doc\u002Fcode mismatch **outside this cycle's change scope** is not fixed here — record\n    it in `docs\u002Ftracking\u002Ffindings.md` and defer (scope-limited delta).\n\n12. **User gate.** Present for approval. **First cycle:** present the code result **and** the harness\n    as a reconciliation against the decisions the user took part in — *\"the [X] we agreed is\n    recorded in the harness as [this]\"* — **not** a raw document dump. **Later cycle:** include a\n    harness-change summary in the result report.\n\n13. **Archive (move) + mark.** On approval, **move** the active 3-doc into `.dryforge\u002FNNN\u002F` — copy\n    `.dryforge\u002F{handoff,spec,plan}.md` into the new highest+1 dir, **then delete them from the\n    `.dryforge\u002F` root** (archiving is a move, not a copy — leave no stale active 3-doc at root). Write\n    `.dryforge\u002Fstatus.json` (`{ \"initialized\": true }`) if absent — the local marker that makes the\n    next cycle a delta.\n\n**Advancing waves.** Sequential waves advance immediately after commit verification — no gate to\nwait for. For parallel waves, the next wave's provisioning SHOULD overlap the current wave's\nintegration gate (`orchestration.md`, Advancing waves), but dispatch waits for a green gate.\nFall back to fully serial advance if uncertain.\n\nMechanics, subagent dispatch constraints, status protocol, context budget, and failure handling live in\n`references\u002Forchestration.md`.\n\n## Completion gate (avoid self-judgment A=A)\n\nDone only when ALL hold — on **evidence**, not assertion:\n- every wave merged; every spec requirement traced to a merged task; zero open\n  `BLOCKED` \u002F needs-fix. **\"Zero open BLOCKED\" is not \"counted as done\"** — each BLOCKED task must have\n  **completed escalation to the user** (the user has been told and has resolved its disposition) with\n  its **worktree preserved** for diagnosis; a BLOCKED task may never be silently tallied into \"done\".\n- every `DONE_WITH_CONCERNS` concern **resolved (fix-dispatched) or explicitly accepted and\n  recorded** (at code-review or by the user) — a flagged concern is never silently carried into\n  \"done\".\n- a **final full check** — **all** of the project's verify commands (whatever the stack actually has\n  — e.g. typecheck \u002F lint \u002F test \u002F build, or fewer; including any genuinely expensive end-only step\n  deferred from the per-wave gate) on the integrated base **exit 0, with the commands and\n  exit codes captured and shown** (not \"looks green\"). **Why re-run everything when each wave already\n  passed:** a per-wave gate proves each wave green *in isolation*, but the integrated result can break\n  on **cross-wave interactions** that no single wave's gate could see — so the completion gate re-runs\n  the full verify set against the whole base as the final, all-together check. Running the\n  full verify set every wave is the **safe baseline**; narrowing to an **affected-only** subset is an\n  optional efficiency lever for **intermediate (per-wave) gates only** — never for the completion\n  gate. Affected-only is permitted when the project's test runner supports change-based filtering\n  (e.g. the test runner's change-based filter — `--changed`, `--since`, `--lf`, or equivalent). When\n  using\n  affected-only, record what was skipped so the completion gate's full run covers it. The\n  **completion gate always runs the full verify set** — it is the cross-wave safety net.\n- **runtime smoke** — **in addition to** the verify commands above (which prove the code compiles\n  and tests pass): when the spec declares a running server or service, start it, send one\n  health-check or minimal request, confirm a 2xx response, then stop. A green build proves the\n  code compiles; a runtime smoke proves it boots and responds. Skip only when the project has no\n  runnable server component.\n- **An unevaluable check is a fail, not a pass.** A verify or smoke command counts as green only when\n  its **assertion itself evaluated and reported success** — exit 0 *from the assertion*, or the\n  expected output actually observed. If the assertion could not run (the command errored before\n  asserting, the server never came up, the matched output was empty, the response couldn't be parsed),\n  that is a **failure** — diagnose it, fix the check (or the code), and re-run until the assertion\n  genuinely passes. **Never infer a pass from side-effects** (\"the server logged the request\", \"a file\n  appeared\", \"no error printed\") when the declared assertion did not itself succeed; a check you can't\n  evaluate is not evidence. (This is A=A self-judgment applied to the gate's own evidence — see header.)\n- no residual escalation outstanding — every task that returned `NEEDS_CONTEXT` \u002F `BLOCKED` was\n  resolved through the bounded escalation ladder, and any escalation that **reached the user** was\n  **synchronous** (the orchestrator pauses the run and waits for the user's\n  response — never a silent hang or a timeout-drop). Subagents themselves never ask the user directly\n  (the prompt files carry that fresh-session rule); only the orchestrator relays escalations to the user.\n\n## Finish\n\nAfter the harness step, final review, user approval, and 3-doc archiving (steps 9–13 above):\n\n- **Greenfield (base = main) →** work is already on main. Notify the user that the project is\n  complete on main. No merge needed.\n- **Existing project (base = feature branch) →** ask the user **how to integrate**:\n  - **Merge to main →** fetch and confirm main has not moved (if it has, re-integrate \u002F escalate);\n    merge the feature branch with **`--no-ff`** **from a checkout on the main branch**. **On\n    conflict, abort and escalate.** After confirming the merge, clean up branches.\n  - **Open a PR \u002F push →** push the feature branch; leave integration to the project's review flow.\n  - **Hand off only →** keep the feature branch intact.\n  Never integrate on your own.\n",{"name":5,"description":44,"disable-model-invocation":45},"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.\n",true,"main","f620abaff09061f8c8b1f1559dca3fdd031a32e5","plugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo",491,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-14 14:06:13",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":45},[58,61,64],{"tool":59,"command":60},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill go",{"tool":62,"command":63},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill go",{"tool":65,"command":66},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill go","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002FSKILL.md",[69,75,79,83,87,91,95,99,103],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Ffoundation-format.md","REFERENCE","参考文档",5425,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Ffoundation-format.md",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fgraph-contract.md",4543,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fgraph-contract.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fharness-format.md",29474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fharness-format.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fharness-lifecycle.md",6763,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fharness-lifecycle.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fharness-review.md",7444,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fharness-review.md",{"path":92,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fimplementer-prompt.md",5839,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fimplementer-prompt.md",{"path":96,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Forchestration.md",25403,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Forchestration.md",{"path":100,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Freviewer-prompt.md",3503,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Freviewer-prompt.md",{"path":104,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fspec-review-prompt.md",2589,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fprekuter\u002Fdryforge\u002Fskills\u002Fgo\u002Freferences\u002Fspec-review-prompt.md",[108,116,123,130,152,175],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":115},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":115},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":115},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":39},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[137,138,33,139,32,140,141,142,143,144,145,22,25,146,147,148,38,149,150,151],"search","deja search","error","memory","re","decide","fix","design","debugging","done","reviewer","io","cli","merge","past",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":39},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[159,160,161,148,26,162,163,164,165,166,167,168,169,170,140,171,29,172,173,174],"deja reflect","reflect","review","record","github","next","https","node","Rules","decisions","brew","remember","project rules","session","end","reflection",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":192,"publishedAt":39},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[181,186,189],{"categoryNo":182,"categoryName":183,"taxonomyType":184,"taxonomyTypeDesc":185},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",{"categoryNo":187,"categoryName":188,"taxonomyType":184,"taxonomyTypeDesc":185},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":190,"categoryName":191,"taxonomyType":184,"taxonomyTypeDesc":185},"01JBSEEDCAT000000000000010","后端与接口",[177,193,194,195,196,197,198,29,199,141,200,201,202,203,22,204,205,206,207,208],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]