context-initlisted

# Context init Instantiates the per-repo skeleton from the Context-Engineering templates, adapted to the target repo. Ask only what cannot be inferred; verify before writing; never touch a legacy repo without an approved migration plan. Templates live in the Context-Engineering repo: `templates/repo/`, `templates/monorepo/`, `templates/community/` (locate your local clone — on this machine `C:/Briar/repos/mine/Context-Engineering` — or ask). ## Workflow Copy this checklist and tick items off: ``` Init progress: - [ ] 1. Explore the target repo - [ ] 2. Detect profile (ask only the gaps) - [ ] 3. Gotcha interview - [ ] 4. Verify commands by running them - [ ] 5. Migration plan gate (legacy repos only) - [ ] 6. Instantiate, audit, report ``` **1. Explore.** Stack and tooling (lockfiles, manifests, scripts), layout (single app vs monorepo — multiple app/package manifests ⇒ monorepo), existing context files (CLAUDE.md, AGENTS.md, adapters, docs/, repo skills), README. **2. Detect profile.** personal / public OSS / team. Infer from the query and repo signals (remote, contributors, license) when possible; otherwise ask ONCE. Community files follow `templates/community/MATRIX.md` exactly — public OSS also picks a license (MIT default). **3. Gotcha interview.** Ask the user for the 3-5 real gotchas and hard constraints — owner knowledge is not inferable. Always ask one explicitly: does anything outside the repo depend on it (published package, API, sibling repos), or is it fr