rite-adoptlisted

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