/migration

name: migration
description: >
  Bring an existing codebase into Dryforge, once. Reads the code, asks what code cannot show —
  business rules, security policy, what is intentional — and writes the project docs at the entry
  points agents already read. Use when the user invokes the `migration` skill on an existing
  project. Requires git.
disable-model-invocation: true

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