Rite adopt

/rite-adopt: onboard existing code

/rite-adopt derives a spec and initial conventions from existing code. It produces the same spec.md used by the rest of the lifecycle and seeds the conventions ledger with observed project idioms.

Use it once when onboarding a repository or one of its sub-areas. Continue with /rite-clarify, /rite-temper, /rite-define, and /rite-build.

Need only a code map? /rite-zoom-out maps unfamiliar code without creating a workspace or ledger. Use /rite-adopt when the project should enter the lifecycle.

Rules consulted (read on demand from .claude/skills/devrites-lib/reference/standards/)

Pull documentation.md when recording the adoption decisions (why-not-what) in decisions.md; pull principles.md when the code upholds invariants worth proposing as project principles (step 4a).

Operating rules (DevRites core)

• No silent assumptions · prefer the project's existing conventions (you are documenting them, not imposing new ones) · ask the human when the adoption scope or the next-build objective is unclear.

Workflow

0. Read .claude/skills/devrites-lib/reference/standards/core.md, then run devrites-engine preamble for deterministic workspace orientation.
1. Scope the adoption ($ARGUMENTS). Which repo or sub-area is being onboarded, and: if stated: what the user wants to build next on top of it. If the next-build objective is missing, ask once (it shapes the spec's acceptance); if the area is ambiguous, confirm before investigating the whole tree.
2. Inspect the existing code to establish the project's current structure. Use a code-intelligence index if available (codebase-memory-mcp first (its get_architecture gives a fast overview), cross-checked with codegraph + graphify, else standard methods (LSP / Read/Grep/Glob); see .claude/skills/devrites-lib/reference/standards/tooling.md) for structure, callers, and impact. Capture, per adoption: current behavior, architecture + placement (layers, seams, where each kind of thing lives), the commands (test / build / typecheck / lint), and the idioms (naming, layering, error model, test style) + recurring gotchas. Read PRODUCT.md / DESIGN.md / CLAUDE.md / AGENTS.md if present.
3. Write spec.md via rite-spec's spec template and create the workspace + set .devrites/ACTIVE (state-workspace). The spec records the current behavior as the baseline and the next objective (what adoption is for) with measurable acceptance. Also write decisions.md, assumptions.md, questions.md, and state.md (phase: spec). 3a. Seed the capability ledger from the baseline. If the derived spec.md carries structured ### Requirement: blocks, fold them into the living .devrites/specs/<capability>/spec.md ledger so the project's current proven behavior is recorded before the first new feature. The next /rite-spec writes deltas against this ledger (ledger.md). A flat baseline folds as all-ADDED into the feature slug's capability; tag capabilities in the spec first if you want finer granularity.

   devrites-engine ledger diff .devrites/work/<slug>   # preview
   devrites-engine ledger sync .devrites/work/<slug>   # seed
   

   Skip when the baseline records no structured requirements (nothing to seed).
4. Seed the conventions ledger from observed behavior: adoption § seeding. This is the bootstrap exception to evidence-gated promotion. Seeds start at the base band with onboarding provenance; later sealed slices may confirm or contradict them, and fresh evidence wins. Completion: every seed names observed evidence, provenance, and the base band. 4a. Propose candidate principles (optional and human-ratified). When the code consistently enforces an invariant, such as integer cents for money, redacted PII in logs, or preserved v1 endpoints, propose it as a candidate principle rather than a convention. Principles are prescriptive gates, so never seed them automatically. Present each candidate through AskUserQuestion with evidence, and write human-ratified candidates to .devrites/principles.md with a dated Governance entry (principles.md). An unratified candidate remains a convention, not a gate. If no invariant qualifies, declare no principles.
5. Hand off. Continue with /rite-clarify. Its topology scan asks no questions when the derived contract is already clear. Every plan then runs /rite-vet before build. Do not plan or build here. Completion: one next rite is reported and no plan or application code was written.

Mid-flight discipline. Do not invent conventions, seed an assumed idiom, or turn adoption into a rewrite. Adoption records existing behavior; a later feature changes it. See anti-patterns.

Output

Progress first: run devrites-engine progress, then use the shared completion reply contract (devrites-lib/reference/reply-contract.md). Default success shape:

Done: adopted existing behavior into <slug>; baseline spec and placement recorded.
Changed: spec.md, decisions.md, conventions ledger, principles proposals <updated|none>
Evidence: not applicable; reverse-derived behavior is recorded for review
Open: <none | adoption questions>
Next: /rite-clarify
Record: .devrites/work/<slug>/spec.md
↻ Hygiene: /clear before the next phase