Dryforge plugin

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

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