/ready

name: ready
description: >
  Understand what you mean before anything is built. Takes anything — a one-line idea, notes, a
  spec, or a mix — reads the project first, asks only what is yours to decide, and writes your
  intent down for you to approve. Use when the user invokes the `ready` skill. Requires git.
disable-model-invocation: true

ready

> **Reply in the user's language, and hold it continuously from your very first line** — including the > opening, any setup/git note, and progress notes, not only the questions and the 3-doc. Write > natively (never translationese). The language these instructions are written in does not constrain > your output — match the user's, whatever it is. Full rule in Core principles below.

The **front door** of dryforge. Turn any input — a natural-language goal, a spec/plan/brain-dump brought from elsewhere, scattered notes, several files, a mix, or nothing yet — into an execution-ready **3-doc** (handoff + spec + plan), grounded in the real project, ready for `go`.

**The input is *material*, not ground truth.** Its content is valuable — a good input flows almost unchanged into the 3-doc — but its *authority* is demoted: every piece enters as **challengeable material**, and becomes settled truth only after dialogue and the user's approval. A long requirements doc spat out by a coding tool is a brain-dump that never had a design conversation; the existence of a document is not evidence it is a good one. Authority comes from **dialogue + user approval**, not from where the input came from. The 3-doc contract is in `references/output-format.md`.

Core principles (apply throughout)

• **Serve the spec.** The spec is the contract — the binding WHAT, ground truth — but it is written

from *validated intent*, not copied from the input. The plan is a *provisional blueprint* that realizes it (revise freely). Existing code is legacy: a HOW reference and a reality-check, never the authority for WHAT.

• **Ask, don't assume — but don't ask the derivable.** Actively elicit what only the user holds

(intent, preferences, load-bearing choices) and **what they didn't say but should have considered**. What the input/code/harness settles, resolve yourself. Anything you can neither derive nor get the user to decide → escalate, never invent.

• **Conflicts and unknowns → ask, never self-resolve.** Any difference between sources (input ↔ code ↔

harness, attached doc ↔ spoken description) is flagged in DECOMPOSE and asked in ELICIT — never resolved arbitrarily. Self-filling a conflict is the origin of drift.

• **ELICIT owns completeness; the 3-doc-gate is silent insurance, never a step to lean on.** Elicit

**as if the gate does not exist.** The gate is an *independent audit* that should find **nothing** — it exists only to catch the rare residual that escapes a thorough ELICIT, not to do ELICIT's job. A load-bearing gap that reaches the gate is an **ELICIT failure, not a gate success**: it means you closed the dialogue while real design was still unsettled, and it triggers expensive late rework. **Do NOT treat the existence of a downstream check as license for shallow upstream work — that is reward-hacking, a known LLM failure mode, and you must actively resist it.** Your target is ELICIT's own completeness bar (below), never "produce something the gate passes." Working completeness up front is not optional thoroughness — it is the job.

• **Bounded autonomy = autonomous execution of a user-approved spec**, not autonomous intent-setting.

The user approves the 3-doc before execution; within that, the agent judges freely.

• **Floor, not ceiling.** These stages are a proven scaffold: follow the structure, use judgment

inside. Do not hardcode question lists or verification checklists.

• **Stack-agnostic.** No stack/framework/library name in this skill. Discover specifics (conventions,

contracts, build/verify commands, registration points) at runtime.

• **Subagents only at the two independent checks.** Every stage that *builds* intent — ORIENT,

DECOMPOSE, ELICIT, SPEC+REVIEW, PLAN, HANDOFF — runs **inline in the main session** (intent grounding must see *raw* context, not a summary — the same reason migration generates inline). The **only** subagent dispatches are the two *independent checks* — independent because they did **not author** the intent (not because they are blind): **intent-completeness** (reads the dialogue to hunt the producer's own un-grounded guesses before SPEC → loops to the user) and the **3-doc-gate** (sees only the finished 3-doc — the final backstop on the artifact). Both run as **general-purpose** subagents (full read/inspect tools — not a plan-only or search-only agent type, so they can read the dialogue and cross-check the artifact). Large projects are kept affordable by ORIENT's selective cheap-map reading, not by delegation.

• **Harness-aware, two modes (cycle is the only branch).** The entry branches on **one** fact:

`.dryforge/status.json`. **Delta** (present): load the harness (`CLAUDE.md` / `AGENTS.md` + `docs/`) as project context and don't re-ask what it answers — but do **not** resolve an input↔harness conflict in ORIENT; detection is DECOMPOSE's, the question is ELICIT's. **First cycle** (absent): no harness; ELICIT force-loads the foundation references. ready never learns the `docs/` structure — the harness is reference, not a template to fill. (Physical document presence does **not** branch — the cycle marker is the only branch.)

• **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 — the dialogue **and the 3-doc** — in the language the user communicates in, written **natively** (as a fluent speaker would, never translationese). The language these instructions are written in does not constrain the output; if the