openspec-adoptlisted

# openspec-adopt One-time OpenSpec adoption for a repo. Scaffolds the documentation baseline before any change proposals reference it. ## Procedure 1. **Check it is actually absent.** An existing `openspec/` means this skill has nothing to do; point at it and stop. 2. **Scaffold.** Prefer `npx openspec init` to scaffold the layout, or create the structure by hand if the tool is unavailable. Create these files: `project.md`, `AGENTS.md`, `specs/`, `changes/`, and `changes/archive/`. One archiving rule is non-negotiable: a change is archived in the pull request that finishes it, before that PR is marked ready, never in a follow-up commit after merge and never as a push onto an approved PR. Post-merge archiving leaves the folder to whoever remembers, which is nobody. 3. **Write `project.md`.** Repo purpose, tech stack, conventions, commit/PR standards. Source: README, CONTRIBUTING, CI workflows, observed code idioms. Short; it is context, not documentation. 4. **Choose spec domains.** Select two to four domains that partition the system by behavior. Name them for what the system does, not for directories. Examples: authentication, persistence, deployment, external integration. 5. **Write baseline specs.** For each domain, `specs/<domain>/spec.md` describing current behavior and contracts: what exists, what invariants hold, what other systems depend on. Ground every claim in code you read or history you checked; a baseline is worthless if it guesses. Reference concrete