ready

# 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 is inline-only). 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 user's language shifts, follow. **Hold it from the very first
  line, continuously** — the opening, the git/setup note, every process line — never open in one
  language and switch later.
- **Talk to the user only when needed — between beats, say nothing.** You speak at **exactly** these
  moments: (a) a question you genuinely need answered, (b) the