claude-code-kit 0.7.1__tar.gz → 0.9.0__tar.gz

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "claude-kit",
       "source": "./",
       "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (no app code, no Docker): install CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json, then run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop.",
-      "version": "0.7.1",
+      "version": "0.9.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.7.1",
+  "version": "0.9.0",
   "description": "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC config (no app code, no Docker). `claude-kit init` asks ordered questions and installs CLAUDE.md + .claude/ (rules, the profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates with working memory and a self-improving learnings loop.",
   "author": {
     "name": "Arjunsingh Yadav",

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/CHANGELOG.md

@@ -4,6 +4,80 @@ All notable changes to claude-kit are documented here. The format follows
 [Keep a Changelog](https://keepachangelog.com/), and the project uses
 [semantic versioning](https://semver.org/).
 
+## [0.9.0] — 2026-06-15
+
+Distils a field review of GitHub's [spec-kit](https://github.com/github/spec-kit) (Spec-Driven
+Development). An adversarial map→verify pass cross-checked spec-kit's seven distinctive features
+against claude-kit's existing spec-driven machinery; most were already covered (the `/constitution`
+artifact by `CLAUDE.md` "Project-specific rules" + the org `ai-working-agreement`; `/clarify` by
+`interview-me`; `/checklist` by `em-reviewer` + the spec-driven reframe + workflow §1b). Per golden
+rule #1 (reuse, don't duplicate), those were **not** re-implemented. The genuine gaps were a
+**built-but-unwired capability** and a **missing mechanism** — both addressed without new spec
+machinery, no application code, and no Docker.
+
+### Added
+- **`skills/task-tracker-sync`** (`standard`+): a thin, **tracker-agnostic** skill that mirrors an
+  existing task/story breakdown into the project's configured issue tracker (GitHub / Linear / Jira
+  via whichever MCP is set up), one issue per task, dependencies carried across, idempotent
+  (match-then-update, never blind-create). This implements spec-kit's `/taskstoissues` as the real
+  mechanism behind what was previously only a permission — `story-planner` said tasks *may* be
+  created, but nothing did it. It syncs a breakdown; it does not create one.
+
+### Changed
+- **Wired the orphaned `story-planner` agent into the pipeline as a coverage gate** — the headline
+  reuse. `story-planner` already decomposes an approved spec into ordered stories and verifies that
+  *every acceptance criterion maps to ≥1 story* (gaps and scope creep flagged), but it appeared in
+  neither `rules/mandatory-workflow.md` nor `agents/orchestrator.md`. It is now **stage 1f — Story
+  Breakdown & Coverage Gate**, between EM approval (1e) and the Developer (2a): implementation cannot
+  start until acceptance-criterion coverage is complete. This is spec-kit's tasks→analyze→implement
+  discipline, fulfilled with an existing component instead of a new one. Flow diagrams, the gating
+  table, and the orchestrator pipeline/spawn-reference/state-tracking were updated to match.
+- **`templates/artifacts/feature-spec.md`** now gives requirements stable ids (R1, R2 …) nesting
+  their Given/When/Then acceptance criteria, and adds an explicit **Assumptions** section — aligning
+  the artifact with the spec shape `mandatory-workflow.md` §1c already mandates and making the new
+  coverage gate concrete (stories and tests trace back to R-ids).
+- `agents/story-planner.md` and `skills/planning-and-task-breakdown` now point at `task-tracker-sync`
+  for pushing a plan to a tracker.
+
+## [0.8.0] — 2026-06-15
+
+Adds a **minimalism / anti-over-engineering** layer distilled from a field review of the
+[ponytail](https://github.com/DietrichGebert/ponytail) plugin. Most of ponytail's philosophy (YAGNI,
+stdlib-first, surgical diffs) was already enforced by `templates/CLAUDE.md` "Simplicity First",
+`skills/code-simplification`, and `rules/rarv-cycle`, so — per golden rule #1 (reuse, don't duplicate)
+— only the genuinely-missing *mechanisms* were added. No application code, no Docker; new components
+are wired through the catalog.
+
+### Added
+- **`skills/over-engineering-review`** (`standard`+): a complexity-**only**, report-**only** scan that
+  returns a terse delete-list (`delete:/stdlib:/native:/yagni:/shrink:` tags, each naming the
+  replacement) over a diff or a whole repo, ending with `net: -N lines possible` or `Lean already.
+  Ship.`. Complements the multi-axis `code-review-and-quality` (it isolates the complexity axis) and
+  stops short of the behavior-preserving refactor that `code-simplification` performs. Never flags the
+  kit's required test or the safety carve-outs.
+- **`skills/simplification-debt`** (`standard`+): harvests deliberately-deferred shortcuts
+  (`TODO(TICKET)`, `FIXME`, and inline `shortcut: ceiling — upgrade` markers) into one ledger grouped
+  by file, and flags any marker that names **no upgrade trigger** as a silent-rot risk. Report-only;
+  persists to a file only when asked.
+- **`load-autonomy` hook** (`SessionStart`, `standard`+): surfaces the repo's active autonomy level
+  (read from the install snapshot) into context each session, so `rules/autonomy-levels.md` is visible
+  and persistent rather than purely instructional. Degrades to a no-op without `jq`. Registered in the
+  hook registry and the plugin `hooks/hooks.json`.
+
+### Changed
+- **`rules/evals.md`** gains section 6: run repeated trials and report the **median of N**, and
+  **separate measurement metrics** (record-and-pass: LOC, cost, latency) **from gate metrics**
+  (execute-and-fail: run the output, assert it) — with the ponytail benchmark cited as a worked example.
+- **`rules/documentation.md`** now blesses an inline upgrade-path shortcut marker
+  (`# shortcut: ceiling — upgrade path`) as an alternative to a ticketed `TODO`, and points at the
+  `simplification-debt` skill that harvests them.
+- **CI now publishes on merge to `main`, gated by a version check.** `publish.yml` also triggers on
+  every push to `main` (in addition to version tags, releases, and manual dispatch). A `version-check`
+  job compares `pyproject.toml`'s version against PyPI and only builds/publishes when the version is
+  new; an unchanged version is skipped cleanly (PyPI versions are immutable). The publisher also passes
+  `skip-existing: true` as a race guard. Net effect: bump the version in a PR, merge it, and the
+  release ships automatically — no manual tag required.
+
 ## [0.7.1] — 2026-06-09
 
 A parity fix for the no-pip fallback scaffolder so the plugin's `/claude-kit:init` command works

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.7.1
+Version: 0.9.0
 Summary: Cookiecutter-style scaffolder for an autonomous Claude Code SDLC configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop.
 Project-URL: Homepage, https://github.com/ajyadav013/claude-kit
 Project-URL: Repository, https://github.com/ajyadav013/claude-kit
@@ -198,9 +198,10 @@ See [`docs/architecture.md`](docs/architecture.md) for the full diagrams.
 ```mermaid
 flowchart TD
     REQ(["/sdlc request"]) --> CLS{"Classify"}
-    CLS -->|"feature"| SPEC["Spec & Dev Docs → Story Planner"]
+    CLS -->|"feature"| SPEC["Spec & Dev Docs"]
     SPEC --> EM{{"Gate: EM approved"}}
-    EM -->|"pass"| LANES["Parallel lanes:<br/>Senior Dev → Architect → Developer → Code Review"]
+    EM -->|"pass"| STORY["Story breakdown + coverage gate<br/>story-planner"]
+    STORY --> LANES["Parallel lanes:<br/>Senior Dev → Architect → Developer → Code Review"]
     LANES --> MR{{"Gate: Merge Reviewer"}}
     MR --> TEST["Unit · E2E · Integration + Senior verification"]
     TEST --> TCG{{"Gate: Test coverage<br/>+ Devil's Advocate"}}
@@ -231,7 +232,7 @@ your chosen DB, and **org persona agents** added only in organization scope. See
 |-------|------|
 | `orchestrator` | Pipeline controller — decomposes, delegates, runs lanes in parallel, gates progression (never writes code) |
 | `spec-doc-writer` | Turns requirements into a spec + developer documentation in one pass |
-| `story-planner` | Decomposes an approved spec into ordered, parallelizable stories |
+| `story-planner` | Decomposes an approved spec into ordered, parallelizable stories; verifies every acceptance criterion maps to a story (workflow gate 1f) |
 | `ui-designer` | Drafts and self-reviews UI/UX design specs |
 | `senior-backend-dev` · `senior-frontend-dev` | Senior review of a work stream's spec (the two-lane example) |
 | `technical-architect` | Cross-system architecture, scalability, integration review |

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/README.md

@@ -171,9 +171,10 @@ See [`docs/architecture.md`](docs/architecture.md) for the full diagrams.
 ```mermaid
 flowchart TD
     REQ(["/sdlc request"]) --> CLS{"Classify"}
-    CLS -->|"feature"| SPEC["Spec & Dev Docs → Story Planner"]
+    CLS -->|"feature"| SPEC["Spec & Dev Docs"]
     SPEC --> EM{{"Gate: EM approved"}}
-    EM -->|"pass"| LANES["Parallel lanes:<br/>Senior Dev → Architect → Developer → Code Review"]
+    EM -->|"pass"| STORY["Story breakdown + coverage gate<br/>story-planner"]
+    STORY --> LANES["Parallel lanes:<br/>Senior Dev → Architect → Developer → Code Review"]
     LANES --> MR{{"Gate: Merge Reviewer"}}
     MR --> TEST["Unit · E2E · Integration + Senior verification"]
     TEST --> TCG{{"Gate: Test coverage<br/>+ Devil's Advocate"}}
@@ -204,7 +205,7 @@ your chosen DB, and **org persona agents** added only in organization scope. See
 |-------|------|
 | `orchestrator` | Pipeline controller — decomposes, delegates, runs lanes in parallel, gates progression (never writes code) |
 | `spec-doc-writer` | Turns requirements into a spec + developer documentation in one pass |
-| `story-planner` | Decomposes an approved spec into ordered, parallelizable stories |
+| `story-planner` | Decomposes an approved spec into ordered, parallelizable stories; verifies every acceptance criterion maps to a story (workflow gate 1f) |
 | `ui-designer` | Drafts and self-reviews UI/UX design specs |
 | `senior-backend-dev` · `senior-frontend-dev` | Senior review of a work stream's spec (the two-lane example) |
 | `technical-architect` | Cross-system architecture, scalability, integration review |

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/agents/orchestrator.md

@@ -79,6 +79,9 @@ Human PRD
 [MR1] Merge Reviewer ──── verifies spec consistency across lanes
   │
   ▼
+[SP]  Story Planner ───── decomposes spec into ordered stories + verifies every
+  │                       acceptance criterion maps to a story (coverage gate)
+  ▼
 ┌─────── FORK POINT 2 (implementation) ───────────────────────┐
 │                                                              │
 │  LANE A — FRONTEND                  LANE B — BACKEND         │
@@ -139,6 +142,7 @@ Done
 ```
 Spec-Doc Writer → [UI Designer if UI]
   → Senior Dev → Technical Architect → EM
+  → Story Planner (coverage gate)
   → Developer → SDLC Code Reviewer → Unit Tests
   → Tester (full) → Senior Tester (full)
   → PR Raiser
@@ -240,6 +244,24 @@ For full-stack work, **spawn these lanes in parallel**:
 
 ---
 
+### Stage SP: Story Breakdown & Coverage Gate (after the spec is approved + consistent)
+
+The bridge between an approved spec and implementation: decompose, then prove coverage before any
+code is written.
+
+- **Spawn**: `story-planner` with the approved spec (+ design spec and architecture notes, if any).
+- It decomposes the spec into the smallest independently-shippable stories, orders them with an
+  acyclic `blockedBy`/`blocks` graph, identifies the immediately-startable parallel set per lane,
+  and builds a traceability map of **every acceptance criterion → ≥1 story**.
+- **Gate**: every acceptance criterion is covered (no **gap**), no story maps to no criterion (no
+  **scope creep**), the graph is acyclic, and the parallel set is genuinely unblocked. A gap or
+  scope-creep finding routes back to the **Spec Writer** (fix the spec) — never silently into a
+  lane. The story breakdown then drives lane assignment at Fork Point 2.
+- For **single-stack** work (Mode A), this runs after EM approval and before the Developer; there
+  is no merge-reviewer, so the Story Planner runs directly on the EM-approved spec.
+
+---
+
 ### FORK POINT 2: Implementation (Mode B only)
 
 #### Lane A (Frontend Implementation):
@@ -438,6 +460,7 @@ PIPELINE: [FORK 1] Lane A: Tech Architect (iteration 1/3) | Lane B: Sr BE Dev Re
 PIPELINE: [FORK 1] Lane A: EM Review (in progress) | Lane B: Tech Architect (in progress)
 PIPELINE: [FORK 1] Lane A: DONE ✓ | Lane B: EM Review (in progress)
 PIPELINE: [JOIN 1] Merge Reviewer (verifying spec consistency)
+PIPELINE: [SP] Story Planner — acceptance-criterion coverage verified ✓
 PIPELINE: [FORK 2] Lane A: FE Developer (in progress) | Lane B: BE Developer (in progress)
 PIPELINE: [FORK 2] Lane A: FE Code Review (iteration 2/5) | Lane B: BE Unit Tests (running)
 PIPELINE: [FORK 2] Lane A: FE Unit Tests (running) | Lane B: DONE ✓
@@ -478,6 +501,7 @@ PIPELINE: DEFECT LOOP (cycle 1/2) - Backend lane re-entered, re-test API lane on
 | 3c-FE | `em-reviewer` | EM review of frontend | Yes — Lane A |
 | 3c-BE | `em-reviewer` | EM review of backend | Yes — Lane B |
 | JOIN | `merge-reviewer` | Verifies spec consistency | No — gate |
+| SP | `story-planner` | Decomposes spec → ordered stories + acceptance-criterion coverage gate | No — gate |
 | 4a-FE | `developer` (FE mode) | Frontend implementation | Yes — Lane A |
 | 4a-BE | `developer` (BE mode) | Backend implementation | Yes — Lane B |
 | 4b-FE | `sdlc-code-reviewer` | Frontend code review | Yes — Lane A |

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/agents/story-planner.md

@@ -35,7 +35,9 @@ A story breakdown (write it where the spec lives, or to `.claude/state/` for the
 5. **Traceability** — every acceptance criterion in the spec maps to at least one story; flag any
    criterion with no story (a gap) and any story with no criterion (scope creep).
 
-When the task tracker is in use, you may create the corresponding tasks with their dependencies.
+When a task tracker is configured, mirror the stories to it (one issue per story, dependencies
+carried across) using the `task-tracker-sync` skill (`.claude/skills/task-tracker-sync/SKILL.md`) —
+it is tracker-agnostic (GitHub / Linear / Jira) and idempotent. Sync after the coverage gate passes.
 
 ## Constraints
 

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/catalog/profiles.yaml

@@ -79,8 +79,11 @@ profiles:
       - incident-postmortem
       - threat-model
       - accessibility-review
+      - over-engineering-review
+      - simplification-debt
+      - task-tracker-sync
     gates: [spec-complete, em-approved, code-review, build-green, test-coverage, security-clear]
-    hooks: [load-continuity, load-learnings, skill-routing, learning-detection, guard-rm-rf, guard-push-main, protect-secrets, guard-commit-secrets, warn-shared-modules, lint-fix, type-check]
+    hooks: [load-continuity, load-learnings, load-autonomy, skill-routing, learning-detection, guard-rm-rf, guard-push-main, protect-secrets, guard-commit-secrets, warn-shared-modules, lint-fix, type-check]
 
   enterprise:
     label: "Enterprise — adds DevOps, Observability, full audit + acceptance"

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/docs/architecture.md

@@ -87,10 +87,11 @@ independent, and enforces a quality gate between phases. **Only the active profi
 flowchart TD
     REQ(["/sdlc request"]) --> CLS{"Classify:<br/>bug · feature · fast-track"}
 
-    CLS -->|"feature"| SPEC["1. Spec & Dev Docs → Story Planner<br/>spec-doc-writer · story-planner (+ ui-designer if UI)"]
+    CLS -->|"feature"| SPEC["1. Spec & Dev Docs<br/>spec-doc-writer (+ ui-designer if UI)"]
     SPEC --> EM{{"Gate: EM approved<br/>em-reviewer"}}
 
-    EM -->|"pass"| FORK["Fork independent work streams"]
+    EM -->|"pass"| STORY["2. Story breakdown + coverage gate<br/>story-planner: every acceptance criterion → a story"]
+    STORY --> FORK["Fork independent work streams"]
     subgraph LANES["Parallel lanes (canonical example: backend + frontend)"]
         direction LR
         L1["Senior Dev → Tech Architect → Developer → Code Reviewer"]

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/hooks/hooks.json

@@ -4,7 +4,8 @@
       "matcher": "",
       "hooks": [
         { "type": "command", "command": "bash \"${CLAUDE_PLUGIN_ROOT}/hooks/scripts/load-continuity.sh\"" },
-        { "type": "command", "command": "bash \"${CLAUDE_PLUGIN_ROOT}/hooks/scripts/load-learnings.sh\"" }
+        { "type": "command", "command": "bash \"${CLAUDE_PLUGIN_ROOT}/hooks/scripts/load-learnings.sh\"" },
+        { "type": "command", "command": "bash \"${CLAUDE_PLUGIN_ROOT}/hooks/scripts/load-autonomy.sh\"" }
       ]
     }
   ],

claude_code_kit-0.9.0/hooks/scripts/load-autonomy.sh

@@ -0,0 +1,21 @@
+#!/usr/bin/env bash
+# SessionStart hook: surface the repo's active autonomy level so every session operates within it
+# instead of forgetting the dial. The level is chosen at install time and recorded in the config
+# snapshot; this just makes it visible each session. See .claude/rules/autonomy-levels.md.
+#
+# Degrades to a no-op when jq isn't present or no level is recorded (never blocks startup).
+
+ROOT="${CLAUDE_PROJECT_DIR:-$PWD}"
+OPTS="$ROOT/.claude/config/init-options.json"
+
+[ -f "$OPTS" ] || exit 0
+command -v jq >/dev/null 2>&1 || exit 0
+
+LEVEL=$(jq -r '.selection.autonomy // empty' "$OPTS" 2>/dev/null)
+[ -n "$LEVEL" ] || exit 0
+
+echo "## Active autonomy level: $LEVEL"
+echo
+echo "Operate within the \`$LEVEL\` autonomy level for this repo: it bounds how much you may do before a human acts. See .claude/rules/autonomy-levels.md for what this level permits and what still needs human sign-off."
+
+exit 0

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.7.1"
+version = "0.9.0"
 description = "Cookiecutter-style scaffolder for an autonomous Claude Code SDLC configuration (no app code, no Docker). Asks ordered questions and installs CLAUDE.md + .claude/ (rules, the chosen profile's agents/skills, hooks, artifact templates) + optional .mcp.json; run /sdlc to drive spec → review → build → test → security → ship through profile-aware quality gates, working memory, and a self-improving learnings loop."
 readme = "README.md"
 requires-python = ">=3.9"

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/rules/documentation.md

@@ -260,6 +260,10 @@ class UserCreate(BaseModel):
 - **Performance decisions**: `# Eager-load to prevent N+1 on the list page`
 - **Security decisions**: `# Rate limit to 5 req/min to prevent credential stuffing`
 - **TODO with ticket**: `# TODO(PROJ-123): Replace with proper RBAC once permissions service is built`
+- **Deliberate shortcut with an upgrade path**: name the ceiling and the trigger inline, as an
+  alternative to an external ticket: `# shortcut: global lock — per-account locks if throughput matters`.
+  A deferral with no trigger is the kind that silently rots; the `simplification-debt` skill harvests
+  these markers into a ledger and flags any that name no upgrade path.
 
 ### Do NOT Comment
 - What the code does when it's obvious from the code itself

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/rules/evals.md

@@ -47,6 +47,27 @@ the one that matches how the feature is actually used.
   (`.claude/rules/quality-gates.md`).
 - **Capability** — pushes the frontier; tracks progress on hard cases you don't pass yet.
 
+## 6. Run repeated trials, and split measurement from gate
+
+A single run of a non-deterministic feature tells you almost nothing. Two practices keep the numbers
+honest:
+
+- **Repeat and aggregate.** Run each case **N times** (commonly 5–10) and report the **median**, not
+  the mean — the median is robust to the occasional wild outlier a model produces. Report N alongside
+  the result; a "90%" from one run and from twenty runs are not the same claim.
+- **Separate metrics that *measure* from metrics that *gate*.** A **measurement** metric records a
+  number and always passes (lines of code, token cost, latency, output length) — it's there to track a
+  trend, not to block. A **gate** metric actually exercises the output and **fails** when it breaks
+  (run the generated code, assert the result, check the file state). Don't let a measurement masquerade
+  as a gate: a solution that scores beautifully on "fewer lines" but doesn't run must still **fail**,
+  because the correctness gate executed it. Wire only gate metrics into `.claude/rules/quality-gates.md`;
+  keep measurements as dashboards.
+
+> Worked example: the [ponytail](https://github.com/DietrichGebert/ponytail) benchmark runs 3 arms ×
+> 3 models × 5 tasks at 10 runs each (median reported), with a line-count *measurement* that always
+> passes beside a *correctness gate* that spawns the runtime to actually execute the generated code.
+> A concrete instance of this section's two practices.
+
 ## Rules
 
 1. **No prompt/rule/tool/model change ships without an eval run** that covers the affected behavior.

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/rules/mandatory-workflow.md

@@ -107,13 +107,13 @@ handled by a dedicated agent in `.claude/agents/`.
 ```
 Phase 1 — Planning (Stages 0-3)   ║  Phase 2 — Development (4-5)   ║  Phase 3 — Testing & Delivery (6-7)
 [0] Orchestrator receives request ║  [4] Developer writes code      ║  [6a] Unit Tester ─┐
-1a→1b→1c→1d→1e ───────────────────╬──► 2a→2b→2c→2d ────────────────╬──► [6b] E2E Tester ─┤ (parallel)
+1a→1b→1c→1d→1e→1f ─────────────────╬──► 2a→2b→2c→2d ────────────────╬──► [6b] E2E Tester ─┤ (parallel)
 Understand→Clarify→Spec→Dev docs  ║  Read→Implement→Quality gate    ║  3a→3b→3c→3d
-→ EM review                       ║  → Code review                  ║  → Security → DevOps/Obs → PR → Human
+→ EM review → Story breakdown      ║  → Code review                  ║  → Security → DevOps/Obs → PR → Human
 ```
 
 **Pipeline rules:**
-- No code is written until Phase 1 is complete (EM approval required).
+- No code is written until Phase 1 is complete (EM approval + story-coverage gate required).
 - No testing starts until Phase 2 code review passes.
 - No PR is created until all tests pass (unit + E2E).
 - No task is marked done until the user has reviewed and accepted.
@@ -151,7 +151,25 @@ table (each requirement → implementation approach → files).
 A skeptical Engineering Manager reviews the dev docs for completeness, quality (simplest
 approach, no over/under-engineering), non-functional concerns, and architecture fit.
 Feedback loops with the Dev Doc Writer, **max 3 iterations**, then escalate.
-**Gate:** EM signals `APPROVED`. Development CANNOT start without it.
+**Gate:** EM signals `APPROVED`. The story breakdown CANNOT start without it.
+
+## 1f — Story Breakdown & Coverage Gate `[Story Planner]`
+With the EM-approved spec, the **Story Planner** decomposes it into the smallest set of
+independently shippable stories, ordered by dependency, and identifies which can run in parallel
+(per lane). It builds a **traceability map**: every acceptance criterion → at least one story.
+
+This is the spec↔stories coverage check *before* any code is written — the gate that catches an
+acceptance criterion no story covers (a **gap**) and a story that maps to no criterion (**scope
+creep**), so both are fixed on paper rather than discovered mid-implementation. A gap or
+scope-creep finding routes back to the Spec Writer (fix the spec), never silently into the code.
+
+**Output:** a story breakdown (written where the spec lives, or to `.claude/state/`) with stable
+story ids, the criteria each satisfies, an acyclic `blockedBy`/`blocks` dependency graph, and the
+immediately-startable parallel set. When a task tracker is configured, the stories can be mirrored
+to it — see `.claude/skills/task-tracker-sync/SKILL.md`.
+**Gate:** every acceptance criterion is covered by ≥1 story (no gaps), no story lacks a criterion
+(no scope creep), the graph is acyclic, and the parallel set is genuinely unblocked. Implementation
+CANNOT start until coverage is complete.
 
 ---
 
@@ -270,6 +288,7 @@ B1 understand → B2 failing test → B3 root cause → B4 fix → B5 quality ga
 ```
 Phase 1: 1a Understand [Orchestrator] → 1b Clarify → 1c Spec [Spec Writer]
   → 1d Dev docs [Dev Doc Writer] → 1e EM review [EM Reviewer, max 3]
+  → 1f Story breakdown + coverage gate [Story Planner]
 Phase 2: 2a Read code [Developer] → 2b Implement → 2c Code review [Code Reviewer, max 5] → 2d Impact check
 Phase 3: 3a Unit tests ─┐ 3b E2E tests ─┘ (parallel)
   → 3b.5 Test-coverage gate (blind review + Devil's Advocate)
@@ -282,7 +301,8 @@ Phase 3: 3a Unit tests ─┐ 3b E2E tests ─┘ (parallel)
 |------|-----------------|
 | Requirements clarified (1b) | Spec Writer starts |
 | Spec approved by user (1c) | Dev Doc Writer starts |
-| EM `APPROVED` (1e) | Developer starts coding |
+| EM `APPROVED` (1e) | Story Planner starts |
+| Story coverage complete — every criterion mapped, no scope creep (1f) | Developer starts coding |
 | Code Reviewer `APPROVED` (2c) | Testing starts |
 | Both testers pass (3a+3b) | Test-coverage gate |
 | Test-coverage PASS/CONFIRMED (3b.5) | Security review |

claude_code_kit-0.9.0/skills/over-engineering-review/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: over-engineering-review
+description: Scans code for over-engineering ONLY and returns a terse delete-list — what to cut and what replaces it — without applying any change. Use when the user asks "what can we delete", "is this over-engineered", "find the bloat", "lean review", "trim this", or wants a complexity-only pass over a diff or a whole repo. Complements (does not replace) the multi-axis code-review-and-quality skill, and stops short of the refactoring that code-simplification performs.
+---
+
+# Over-Engineering Review
+
+> A single-lens scan inspired by the [ponytail](https://github.com/DietrichGebert/ponytail) plugin's
+> review/audit commands. Adapted as a stack-agnostic, report-only skill. It is deliberately **narrow**:
+> it hunts complexity and nothing else.
+
+## What this is (and is not)
+
+- **This skill:** one lens — over-engineering. Output is a **delete-list**: one line per finding,
+  naming what to cut and the leaner replacement. It **reports; it does not edit**.
+- **Not `code-review-and-quality`:** that is the full multi-axis gate (correctness, security,
+  performance, architecture, readability) you run before merge. Use it for the real review. Use *this*
+  when you want the complexity axis alone, in a scannable form, with no other noise.
+- **Not `code-simplification`:** that skill *applies* the refactor and preserves behavior step by step.
+  This skill produces the list; hand the list to `code-simplification` (or a developer) to execute.
+
+## When to use
+
+- "What can we delete from this?" / "Is this over-engineered?" / "Find the bloat."
+- A pre-merge lean pass on a diff, before the full review.
+- A periodic whole-repo audit for accreted complexity.
+
+## Scope
+
+- **Diff mode (default):** scan the current change (`git diff`, staged, or a PR). Prefix findings with
+  the line; for multi-file diffs prefix with `file:line`.
+- **Repo mode:** scan the whole tree. Rank findings biggest-cut-first.
+
+State which mode you ran in one line at the top.
+
+## The five tags
+
+Every finding carries exactly one tag and names its replacement:
+
+- `delete:` — dead code, unused flexibility, a speculative feature. Replacement: nothing.
+- `stdlib:` — a hand-rolled thing the language's standard library already ships. Name the function.
+- `native:` — a dependency or code doing what the platform already does (a built-in input type, a CSS
+  feature, a DB constraint, a framework primitive). Name the feature.
+- `yagni:` — an abstraction with one implementation, a config nobody sets, a layer with one caller,
+  a factory with one product, a wrapper that only delegates.
+- `shrink:` — same logic, fewer lines. Show the shorter form.
+
+## What to hunt (repo mode checklist)
+
+Dependencies the stdlib or platform already ships · single-implementation interfaces · factories with
+one product · wrappers that only delegate · modules exporting one thing · dead flags and config ·
+hand-rolled stdlib · speculative "for later" scaffolding.
+
+## Output format
+
+One line per finding. Diff mode:
+
+```
+L<line>: <tag> <what>. <replacement>.
+file:L<line>: <tag> <what>. <replacement>.   # multi-file
+```
+
+Repo mode, ranked biggest-cut-first:
+
+```
+<tag> <what to cut>. <replacement>. [path]
+```
+
+End with the only metric that matters:
+
+- diff mode: `net: -<N> lines possible.`
+- repo mode: `net: -<N> lines, -<M> deps possible.`
+
+If there is nothing worth cutting, say `Lean already. Ship.` and stop. Do not invent findings to look
+thorough — a clean report is a valid report.
+
+### Examples (stack-neutral)
+
+```
+L12-38: stdlib: 27-line e-mail validator. An "@"/structure check is one line; real validation is the confirmation step.
+L4:     native: a date-picker dependency for one field. The platform's built-in date input, 0 deps.
+repo/store.*:L88: yagni: AbstractRepository with one implementation. Inline it until a second exists. [src/store]
+L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.
+L30-44: shrink: manual loop building a map. The stdlib zip/dict constructor, 1 line.
+net: -120 lines, -1 dep possible.
+```
+
+## Boundaries (do not over-cut)
+
+- **Complexity only.** Correctness bugs, security holes, and performance go to a normal review pass
+  (`code-review-and-quality`) — not this one. If you spot one, note it in a single line under a
+  `# out of scope:` heading; don't fold it into the delete-list.
+- **Never flag the required check.** This kit mandates a runnable test/verification for non-trivial
+  logic (`.claude/rules/testing.md`, `quality-gates.md`). The smallest test that proves the logic is
+  **not** bloat — never list it for deletion.
+- **Never flag the carve-outs.** Input validation at trust boundaries, error handling that prevents
+  data loss, security controls, and accessibility are not over-engineering. Leave them.
+- **Report only.** This skill lists findings and applies nothing. Approving and executing the cuts is a
+  separate, deliberate step (`code-simplification` for behavior-preserving edits).

{claude_code_kit-0.7.1 → claude_code_kit-0.9.0}/skills/planning-and-task-breakdown/SKILL.md

@@ -193,6 +193,12 @@ When multiple agents or sessions are available:
 - **Must be sequential:** Database migrations, shared state changes, dependency chains
 - **Needs coordination:** Features that share an API contract (define the contract first, then parallelize)
 
+## Pushing the plan to a tracker
+
+Once the breakdown is approved and you want it tracked, the `task-tracker-sync` skill mirrors it into
+the project's configured issue tracker (GitHub / Linear / Jira) — one issue per task, dependencies
+preserved, idempotent. It syncs an existing breakdown; it does not create one.
+
 ## Common Rationalizations
 
 | Rationalization | Reality |

claude_code_kit-0.9.0/skills/simplification-debt/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: simplification-debt
+description: Harvests deliberately-deferred shortcuts from the codebase into one debt ledger, so "later" does not quietly become "never". Greps for TODO/FIXME/HACK markers and inline upgrade-path notes, groups them by file, and flags any shortcut that names no upgrade trigger as a silent-rot risk. Use when the user says "what did we defer", "list the shortcuts", "tech-debt ledger", "what's marked to do later", or "simplification debt". Reports only — changes nothing unless asked to persist the ledger.
+---
+
+# Simplification Debt
+
+> Inspired by the [ponytail](https://github.com/DietrichGebert/ponytail) plugin's debt-harvest idea.
+> A deliberate shortcut is fine — an *untracked* one rots. This skill collects them into one place so a
+> deferral stays visible until someone revisits it.
+
+## The convention it harvests
+
+A deliberate shortcut should record two things at the point it's taken: its **ceiling** (the limit it
+hits) and its **upgrade path** (the trigger to revisit). claude-kit recognizes two equivalent forms
+(see `.claude/rules/documentation.md`):
+
+- **Ticketed:** `TODO(PROJ-123): naive O(n²) scan; switch to an index if the list grows.`
+- **Inline upgrade path:** `# shortcut: global lock — per-account locks if throughput matters.`
+
+Both are legitimate. A shortcut with **no** trigger ("TODO: fix later") is the one that rots.
+
+## Scan
+
+Grep the repo for shortcut markers, skipping vendored and build output (`node_modules`, `.git`,
+`dist`, `build`, `vendor`, `target`, etc.). The pattern is language-neutral — markers live in comments,
+so match common comment prefixes (`#`, `//`, `--`, `;`, `<!--`):
+
+```
+grep -rniE '(#|//|--|;|<!--)[[:space:]]*(TODO|FIXME|HACK|XXX|shortcut|ponytail):' . \
+  --exclude-dir={.git,node_modules,dist,build,vendor,target,.venv}
+```
+
+Add your stack's comment prefix if it differs. Each hit is one ledger row. Matching on the comment
+prefix keeps prose that merely *mentions* the convention out of the ledger.
+
+## Output
+
+One row per marker, grouped by file:
+
+```
+<file>:<line> — <what was simplified>. ceiling: <the limit named>. upgrade: <the trigger to revisit>.
+```
+
+Pull the ceiling and trigger straight from the comment when the `<ceiling>, <upgrade>` form is used.
+Want an owner per row? add `git blame -L<line>,<line> <file>`.
+
+**Flag the rot risk:** any marker that names no upgrade path or trigger gets a `no-trigger` tag — those
+are the deferrals that silently become permanent.
+
+End with a one-line tally:
+
+```
+<N> markers, <M> with no trigger.
+```
+
+Nothing found: `No deferred shortcuts. Clean ledger.`
+
+## Persisting (only if asked)
+
+By default this reports to the conversation and changes nothing. If the user wants it tracked, write the
+ledger to a file they choose (e.g. `SIMPLIFICATION-DEBT.md` at the repo root, or an entry under the
+artifacts dir). Don't create the file unprompted.
+
+## Boundaries
+
+- **Reads and reports only.** It never edits code or removes markers.
+- **Not a linter.** It surfaces *intentional* shortcuts to keep them honest; it does not judge code it
+  wasn't told about.
+- Pairs with `over-engineering-review` (find complexity to cut now) and `code-simplification` (perform
+  the cut). This skill is about the shortcuts you *chose* to leave behind.