contextdevkit 1.8.0

package/templates/claude/commands/pipeline/ship.md

@@ -0,0 +1,54 @@
+---
+description: L6 — autonomous feature pipeline. Drives the full squad: design → implement → review → test → log. Checkpoints can be manual or automatic.
+argument-hint: <feature / objective> [--auto]
+---
+
+# 🚢 Ship (autonomous squad pipeline)
+
+Objective: **$ARGUMENTS**
+
+Run the end-to-end delivery pipeline, orchestrating the squad. Use TodoWrite to
+track the stages.
+
+## Checkpoint mode
+
+The stages marked ◆ are checkpoints. Pick the mode from the arguments:
+
+- **Manual (default)** — pause and ask for the user's OK at each ◆. Safest.
+- **Automatic (`--auto` in the arguments)** — do NOT pause at ◆; instead each
+  checkpoint becomes an **automatic gate**: proceed only if its objective
+  criteria pass (design has no unresolved high-risk item; review has zero
+  blockers; tests green; coverage ≥ `qa.coverageTarget` on `qa.criticalPaths`).
+  If a gate **fails**, STOP and report — never push past a red gate. Always pause
+  for the user before an irreversible action (commit/push/PR) regardless of mode.
+
+State which mode you're running at the start.
+
+## Pipeline
+
+1. **Scope & state.** Run `node contextkit/tools/scripts/context-pack.mjs` (latest-session
+   digest + immutable rules + recent ADRs in one call) and
+   `node contextkit/tools/scripts/adr-digest.mjs --search "<objective keywords>"` for the
+   ADRs relevant to the objective [ADR-0027] — open a full ADR only when needed.
+   Restate the objective; define IN/OUT-OF-SCOPE (as `/dev-start`).
+2. **Design** — delegate to `architect`: options, trade-offs, recommended path,
+   blast radius. If it crosses high-risk paths (L5), run `/simulate-impact` first.
+   ◆ Checkpoint: confirm the design with the user.
+3. **Plan tests** — delegate to `qa-orchestrator` (`/test-plan`): happy / edge /
+   failure for the scope.
+4. **Implement** — route to the right domain agent(s) (backend/frontend/db/…).
+   Keep changes within scope and the constitution (file size, SRP, naming, docs).
+5. **Self-review** — delegate to `code-reviewer`: constitution + immutable rules.
+   Fix blockers before continuing.
+6. **Test** — `/scaffold-tests` then run the suite; `/qa-signoff` against
+   `qa.criticalPaths` + `coverageTarget`. If the UI's *look* is part of the change,
+   run the **visual** suite too (`/visual-test`). ◆ Checkpoint if anything is red.
+7. **Quality gates** — run `tech-debt-scan` and (if `l5.contractGlobs` set)
+   `contract-scan`; surface regressions.
+8. **Record** — `/new-adr` if a real decision was made; `/log-session`; update
+   `CHANGELOG.md` `[Unreleased]`.
+9. **Report** — summary: what shipped, tests, debt/contract status, follow-ups.
+   Offer the commit/PR (do not push without the user's OK).
+
+If any agent isn't available in this environment, do that stage yourself but keep
+the gates. Never skip the review and test stages to "save time".

package/templates/claude/commands/pipeline/workflow.md

@@ -0,0 +1,85 @@
+---
+description: Workflow macro — chain /roadmap → /new-adr → /pipeline → /ship into one explicit narrative. (ticket 041)
+argument-hint: "new <slug> | advance <slug> [ref] | status [<slug>] | resume <slug>"
+allowed-tools: Bash(node:*)
+---
+
+`/workflow` is a **thin macro** over the primitives the kit already ships.
+It doesn't merge `/roadmap`, `/new-adr`, `/pipeline`, or `/ship` — it just
+keeps a breadcrumb so a multi-day, multi-session feature lifecycle reads as
+one story instead of four disconnected commands.
+
+## When to use
+
+- A feature is big enough to deserve a roadmap entry **and** an ADR **and**
+  pipeline tickets **and** a ship pass.
+- You want to be able to come back tomorrow (or on another machine) and
+  read "where did I stop?" in one place.
+- You want `/dev-start` to find the right scope for the next sub-session.
+
+## The four phases
+
+1. **roadmap** — product slice / what & why
+2. **adr** — technical decision (architecture, dependency, pattern)
+3. **tickets** — break the ADR's follow-ups into DevPipeline tasks
+4. **ship** — implement, test, log
+
+## How
+
+### Start a workflow
+
+```
+node contextkit/tools/scripts/workflow.mjs new <slug>
+```
+
+Then run `/roadmap add …` yourself. Once the roadmap entry is recorded:
+
+```
+node contextkit/tools/scripts/workflow.mjs advance <slug> <roadmap-section-ref>
+```
+
+…which marks `roadmap` done and points you at `adr`. Repeat for each phase.
+
+### Check status
+
+List all in-flight workflows:
+
+```
+node contextkit/tools/scripts/workflow.mjs status
+```
+
+Show one:
+
+```
+node contextkit/tools/scripts/workflow.mjs status <slug>
+```
+
+`--json` for machine-readable output.
+
+### Resume from another session / machine
+
+```
+node contextkit/tools/scripts/workflow.mjs status <slug>
+```
+
+The breadcrumb file (`contextkit/memory/workflows/<slug>.md`) carries the full
+history. The current phase is the resume point — invoke the matching native
+command (`/new-adr`, `/pipeline add`, `/ship`) and then `advance` when done.
+
+## What `/workflow` does NOT do
+
+- It does **not** auto-invoke `/roadmap`, `/new-adr`, `/pipeline`, or `/ship`.
+  Each phase is an explicit user action (rule 9 — build what is asked).
+- It does **not** chain phases silently. Every `advance` is a confirmation.
+- It does **not** know which ADR or which tickets belong to which workflow —
+  you pass the ref (e.g. `ADR-0023`, `[052,053]`) when advancing.
+
+## Breadcrumb file
+
+Path: `contextkit/memory/workflows/<slug>.md`. Schema is YAML-ish frontmatter
+parsed by hand (no `yaml` dep). One file per slug. The body keeps a bullet
+history of phase transitions for human inspection — you can hand-edit it
+without breaking the parser.
+
+The directory ships seeded (`.gitkeep`); files are written lazily by the
+script when you call `new`.

package/templates/claude/commands/playbook.md

@@ -0,0 +1,27 @@
+---
+description: Playbook registry + runner — list/show/run/track the reusable procedures in contextkit/workflows/playbooks/.
+argument-hint: [list | show <name> | run <name> [note] | runs]
+---
+
+# 📓 Playbook
+
+Manage and run the project's **reusable procedures** (`contextkit/workflows/playbooks/`) —
+the *why / how / anti-patterns* behind a slash command. This is the managed layer over
+that folder: a registry you can list, show, run, and track.
+
+Act on **$ARGUMENTS**:
+
+- **list** (default) — `node contextkit/tools/scripts/playbook.mjs list`. Show the
+  registry (every playbook + its title). Recommend the right one for the task at hand.
+- **show `<name>`** — `node contextkit/tools/scripts/playbook.mjs show <name>`. Print the
+  full procedure so you can read it before acting.
+- **run `<name>` [note]** — `node contextkit/tools/scripts/playbook.mjs run <name> "<note>"`.
+  Records the run in `contextkit/memory/playbook-runs.md` (audit trail) and prints the
+  procedure; then **actually execute its steps**, applying its judgment, and report the
+  outcome.
+- **runs** — `node contextkit/tools/scripts/playbook.mjs runs`. Show the run history.
+
+Composition: other flows reuse this instead of ad-hoc step lists — e.g. `/ship` and the
+squads can `run` a playbook (tech-debt-sweep, simulate-impact, distillation-cycle,
+security-batch) rather than restating it. Keep playbooks stack-agnostic; project-specific
+detail belongs in a scoped `CLAUDE.md` or an ADR.

package/templates/claude/commands/predictions-review.md

@@ -0,0 +1,28 @@
+---
+description: Close the predicted-vs-actual loop — fill each prediction's Actual section from the ledger.
+---
+
+# 🔁 Predictions Review
+
+Close the loop on `/simulate-impact` predictions for the current session.
+
+Run:
+
+```
+node contextkit/tools/scripts/predictions-review.mjs
+```
+
+This reads the session ledger and, for every `/simulate-impact` recorded this session, fills the
+**Actual** section of its prediction file in `contextkit/memory/predictions/`: the paths actually
+changed vs what was predicted, with the delta in both directions (predicted-but-not-changed,
+changed-but-not-predicted).
+
+Then:
+
+1. Open the updated prediction file(s) and add the **Risk accuracy** note — was the predicted risk
+   level right? That judgment is yours, not the script's.
+2. If a pattern repeats across predictions (an area consistently under- or over-estimated), capture
+   it: refine `.claude/commands/simulate-impact.md`, or open `/new-adr` if it's architectural.
+
+Also invoked automatically by `/log-session` at the end of a session, so the loop closes without a
+separate step in the normal flow.

package/templates/claude/commands/qa/qa-signoff.md

@@ -0,0 +1,24 @@
+---
+description: QA — final verdict. Run the suite, check critical-path coverage vs target, write a PASS/NEEDS-WORK report.
+---
+
+# 🧪 QA sign-off
+
+Act as **qa-orchestrator** and produce the final QA verdict.
+
+1. Run the project's test suite (and coverage if the runner supports it).
+2. Read `contextkit/config.json` → `qa.criticalPaths` and `qa.coverageTarget`.
+3. Assess:
+   - Do all tests pass?
+   - Are the `criticalPaths` covered (happy + failure modes), not just the easy
+     lines?
+   - Is coverage at or above `coverageTarget` (where measurable)?
+   - If a **visual harness** exists (`visual-test.mjs status`), did the visual suite
+     pass? An unintended screenshot diff is a NEEDS-WORK (have design-team confirm
+     intentional changes before refreshing baselines).
+4. Write a concise report: ✅ covered, ⚠️ gaps (with the specific files/cases
+   missing), and a clear **PASS** or **NEEDS-WORK** verdict.
+5. Record the verdict in the session log (or remind the user to `/log-session`).
+
+This is advisory by default — it informs `/close-version`, it doesn't hard-block.
+Treat a NEEDS-WORK on a critical path as a real blocker worth fixing first.

package/templates/claude/commands/qa/scaffold-tests.md

@@ -0,0 +1,27 @@
+---
+description: QA — materialize tests for the given files, routing each slice to the right specialist.
+argument-hint: <files or scope>
+---
+
+# 🧪 Scaffold tests
+
+Materialize tests for: **$ARGUMENTS**
+
+Act as **qa-orchestrator** and route work to the specialists (fan out in parallel
+for independent slices via the Agent tool when available):
+- **qa-unit** → pure functions/modules in scope (fast, mocked deps).
+- **qa-integration** → anything crossing a boundary (HTTP/DB/queue/fs).
+- **qa-fuzzer** → parsers, validators, schemas, auth, and `qa.criticalPaths`.
+- **qa-e2e** → critical user journeys, plus **visual / screenshot** checks where the
+  UI's *look* is the contract (scaffold with `/visual-test`).
+
+Rules:
+1. Match the project's existing test runner and file conventions. Never add a
+   second framework.
+2. Place test files where the project keeps them; mirror existing naming.
+3. Cover happy / edge / failure for each slice (use a prior `/test-plan` if one
+   exists).
+4. After writing, run the suite and report pass/fail.
+
+If sub-agents aren't available in this environment, write the tests yourself but
+keep the unit / integration / fuzz separation explicit.

package/templates/claude/commands/qa/test-plan.md

@@ -0,0 +1,26 @@
+---
+description: QA — generate a 3-layer test plan (happy / edge / failure) for a scope, before writing test code.
+argument-hint: <what to test>
+---
+
+# 🧪 Test plan
+
+Produce a shift-left test plan for: **$ARGUMENTS** (if empty, infer from the
+current change / recent edits).
+
+Act as **qa-orchestrator**:
+1. Read `contextkit/config.json` → `qa` (`criticalPaths`, `coverageTarget`) and the
+   project's existing test setup so the plan fits the stack.
+2. Identify the units, boundaries, and invariants in scope. Note which fall on
+   `qa.criticalPaths` (these get priority).
+3. Output the plan in **three layers**, each with concrete, specific cases (not
+   generic boilerplate):
+   - **Happy path** — the expected successful flows.
+   - **Edge cases** — boundaries: empty/max/negative, unicode, timezones,
+     concurrency, off-by-one.
+   - **Failure modes** — invalid input, dependency errors, partial failure,
+     timeouts, idempotency/retries.
+4. For each case, note the right layer (unit / integration / fuzz) so
+   `/scaffold-tests` can route it.
+
+Do not write test code here — this is the plan. Offer `/scaffold-tests` next.

package/templates/claude/commands/qa/visual-test.md

@@ -0,0 +1,42 @@
+---
+description: Visual / browser-driven testing harness — scaffold + run screenshot/visual-regression checks (qa-e2e + design-team).
+argument-hint: [status | scaffold [--js|--python] | run]
+---
+
+# 🖼️ Visual test (qa-e2e + design-team)
+
+Add a **browser-driven, visual** layer on top of behavioural e2e: open the running
+app, exercise a flow, and verify by **screenshot / visual regression**. The kit
+**scaffolds**; the browser runner is a **project** dependency (never the kit's zero-dep
+hot path).
+
+Act on **$ARGUMENTS** — route to **qa-e2e**, pair with **design-team** for baselines:
+
+## status
+```
+node contextkit/tools/scripts/visual-test.mjs status
+```
+Reports whether a visual harness exists (Playwright/Cypress for JS, pytest-playwright
+for Python) and what's missing.
+
+## scaffold
+```
+node contextkit/tools/scripts/visual-test.mjs scaffold          # auto-detect stack
+node contextkit/tools/scripts/visual-test.mjs scaffold --python
+```
+Writes a starter (write-if-missing): a Playwright config + a `tests/visual/` screenshot
+baseline. Then install the runner (the command prints it):
+`npm i -D @playwright/test && npx playwright install` (JS) or
+`pip install pytest-playwright && playwright install` (Python).
+
+## run / baseline
+Run the project's visual suite (e.g. `npx playwright test tests/visual`). The first run
+records baselines; later runs diff against them. Treat an **unintended** visual diff as
+a failure; update baselines deliberately (`--update-snapshots`) and have **design-team**
+review intentional changes.
+
+## judgment (qa-e2e)
+- Cover the few screens where the *look* is the contract; don't snapshot everything.
+- Stabilize: fixed viewport, seeded data, masked dynamic regions, wait on network-idle.
+- A change isn't "done" until the visual check is green — wired into `/qa-signoff` and
+  the `/ship` gate.

package/templates/claude/commands/roadmap.md

@@ -0,0 +1,48 @@
+---
+description: Create/manage the product roadmap (the what/why). New project: build it with the user. Existing: find or analyze→propose.
+argument-hint: [show | new | from-existing | add | sync-pipeline]
+---
+
+# 🗺️ Roadmap
+
+The product/business plan in `contextkit/memory/roadmap.md` — capabilities + milestones
+(P-IDs), ordered by value. **Not** bugs/tasks/SLA (those are the DevPipeline). The
+roadmap is **important** — keep it real and current.
+
+First, get the facts: `node contextkit/tools/scripts/roadmap.mjs find --json`
+(tells you if the canonical roadmap is defined, and lists any existing
+roadmap/PRD/spec/vision files in the repo).
+
+Act on **$ARGUMENTS**:
+
+## show (default)
+Read `contextkit/memory/roadmap.md`; summarize the phases, what's done/in-progress,
+and the next highest-value milestone. If it's still the placeholder, say so and
+offer to create it (→ `new` or `from-existing`).
+
+## new — build it WITH the user (greenfield or undefined)
+Co-create it, don't dump a template. Ask, in a short adaptive round:
+- the product vision + primary user journey (reuse `contextkit/memory/product.md` if present);
+- the few **outcomes** that matter first, and roughly in what order;
+- any hard deadlines/constraints.
+Then draft phases `P1, P2, …` with items `P1.1, P1.2, …` — each a user-facing
+capability + a one-line acceptance note. Show it, refine with the user, save.
+
+## from-existing — existing project
+1. If `roadmap.mjs find` listed a roadmap/PRD/spec file → read it and **import /
+   normalize** it into `contextkit/memory/roadmap.md` (P-ID format), keeping intent.
+2. If nothing was found → **analyze** the codebase (structure, README,
+   `product.md`, routes/features, open TODOs/issues) and **propose** a roadmap:
+   what exists, gaps, and likely next milestones. Present it as suggestions.
+3. Either way, **ask the user to add their own objectives** — turn each into a
+   P-ID item. The roadmap must reflect their intent, not just your inference.
+
+## add
+Append a new milestone/item with the next P-ID and an acceptance note.
+
+## sync-pipeline
+Hand the next milestone to execution: `/pipeline from-roadmap` breaks it into
+backlog tasks (cross-referenced by P-ID). Keep the non-duplication rule —
+roadmap = capabilities; pipeline = the tasks to deliver them.
+
+After any change, save `contextkit/memory/roadmap.md` and offer `/log-session`.

package/templates/claude/commands/setup/aidevtool-from0.md

@@ -0,0 +1,104 @@
+---
+description: Bootstrap a brand-new (empty) project from zero — product idea, interactive questionnaire, stack suggestion, roadmap, best practices.
+argument-hint: [one-line idea]
+---
+
+# 🌱 AI Dev Tool — Start from Zero
+
+Use this when the project is **empty** (no code yet). If there's already a
+codebase, use `/setupcontextdevkit` instead. Goal: go from a blank folder to a
+project with a clear product vision, a stack, a roadmap, the best-practices
+constitution, and an initialized DevPipeline — by **actively** interviewing the
+user and suggesting, not just scaffolding.
+
+First confirm it's greenfield: run `node contextkit/tools/scripts/detect-stack.mjs`
+and check `greenfield: true` / no `sourceDirs`. If it's not empty, stop and point
+to `/setupcontextdevkit`.
+
+## Phase 1 — Intelligent product questionnaire (interactive)
+
+Ask a focused, **smart** set of questions — adapt follow-ups to the answers, do
+not dump a static form. Cover:
+1. **What is the app?** Problem it solves, who it's for, the core value.
+2. **The core user journey** (the one flow that must be great).
+3. **Platform**: web / mobile / desktop / CLI / API / library?
+4. **Scale & constraints**: expected users, budget, deadlines, team size, any
+   hard constraints (offline, on-prem, regulation like LGPD/GDPR)?
+5. **Tech preferences**: do they already have stack ideas, or want a suggestion?
+6. **Audience language** for UI text.
+
+Summarize your understanding back and get a thumbs-up before proceeding.
+
+## Phase 2 — Product vision
+
+Write `contextkit/memory/product.md`: one-paragraph vision, target user, core value,
+the primary journey, non-goals. Short and sharp.
+
+## Phase 3 — Stack: suggest or refine
+
+If they gave a stack, sanity-check it against the requirements and note risks. If
+they want a suggestion, propose **one** recommended stack with a short rationale
+and 1–2 alternatives + trade-offs (act like `architect`). Record the choice as
+`/new-adr "Stack: <summary>"` (ADR-0001). Don't over-engineer for imagined scale.
+
+**Curated stacks with playbooks.** When a curated option fits the requirements,
+prefer it over an ad-hoc proposal — the playbook anchors conventions the kit
+will enforce later (`/setupcontextdevkit`, scoped CLAUDE.md, `/contract-check`):
+
+- **TanStack** (type-safe React/Solid/Vue with Query + Router; optionally
+  Start as the full-stack frame) → `contextkit/workflows/playbooks/tanstack.md`.
+  Pick it for type-safe apps where headless control matters; **don't** stack
+  TanStack Router on top of Next/Nuxt/Remix.
+
+If you pick a curated stack, cite its playbook in the ADR and inherit its
+conventions verbatim into the project's `CLAUDE.md` "Stack" block.
+
+## Phase 4 — Roadmap (product/business)
+
+Build `contextkit/memory/roadmap.md` **with the user** via `/roadmap new`: phases/
+milestones with **P-IDs** (P1.x, P2.x…), each a user-facing capability + a
+one-line acceptance note, ordered by value. Co-create it — ask which outcomes
+matter first; don't dump a template. This is the *what/why* of the product — NOT
+bugs or CI tasks (those live in the DevPipeline).
+
+## Phase 5 — Best practices (the constitution)
+
+Offer to adopt the context-coding best practices in `contextkit/best-practices.md`
+(280-line rule + **intelligent** refactoring — split by responsibility, never
+random; SoC; naming; errors; docs). On yes, fill the constitution section of
+`CLAUDE.md` accordingly and set `practices.active = true` via `/context-config`.
+
+## Phase 6 — Initialize execution
+
+Seed the DevPipeline from the roadmap: break the first milestone into a few
+concrete backlog tasks —
+`node contextkit/tools/scripts/pipeline.mjs add --type feature --priority P1 --title "..." --roadmap P1.1`.
+
+As soon as the project's structure exists (apps/backend/frontend/modules), give
+each its **own scoped CLAUDE.md** with `/claude-md` — the root one is the
+constitution; each module documents its local rules. Do this as modules are born,
+not after the codebase is already sprawling.
+
+**Curated-stack starter (opt-in).** If Phase 3 picked a curated stack with a
+starter under `templates/contextkit/starters/<stack>/`, offer to copy it into the
+project root as a wiring scaffold. Default is **no**; the user explicitly
+opts in. Currently available: `tanstack/` (Start + Router + Query, empty —
+no invented domain, no CSS framework, no backend choice — see ADR-0017).
+After copy, the starter becomes the user's code; no upgrade path.
+
+## Phase 6b — Version control (verify, then decide with the user)
+Run `node contextkit/tools/scripts/git.mjs status`. `git init` if it's not a repo.
+Then check the remote:
+- **already connected** (`remoteUrl` present) → confirm it's the right one, done.
+- **none** → **ask**: "Do you already have a repository to connect, or should we
+  create a new one?" Then run `/git setup-remote` (B1 connect existing / B2 create
+  new — private by default; install `gh`/`glab` if needed). A new project should be
+  under version control from day one. Confirm before pushing/creating.
+
+## Phase 7 — Set level & finish
+
+Recommend a starting level (usually L2; L4+ if it'll be a team). Run
+`node contextkit/tools/scripts/setup-complete.mjs` to clear the first-run trigger,
+then `/log-session`. Report: product, stack (+ADR), roadmap, pipeline seeded,
+level. The platform stays **active** — as the roadmap grows, suggest the next
+practice/level. Empty project today, opinionated project tomorrow.

package/templates/claude/commands/setup/context-config.md

@@ -0,0 +1,25 @@
+---
+description: Inspect or edit contextkit/config.json (ledger path lists, L5 high-risk paths, distill params).
+argument-hint: show [path] | set <path> <value>
+---
+
+Inspect or edit `contextkit/config.json` — the single source of truth for ContextDevKit behaviour.
+
+**$ARGUMENTS**
+
+Sections you can tune:
+- `ledger.important` / `ledger.irrelevant` / `ledger.registration` — which paths trigger the drift
+  nudge, which are ignored, which count as registering a session. **Tune these to your stack** (e.g.
+  Python → add `app/`, `tests/`; Go → `cmd/`, `internal/`).
+- `l5.highRiskPaths` — paths the Level 5 gate protects (require `/simulate-impact` first).
+- `l5.distill.*` — auto-distillation cadence.
+- `level` — prefer changing via `/context-level`.
+
+How to act — use the helper script (it coerces types and validates with zod when available):
+- Show:  `node contextkit/tools/scripts/context-config.mjs show [dotted.path]`
+- Set:   `node contextkit/tools/scripts/context-config.mjs set <dotted.path> <value>`
+  (arrays/objects accept JSON, e.g. `set ledger.important '["app/","tests/"]'`).
+
+Run the appropriate command based on `$ARGUMENTS` and show the output. The script never writes a
+malformed config — if `zod` is installed it validates against `contextkit/runtime/config/schema.mjs`
+first. For changing the level, prefer `/context-level`.

package/templates/claude/commands/setup/context-doctor.md

@@ -0,0 +1,21 @@
+---
+description: Diagnose this project's ContextDevKit install (node, config, hook wiring, git hooks, onboarding).
+---
+
+> ⚠️ **Deprecated (1.0):** **/audit** runs the doctor *plus* stats, tech-debt and
+> QA — prefer it. This still runs just the doctor.
+
+Run the ContextDevKit health check:
+
+```
+node contextkit/tools/scripts/doctor.mjs
+```
+
+It verifies Node version, `contextkit/config.json` validity + level, that
+`.claude/settings.json` hook wiring matches the configured level, git-hook
+presence (Level ≥ 3), memory scaffolding, and onboarding state — printing a
+suggested fix for each problem.
+
+Show the output to the user. If it reports critical issues (✗), offer to fix them
+(usually `/context-level <n>` to rewire, or re-running the installer). If it only
+shows advisory notes (⚠), mention them but don't force action.

package/templates/claude/commands/setup/context-level.md

@@ -0,0 +1,17 @@
+---
+description: Show or change the ContextDevKit activation level (1–7).
+argument-hint: [1-7]
+---
+
+Inspect or change the ContextDevKit level for this project.
+
+- **Show current level + what each enables**: `node contextkit/tools/scripts/context-level.mjs`
+- **Change level** (e.g. to 3): `node contextkit/tools/scripts/context-level.mjs $ARGUMENTS`
+
+Changing the level updates `contextkit/config.json` and recomposes `.claude/settings.json` hook wiring
+(and installs git hooks at Level ≥ 3). Run the appropriate command based on `$ARGUMENTS`, show the
+output, and remind the user to **restart Claude Code** so it reloads the hooks.
+
+Levels: 1 Memory · 2 Ledger (drift) · 3 Multi-session · 4 Squads (agents) · 5 Proactive (gates)
+· 6 Autonomy & Insight · 7 Ecosystem & Scale. (6–7 are capability tiers — no new hook.)
+Going up adds capability; going down cleanly removes the now-disabled hooks.