@skitterbyte/skitterspec 0.1.0

package/assets/skills/spec-bug/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: spec-bug
+description: Investigate a bug, capture it as a Bug-type spec, and drive it red→green. ALWAYS starts by reproducing the bug with a failing test, then writes the spec and works the test to green. Creates specs/in-progress/bug-<name>/00-overview.md. Use when the user reports a bug, says "/spec-bug", "investigate this bug", "this is broken — find and fix it", or pastes an error/stack trace.
+---
+
+# /spec-bug — investigate a bug, prove it with a failing test, fix it
+
+This is the **bug** counterpart to `/spec` (which is for **features**, plan-only).
+Unlike `/spec`, this skill is hands-on and test-first: it reproduces the bug as a
+**failing test (RED)**, captures a lean Bug spec, then works the test to **GREEN**.
+
+Spec type convention (see `.claude/rules/spec-planning.md`):
+- Bug specs are named `bug-<kebab-name>`; feature specs `feat-<kebab-name>`.
+- Every spec header carries `> **Type:** Bug` (or `Feature`).
+
+## 1. Reproduce & isolate (light investigation)
+
+Bugs are concrete — confirm, don't over-grill. Establish:
+
+- **Repro:** exact steps / input that triggers it. Ask only if you can't derive it.
+- **Expected vs actual:** what *should* happen vs what does.
+- **Scope & blast radius:** which module(s)/endpoint(s)/package; one tenant or all.
+- **Root cause:** read the code, trace it to `file:line`. Compare a working path
+  against the broken one (the bug usually lives in the differential). Do NOT
+  patch a symptom before you understand the cause.
+
+## 2. Write the failing test FIRST (RED) — mandatory
+
+Encode the **correct** (expected) behaviour as a test, then run it and confirm it
+**fails for the right reason**:
+
+- Put it where the suite already covers that area. Reuse existing test helpers /
+  factories; follow the project's test rules (see `.claude/rules/`). Never
+  hardcode dates — compute them relative to now.
+- Run it with the project's test command. Quote the red output. A test that
+  passes before the fix proves nothing — keep refining the assertion until it
+  genuinely captures the bug.
+
+## 3. Write the Bug spec
+
+Create the spec **folder** `specs/in-progress/bug-<kebab-name>/` with its entry
+point `00-overview.md` (every spec is a folder — never a bare file). A bug is
+usually a single-pass fix, so the `## Fix` block can live directly in
+`00-overview.md`. **If the fix needs phasing** (large/uncertain root cause),
+split it into phase files (`01-<slug>.md`, `02-…`) with a phase index in
+`00-overview.md`, exactly like a feature spec. It starts in `in-progress`
+because work is already underway. Keep it lean:
+
+```markdown
+# Bug: <short title>
+
+> **Type:** Bug
+> **Status:** In Progress — fixing (red test added)
+> **Author:** <git user.name — who reported/captured it>
+> **Developer:** <git user.name — you, since you're fixing it now>
+> **Raised:** <YYYY-MM-DD (today)>
+> **Area:** <files/modules>
+
+## Symptom
+
+<observed wrong behaviour + repro steps; paste the error/stack if any>
+
+## Root cause
+
+<the actual cause, at `file:line`. One paragraph — be specific.>
+
+## Failing test (red)
+
+<test name + path; what it asserts. How to run it. Paste the red failure line.>
+
+## Fix
+
+- [ ] <the minimal change that addresses the root cause, not the symptom>
+- [ ] Failing test now passes (GREEN); run the project's typecheck and test
+      commands — confirm no regressions.
+- [ ] <any follow-up hardening, or "None">
+
+## State log
+
+| Date | Status | Folder | By |
+|------|--------|--------|----|
+| <YYYY-MM-DD> | In Progress | in-progress | <developer> |
+
+## Changelog
+
+- <YYYY-MM-DD> — Bug reproduced; failing test added (red).
+```
+
+The **State log** is the folder/status audit trail; later transitions
+(`/spec-complete`, `/spec-cancel`) append a row. The **Changelog** is for the
+fix narrative and decisions — keep them separate.
+
+## 4. Drive to GREEN
+
+- Implement the **minimal, root-cause** fix. Match surrounding code; honour all
+  project rules (see `.claude/rules/`).
+- Re-run the failing test → it must pass. Then run the project's typecheck and
+  test commands to confirm no regressions. Quote results.
+- Tick the Fix tasks, add a Changelog line (`- <date> — Fixed: <one line>; test green`).
+
+If the root cause is large/uncertain and can't be fixed in one pass: keep the red
+test, split the fix into phase files (`01-<slug>.md` …) with a phase index in
+`00-overview.md`, and leave the spec in `in-progress` for `/spec-go` to continue.
+Say so explicitly — don't fake green.
+
+It starts in `in-progress`, so it does **not** touch `specs/backlog/00-index.md`
+(there is no index for in-progress). When `/spec-complete` later finishes it,
+that skill logs it to `specs/complete/00-index.md`.
+
+## 5. Report
+
+Summarise: root cause, the failing→passing test, the fix, and the full test
+result. The spec stays in `in-progress`; suggest `/spec-complete` to verify and
+archive it. Do **not** `git commit` unless the user asks.

package/assets/skills/spec-cancel/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: spec-cancel
+description: Cancel a spec — capture the reason, record final progress, stamp the reason on the spec header, then move it into specs/cancelled/. Targets a spec by name (arg) or the spec currently in context. Use when the user says "/spec-cancel", "drop this spec", "we're not doing this spec", or "shelve <spec>".
+---
+
+# /spec-cancel — record, stamp a reason, archive a spec
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate it under `specs/` (any bucket — `backlog/`, `in-progress/`, …). Entry point
+  is its `00-overview.md`; phases are separate files (`01-<slug>.md`, `02-…`) listed
+  in its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Ask for the cancellation reason — required
+
+Ask the user **why** it's being cancelled (e.g. superseded by X, descoped, no
+longer needed, blocked indefinitely). Do not proceed without a reason; capture
+it verbatim/condensed for the header.
+
+## 3. Double-check and record progress
+
+- Read the overview and every phase file and reconcile task state with reality:
+  tick anything that was actually completed before cancelling so the record is
+  honest about what landed.
+- Note any partial/abandoned work so it isn't mistaken for unstarted.
+
+## 4. Stamp the spec
+
+Update the **Status** header in the entry point so the reason is visible at the
+top:
+
+```
+> **Status:** Cancelled (<YYYY-MM-DD>) — <reason>
+```
+
+Append a **State log** row:
+`| <YYYY-MM-DD> | Cancelled | cancelled | <git user.name> |`.
+
+Add a **Changelog** entry:
+`- <YYYY-MM-DD> — Cancelled: <reason>.`
+
+## 5. Move to cancelled
+
+`mkdir -p specs/cancelled` then **`git mv`** the file or folder:
+`git mv "specs/<bucket>/<name>" "specs/cancelled/<name>"` (preserve history;
+move the whole folder).
+
+If the spec was in `backlog`, **remove its row from `specs/backlog/00-index.md`**
+(it has left the backlog). There is no index for `cancelled`.
+
+## 6. Report
+
+Confirm the cancellation, the reason recorded, and the new location. Do **not**
+`git commit` unless the user asks.

package/assets/skills/spec-complete/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: spec-complete
+description: Finish a spec — verify all phases are genuinely done, update progress, then move it into specs/complete/. Targets a spec by name (arg) or the spec currently in context. Use when the user says "/spec-complete", "mark this spec done", or "this spec is complete".
+---
+
+# /spec-complete — verify, finalise, archive a spec
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate the spec folder under `specs/` (usually `specs/in-progress/`). Entry
+  point is its `00-overview.md`; phases are separate files (`01-<slug>.md`, `02-…`)
+  listed in its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Double-check progress — don't rubber-stamp
+
+Before marking complete, confirm the work is actually finished:
+
+- Read every phase file. For each **unchecked** task, check whether it is in fact
+  done in the code — tick it (`- [x]`) if so, or surface it if not.
+- Run the project's typecheck and test commands. The suite must be **green** to
+  call a spec complete.
+- For a **Bug** spec (`Type: Bug`), confirm the originally-failing test named in
+  the spec now passes — that test is the proof the bug is fixed.
+- If genuinely incomplete work remains, **stop and tell the user** rather than
+  forcing completion. Offer to finish it (`/spec-go`) or to complete with the
+  remaining items explicitly listed as deferred.
+
+## 3. Update the spec
+
+- Tick all completed tasks in the phase files; flip every finished phase-file
+  heading **and** every row in the `00-overview.md` phase index to `✅`.
+- Set the **Status** header in the entry point:
+  `> **Status:** Complete (<YYYY-MM-DD>)`.
+- Append a **State log** row:
+  `| <YYYY-MM-DD> | Complete | complete | <git user.name> |`.
+- Add a **Changelog** entry:
+  `- <YYYY-MM-DD> — Completed; all phases done, tests green.`
+  (Note any consciously-deferred items here too.)
+
+## 4. Move to complete
+
+`mkdir -p specs/complete` then **`git mv`** the file or folder:
+`git mv "specs/in-progress/<name>" "specs/complete/<name>"` (preserve history;
+move the whole folder).
+
+Then **prepend a row to `specs/complete/00-index.md`** (newest first — directly under
+the table header, above existing rows):
+
+```
+| <YYYY-MM-DD> | <name> | Feature|Bug |
+```
+
+This is the append-only completion log used to find the latest completed specs.
+
+## 5. Report
+
+Confirm the move, the final test result, and list anything deferred. Do **not**
+`git commit` unless the user asks.

package/assets/skills/spec-go/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: spec-go
+description: Promote a spec into active development and implement its first phase. Moves the spec from backlog into specs/in-progress/, then builds phase 1 with tests. Targets a spec by name (arg) or the spec currently in context. Use when the user says "/spec-go", "start this spec", "begin implementing <spec>", or "let's build the next phase".
+---
+
+# /spec-go — start (or continue) implementing a spec
+
+## 1. Identify the target spec
+
+- If a name/path is given as an argument, use it.
+- Otherwise use the spec **currently in context** (the one just created or
+  discussed). If neither is clear, ask which spec.
+- Locate it by searching `specs/` (check `specs/backlog/` first, then the other
+  buckets). A spec is a `<name>/` folder whose entry point is `00-overview.md`,
+  with **one file per phase** alongside it (`01-<slug>.md`, `02-…`). Legacy specs
+  may be a bare `<name>.md`, or a `00-overview.md` with inline phases — handle
+  those too.
+
+## 2. Move it into development
+
+- If it isn't already under `specs/in-progress/`, move the whole spec folder
+  there. **Use `git mv`** to keep history:
+  `git mv "specs/backlog/<name>" "specs/in-progress/<name>"`.
+  `mkdir -p specs/in-progress` first if needed.
+- Update the **Status** header in the entry point:
+  `> **Status:** In Progress — Phase 1 (started <YYYY-MM-DD>)`.
+- Set the **Developer** header field if it's still `—`: use `git config user.name`.
+- Append a **State log** row:
+  `| <YYYY-MM-DD> | In Progress | in-progress | <git user.name> |`.
+- **Remove the spec's row from `specs/backlog/00-index.md`** — it has left the backlog
+  (there is no index for `in-progress`).
+
+A spec ideally reaches here as `Ready` (via `/spec-ready`), but `/spec-go` works
+on a `Draft` too — just sanity-check it's well-formed before building.
+
+If the spec is already in `in-progress`, skip the move and implement the **next
+unfinished phase** instead of Phase 1.
+
+## 3. Pre-flight — commit prior work, then compact
+
+Before writing any code for this phase, get the workspace and context clean:
+
+- **Confirm the last-worked phase is committed.** Run `git status` and
+  `git log --oneline -5`. The most recently *implemented* phase (not necessarily
+  the numerically previous one) should already be committed. If prior-phase work
+  is still uncommitted, **stop and suggest committing it first** (e.g. via
+  `/commit`) so each phase lands as its own reviewable commit — don't build the
+  next phase on top of an uncommitted one. (Skip if this is the first phase —
+  there's nothing prior to commit.)
+- **Compact, then continue.** Recommend the user run `/compact` now. A fresh,
+  minimal context keeps the phase focused and avoids drift from earlier turns;
+  the spec file on disk is the source of truth, so nothing is lost. Pause for the
+  `/compact`, then implement the phase.
+
+## 4. Implement the phase
+
+Identify the **first unfinished phase** from the `00-overview.md` phase index,
+then open its phase file (`0N-<slug>.md`) — that file holds the tasks. Mark it
+started: set the phase-file heading to `🔄` and its `> **Status:**` to
+`In progress`, and flip the matching row in the overview phase index to `🔄`.
+Then build it, following the project rules in `.claude/rules/*.md` and `CLAUDE.md`:
+
+- Work task by task through the phase file. Make focused edits that match
+  surrounding code.
+- Honour the project's conventions (see `.claude/rules/spec-planning.md` and the
+  rules it links).
+- **Tests are part of the phase, not after it.** Create/extend tests for the
+  work, then run the project's typecheck and test commands. Do not declare the
+  phase done until green.
+- Never hardcode dates in tests; never run destructive commands against a real
+  database — use the project's test database only.
+
+## 5. Record progress
+
+- In the **phase file**: tick completed tasks (`- [x]`), flip its heading to `✅`,
+  and set its `> **Status:**` to `Done`.
+- In **`00-overview.md`**: flip the matching phase-index row to `✅`.
+- If anything changed from the plan (a decision, a deviation, a discovered
+  constraint), add a dated **Changelog** entry in `00-overview.md`.
+- If new work surfaced, add it as tasks to the appropriate phase file (or add a
+  new phase file + index row) rather than doing it silently.
+
+## 6. Report
+
+Summarise what was implemented, the test result (quote failures if any), and
+which phase is next. Do **not** `git commit` unless the user asks — finish,
+verify, and wait.

package/assets/skills/spec-init/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: spec-init
+description: Bootstrap the spec-driven-development workflow in the current project — create the specs/ lifecycle folders and .core, wire version-control so specs are tracked, verify the spec skills are installed, and add the spec workflow to CLAUDE.md and .claude/rules. Idempotent and safe to re-run. Use when setting up a new project for specs or repairing the setup, or when the user says "/spec-init", "set up specs here", "initialise the spec process".
+---
+
+# /spec-init — set up the spec-driven-development workflow
+
+Bootstrap (or repair) everything this project needs to run the spec lifecycle.
+**Idempotent:** detect what already exists, create only what's missing, and never
+clobber customised content. Finish with a summary of created vs already-present.
+
+> If `@skitterbyte/skitterspec` is installed, `npx @skitterbyte/skitterspec init` does
+> all of the below mechanically. This skill is the manual/repair path and is
+> useful when the package isn't available or you only need to fix part of the
+> setup.
+
+The system is **eight skills**: `spec` (feature), `spec-bug` (bug), `spec-ready`,
+`spec-review`, `spec-go`, `spec-complete`, `spec-cancel`, and this `spec-init`. The lifecycle is
+`backlog → in-progress → complete / cancelled`, with `.core` holding always-apply
+project rules.
+
+## 1. Folders
+
+Create any that are missing; drop a `.gitkeep` into ones that would otherwise be
+empty so git keeps them:
+
+- `specs/.core/` — project rules (always apply; never moved)
+- `specs/backlog/` `specs/in-progress/` `specs/complete/` `specs/cancelled/`
+
+Also ensure the two index files exist (create with just their header comment +
+table header if missing — do not regenerate if present):
+
+- `specs/backlog/00-index.md` — live view of backlog (`Added | Spec | Type | Status`);
+  `/spec` adds rows, `/spec-go` and `/spec-cancel` remove them.
+- `specs/complete/00-index.md` — append-only completion log (`Completed | Spec | Type`),
+  newest first; `/spec-complete` prepends a row.
+
+## 2. Version control — keep specs tracked
+
+The whole lifecycle lives in git — **everything under `specs/` is tracked**, so
+the default is simply *no ignore rule excluding it*. Ensure `.gitignore` has no
+`/specs/*` (or similar) entry that would hide spec folders; if one exists and the
+project wants everything tracked, remove it. Confirm with
+`git check-ignore -v specs/.core/<any-file>` — it should print nothing (tracked).
+
+- **`.core` dotfile caveat:** only relevant if a `/specs/*` ignore is
+  (re)introduced — `*` matches dotfiles, so `.core` would need an explicit
+  `!/specs/.core/` negation. With no ignore rule, it's tracked automatically.
+- If the project uses a formatter/linter ignore glob that excludes `specs/**`,
+  decide whether spec markdown should be formatted/linted and adjust accordingly.
+- If a project later wants to **stop** versioning work-in-progress specs, that's
+  a deliberate opt-out (e.g. `/specs/*` + `!/specs/.core/`) — ask first; the
+  default is track-everything.
+
+## 3. Verify the skills are installed
+
+Check each of the eight skills resolves — `.claude/skills/<name>/SKILL.md`
+(project) or `~/.claude/skills/<name>/` (global). List any missing. This skill
+scaffolds the project; it does **not** regenerate skill bodies — missing skills
+must be copied in (e.g. `npx @skitterbyte/skitterspec init`) from a global install
+or a sibling project. If most/all are global, just confirm availability.
+
+## 4. Governing rule (`.claude/rules/spec-planning.md`)
+
+Ensure it exists. If missing, create it documenting:
+
+- the lifecycle skills with their **status** and **folder** (table);
+- the **type** convention — header `> **Type:** Feature|Bug` + filename prefix
+  `feat-`/`bug-` (never `[BUG]` brackets — glob hazard);
+- the **Author** / **Developer** header fields;
+- the **State log** audit table (folder/status transitions), kept separate from
+  the **Changelog** (decisions);
+- the project's concrete typecheck/test commands, and the rule that **every
+  phase ends with creating + running tests**.
+
+Read a sibling spec skill (e.g. `spec`, `spec-go`) for the canonical shapes
+rather than inventing them. If the rule already exists, leave it unless stale.
+
+## 5. CLAUDE.md
+
+Ensure a `## Spec workflow` section exists. If absent, add one with the
+skill table (`Skill | Action | Status | Folder`), the Feature/Bug type note,
+and a pointer to `.claude/rules/spec-planning.md`. Also update the `specs/` entry
+in any project-structure tree to show `.core/` + the four lifecycle folders. If
+the section exists, refresh only stale folder/skill names — don't rewrite it.
+
+## 6. Report
+
+Summarise per area — folders, `.gitignore` lines, tooling-ignore negations,
+skills (present/missing), rule file, CLAUDE.md section — as created / updated /
+already-present, plus the `git check-ignore` result for `.core`. Do **not**
+`git commit` unless the user asks.

package/assets/skills/spec-ready/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: spec-ready
+description: Mark a Draft spec as Ready — confirm it's groomed (no unresolved open questions, phases and per-phase tests defined, decisions captured) and flip its status to Ready so it's a candidate for /spec-go. Stays in specs/backlog/. Targets a spec by name (arg) or the spec in context. Use when the user says "/spec-ready", "this spec is ready", or "mark <spec> ready to start".
+---
+
+# /spec-ready — promote a Draft spec to Ready
+
+A grooming gate between authoring (`/spec`, status `Draft`) and implementation
+(`/spec-go`, status `In Progress`). It does **not** move the spec — it stays in
+`specs/backlog/`; it only confirms quality and flips the status to `Ready` so
+you can see at a glance which backlog specs are good to start.
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate the spec folder under `specs/backlog/`. Entry point is its
+  `00-overview.md`; phases are separate files (`01-<slug>.md`, `02-…`) listed in
+  its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Check it's actually ready — don't rubber-stamp
+
+Review the spec against the readiness bar. If any of these fail, **stop and tell
+the user what's missing** rather than marking it Ready:
+
+- **Open questions resolved** — the `## Open questions` section is empty or
+  reads "None". Unresolved branches mean it isn't ready.
+- **Decisions captured** — the chosen solution and key trade-offs are recorded.
+- **Phased with clear tasks** — work is broken into phases, and **every phase in
+  the `00-overview.md` index has a matching phase file** (`0N-<slug>.md`) with
+  verb-first `- [ ]` tasks granular enough for one session. No index row without
+  a file, no orphan file without an index row.
+- **Tests baked into every phase** — each phase file ends with a
+  create-and-run-tests task (a phase isn't done until green).
+- **Concise and current** — no stale/contradictory sections.
+
+Offer to fix small gaps inline if the user wants; otherwise leave it `Draft`.
+
+## 3. Mark Ready
+
+- Set the **Status** header in the entry point:
+  `> **Status:** Ready (<YYYY-MM-DD>)`.
+- Append a **State log** row: `| <YYYY-MM-DD> | Ready | backlog | <git user.name> |`
+  (no folder change — Ready stays in `backlog`).
+- Update the spec's row in `specs/backlog/00-index.md` — set its Status column to
+  `Ready` (the row stays; the spec is still in backlog).
+- Optionally add a **Changelog** note if grooming changed anything substantive.
+
+## 4. Report
+
+Confirm it's Ready and note it stays in `backlog` until `/spec-go` picks it up.
+If you blocked it, list exactly what needs resolving first.

package/assets/skills/spec-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: spec-review
+description: Re-validate an existing spec against the current codebase — detect drift (renamed/removed files, changed APIs, tasks already done in code, stale decisions), grill where a decision is needed, and update the spec so it's relevant again. Targets a spec by name (arg) or the spec in context. Use when the user says "/spec-review", "is this spec still accurate", "this spec has gone stale", or before picking up an old backlog spec.
+---
+
+# /spec-review — bring a spec back in sync with the codebase
+
+Specs rot: the code moves on while a spec sits in the backlog or pauses
+mid-build. This skill re-validates a spec against the **current** code and
+rewrites the stale parts so it's safe to act on. It plans only — it does not
+implement anything (that's `/spec-go`).
+
+## 1. Identify the target spec
+
+- Use the name/path argument if given, else the spec **in context**. If unclear,
+  ask which spec.
+- Locate the spec folder under `specs/` (any bucket). Entry point is its
+  `00-overview.md`; read it **and every phase file** (`01-<slug>.md`, `02-…`)
+  listed in its phase index (legacy specs may be a bare `<name>.md`).
+
+## 2. Validate against the codebase — evidence first
+
+Read the spec, then check every claim it makes against the real code. Don't
+trust the spec's own wording — verify:
+
+- **Referenced things still exist.** Grep/read for each `file:line`, module,
+  function, route, model, type, or symbol the spec names. Flag anything renamed,
+  moved, or deleted.
+- **Tasks already done.** For each `- [ ]`, check whether the code already
+  implements it (it may have landed via other work). Tick `- [x]` what's done.
+- **Decisions still valid.** Re-check each `## Decisions` entry against the
+  current architecture and `.claude/rules/*.md`. Flag any that now conflict with
+  how the codebase actually works (a changed convention, a superseded approach).
+- **New constraints.** Note rules/patterns introduced since the spec was written
+  that it must now honour (e.g. a new required field, a new error type, a new
+  pattern the rest of the code now follows).
+- **Backward compatibility.** Re-confirm the planned API/schema changes are still
+  additive/safe given the current code (see the project's compatibility rules).
+
+## 3. Grill only where a decision is needed
+
+Where the drift forces a choice (the old approach no longer fits, a referenced
+thing is gone, scope is now ambiguous), grill the user like `/spec` Phase A —
+**one question at a time, with a recommended answer** — but scoped tightly to
+the drift. Don't re-litigate decisions that still hold. If you can resolve it by
+reading the code, do that instead of asking.
+
+## 4. Update the spec
+
+- Rewrite stale **Decisions** / **Solution overview** in `00-overview.md` and
+  stale **tasks** in the phase files so they match the current code and the
+  resolved questions. Add/remove tasks within a phase file; add a new phase by
+  creating a `0N-<slug>.md` file **and** a matching overview index row, or drop a
+  dead phase by removing both. Keep the index and files in sync; **preserve
+  completed `[x]` history**.
+- Tick tasks already satisfied by the code; re-open `## Open questions` for
+  anything still undecided.
+- Add a dated **Changelog** entry summarising the review (e.g. `- <date> —
+  Reviewed vs codebase: retargeted Phase 2 onto X, dropped Y (removed), ticked Z
+  (already done)`).
+- **Status:** if drift is minor, leave status as-is. If a `Ready` spec needs real
+  re-grooming, knock it back to `Draft` (set `> **Status:** Draft`, append a
+  **State log** row, and reset its row in `specs/backlog/00-index.md` to `Draft`).
+
+## 5. Report
+
+Summarise the drift found, what you changed, any questions still open, and
+whether the spec is now safe to `/spec-go` (or needs `/spec-ready` again). Do
+**not** `git commit` unless the user asks.

package/bin/skitterspec.js

@@ -0,0 +1,9 @@
+#!/usr/bin/env node
+'use strict'
+
+const { run } = require('../src/cli.js')
+
+run(process.argv.slice(2)).catch((err) => {
+  console.error(`skitterspec: ${err.message}`)
+  process.exit(1)
+})

package/package.json

@@ -0,0 +1,42 @@
+{
+  "name": "@skitterbyte/skitterspec",
+  "version": "0.1.0",
+  "description": "Spec-driven-development workflow for Claude Code — installs the spec lifecycle skills, rule, and specs/ folders into any project.",
+  "keywords": [
+    "claude",
+    "claude-code",
+    "spec-driven-development",
+    "sdd",
+    "skills",
+    "scaffold"
+  ],
+  "license": "MIT",
+  "author": "Reuben Greaves",
+  "type": "commonjs",
+  "bin": {
+    "skitterspec": "bin/skitterspec.js"
+  },
+  "files": [
+    "bin",
+    "src",
+    "assets"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "dependencies": {
+    "prompts": "^2.4.2"
+  },
+  "scripts": {
+    "test": "node --test",
+    "changelog": "node scripts/generate-changelog.js",
+    "changelog:retro": "node scripts/generate-changelog.js --retro",
+    "releases": "node scripts/generate-releases.js",
+    "releases:retro": "node scripts/generate-releases.js --retro",
+    "version": "node scripts/generate-changelog.js && node scripts/generate-releases.js && git add CHANGELOG.md RELEASES.md"
+  },
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/skitterbyte/skitterspec.git"
+  }
+}