migration

# migration

> **Reply in the user's language, and hold it continuously from your very first line** — the opening,
> every grounding/progress note, the questions, and the harness, not only some of them. Write natively
> (never translationese). You are reading a codebase (and these instructions) that may be in another
> language; **neither sets your output language — only the user's does.** Full rule in Core principles below.

Convert an existing project into the dryforge **project harness** — the durable documentation layer
that every later agent (dryforge or not) works inside. migration reads the codebase, elicits the
intent/constraints/decisions that code cannot express, and generates the whole harness:
`CLAUDE.md` / `AGENTS.md`, the `docs/` set, and a per-module `AGENTS.md`. The harness spec is in
`references/harness-format.md`.

migration is a **one-time conversion**, not a task runner. It writes documentation only — it does
**not** create a 3-doc (that is `ready`'s job) and does **not** execute code (that is `go`'s).
After it finishes, commit the harness and clear the session before running `ready` → `go`:
migration is an independent piece of work, and a fresh session keeps the task-level dialogue clean.

## Core principles (apply throughout)

- **The harness is durable project memory, not ground truth.** It is the project's discipline and
  constraint — written so the next agent works the project without going off the rails. A hollow
  harness (structure present, content empty) is worse than none.
- **Content density is the whole point.** Every file must clear the quality bar in
  `references/harness-format.md` (five principles, four techniques). Filling sections is not the
  goal; informing the next agent is.
- **Knowledge asymmetry drives elicitation.** Domain knowledge lives with the user — *extract* it
  (don't fabricate). Technical knowledge lives with you — *present* options + trade-offs and let the
  user decide. Don't accept the user's generalities as-is, and don't concretize them alone.
- **Subagents only at the final REVIEW.** SCAN, ELICIT, and GENERATE run inline in the main session —
  generation needs the live conversation's *raw* grounding, not a summary. **REVIEW is the exception:**
  the finished harness is verified by **one independent subagent that did not author it.** Self-judging
  your own harness is the weakest move (A=A), and the harness is the **most
  durable artifact in the system** (every later agent works inside it), so it earns the one fresh-eye
  check — the same relaxation `ready` made (generate inline, verify independently). This is the *only*
  dispatch.
- **Stack-agnostic.** No stack/framework/library name in this skill. Discover all specifics
  (conventions, module boundaries, build/verify commands, external deps) at runtime from the project.
- **escalate-don't-guess.** What the code can't settle and you can't derive, ask the user — never
  invent a domain rule, a policy, or a rationale.
- **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 whole harness** (CLAUDE.md / AGENTS.md, docs/, module AGENTS.md) —
  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 codebase's or these instructions' language and switch later. The language of the
  code you read does **not** constrain your output; only the user's does.
- **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 final walk-through / result, (c) a real
  blocker — **these are the only times user-facing text exists.** SCAN, GENERATE, REVIEW, and any fix
  loop are **silent phases**: the UI already shows the file/command activity, so narrating it is pure
  leak. If what you are about to emit is none of (a)/(b)/(c), the correct output is **nothing**.
  **Between those beats, stay silent** — reading references, reading code, and internal
  operations are not narrated. **No transition lines** ("now I'll…", "먼저 …", "let me read…", "Now the …" announcing each write) — at
  those plumbing moments your voice slips into the instructions' language (English) or internal tokens;
  emit *nothing* there, don't translate it. When you *do* speak (a/b/c), use a **plain, non-technical
  register** in the user's language — the words a non-engineer would understand. This is your default
  voice, not a per-line check, so it costs nothing. **Never surface internal tokens:** dryforge mechanism / coined terms (harness,
  ledger, decision surface, grounding, lens, invariant, `.dryforge`), phase / step labels (SCAN /
  ELICIT / GENERATE / REVIEW), or project-internal jargon a non-engineer wouldn't recognize
  (library/tool names, config flags, test-framework internals). **Don't soften internal logic into
  user-ish words — just omit it.** E.g. "Starting a git repo here." — not "Initializing git and adding
  the marker directory to `.gitignore` so the harness state isn't committed."

## Input & preconditions

- Invocation: the user invokes the `migration` skill, no arguments — migration reads the **current
  project**.
- **Existing codebase expected.** migration converts a project that already has code. For a
  greenfield project (no code yet), there is nothing to migrate — direct the user to `ready` (which
  designs the project's first cycle and lets `go` create the harness from scratch).
- **git required.** If the project is not a git repo, offer to run `git init` **and make an initial
  commit** (later `go` needs a HEAD for worktrees). If git is not installed, stop and sa