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

{claude_code_kit-0.8.0 → 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.8.0",
+      "version": "0.9.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

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

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.8.0",
+  "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.8.0 → claude_code_kit-0.9.0}/CHANGELOG.md

@@ -4,6 +4,41 @@ 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.8.0
+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.8.0 → 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.8.0 → 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.8.0 → 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.8.0 → claude_code_kit-0.9.0}/catalog/profiles.yaml

@@ -81,6 +81,7 @@ profiles:
       - 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, load-autonomy, skill-routing, learning-detection, guard-rm-rf, guard-push-main, protect-secrets, guard-commit-secrets, warn-shared-modules, lint-fix, type-check]
 

{claude_code_kit-0.8.0 → 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.8.0 → claude_code_kit-0.9.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.8.0"
+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.8.0 → 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.8.0 → 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/task-tracker-sync/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: task-tracker-sync
+description: Mirrors an existing task or story breakdown into the project's issue tracker as issues, preserving dependencies. Use after planning/story breakdown when the user wants the plan pushed to GitHub / Linear / Jira (e.g. "create issues for these tasks", "sync the plan to the tracker"). Does not create the breakdown — it syncs one that already exists.
+---
+
+# Task Tracker Sync
+
+## Overview
+
+Turn a finished plan into tracked work. Given a task or story breakdown that **already exists**
+(from `planning-and-task-breakdown`, the `story-planner` agent, or a plan document), create one
+issue per task in whatever issue tracker the project has configured, carrying the dependency graph
+across so the tracker mirrors the plan instead of a flat dump of tickets.
+
+This skill **consumes** a breakdown; it never invents one. If no plan exists yet, run
+`planning-and-task-breakdown` (or the `story-planner` agent) first, then sync its output.
+
+## When to Use
+
+- A plan / story breakdown is approved and the user wants it in the tracker for execution.
+- The user says "create issues for these tasks", "open tickets", "push this to Linear/Jira/GitHub".
+- Stories from the workflow's stage 1f (Story Planner) need tracker counterparts before lanes start.
+
+**When NOT to use:** there is no breakdown yet (plan first); a single throwaway task; or the user
+only wants a local checklist, not tracker issues.
+
+## Tracker-agnostic by design
+
+claude-kit does not assume a tracker. Use whichever **issue-tracker MCP server** is configured for
+the project (see `.mcp.json` / the catalog): GitHub, Linear, Jira, or another. Discover the
+tracker's create/update tools at run time and use them — never hardcode one vendor's API.
+
+If **no** tracker MCP is configured: stop and say so. Offer to (a) emit the issues as a Markdown
+checklist the user can paste, or (b) wait until a tracker is set up. Do not fabricate issue URLs.
+
+## The Sync Process
+
+1. **Read the breakdown.** Load the plan/story file. For each task capture: title, body (the
+   description + acceptance criteria + verification steps + files-touched), a stable local id, and
+   its `blockedBy`/`blocks` dependencies. Reference the spec requirement ids (R1, R2…) in the body
+   so each issue traces back to the spec.
+2. **Detect the tracker.** Identify the configured issue-tracker MCP and the fields it supports
+   (labels, milestones, parent/child, issue links / "blocks" relations).
+3. **Reconcile before creating (idempotent).** Search the tracker for existing issues matching each
+   task (by a stable marker in the title or body, e.g. the story id). **Update** a match; **create**
+   only what's genuinely missing. Re-running the sync must not produce duplicates.
+4. **Create issues** for the unmatched tasks: title, structured body, and any labels the project
+   uses. Record the new issue id/URL against the local task id.
+5. **Wire dependencies.** Once every task has a tracker id, translate `blockedBy`/`blocks` into the
+   tracker's native relation (issue links, task lists, or parent/child). If the tracker can't express
+   a relation, note it in the issue body ("Blocked by #N") rather than dropping it.
+6. **Report.** A table of local task id → issue URL → created|updated, plus any dependency links
+   made and anything that needs manual attention.
+
+## Constraints
+
+- **Confirm before writing.** Creating tracker issues is an outward-facing action — show the user
+  what will be created/updated and how many, and get a go-ahead before the first write, unless they
+  already said "just do it".
+- **Idempotent.** Match-then-update; never blind-create. A second run is a no-op when nothing changed.
+- **Faithful, not creative.** Sync the tasks as written. Don't reword acceptance criteria, split,
+  merge, or add tasks here — that's the planner's job. Round-trip changes through the plan, then
+  re-sync.
+- **No secrets.** Never put credentials or tokens in issue bodies. Tracker auth comes from the MCP
+  server's configured env vars, not from anything you write.
+
+## Verification
+
+- [ ] Every task in the breakdown has exactly one corresponding tracker issue (no duplicates).
+- [ ] Dependencies are represented in the tracker (native links) or explicitly noted in bodies.
+- [ ] Each issue body traces to its spec requirement id(s) and lists acceptance criteria.
+- [ ] A re-run reports all "updated"/"unchanged" — zero accidental new issues.

{claude_code_kit-0.8.0 → claude_code_kit-0.9.0}/src/claude_kit/__init__.py

@@ -7,4 +7,4 @@ Docker): ``claude-kit init`` asks ordered questions and lays down ``CLAUDE.md``
 as a plugin. Extensibility is data-driven via the ``catalog/`` (stacks, profiles, MCP).
 """
 
-__version__ = "0.8.0"
+__version__ = "0.9.0"

claude_code_kit-0.9.0/templates/artifacts/feature-spec.md

@@ -0,0 +1,44 @@
+# Feature spec: <name>
+
+> Produced before implementation (see `.claude/rules/mandatory-workflow.md`). Keep it explicit
+> enough to review. Give each requirement a stable id: the **Story Planner** (workflow stage 1f)
+> maps every acceptance criterion below to an implementation story, so coverage gaps and scope
+> creep are caught on paper, not mid-build.
+
+## Problem / motivation
+What user need or problem does this address? Why now?
+
+## Goals / non-goals
+- Goals:
+- Non-goals:
+
+## Requirements & acceptance criteria
+Each requirement gets a stable id (R1, R2, …) so stories and tests can trace back to it. Every
+requirement needs at least one acceptance criterion phrased as a checkable Given/When/Then.
+
+- **R1** — <requirement>
+  - [ ] Given … when … then …
+- **R2** — <requirement>
+  - [ ] Given … when … then …
+
+## Assumptions
+Defaults chosen where the request was silent — state them so they can be corrected *before* coding,
+not discovered after. (Open, still-undecided questions belong under "Rollout / open questions", not
+here; an assumption is a decision you are proceeding on unless told otherwise.)
+
+- …
+
+## Scope
+Affected modules / files / surfaces. Independent work streams (e.g. backend lane, frontend lane).
+
+## Design
+Approach, data model / API contract changes, key decisions (link ADRs for significant ones).
+
+## Risks & constraints
+Deadline, compatibility, security, performance, compliance.
+
+## Test plan (summary)
+What unit / integration / e2e coverage proves each requirement's acceptance criteria (reference the
+R-ids). Detail lives in test-plan.md.
+
+## Rollout / open questions

claude_code_kit-0.8.0/templates/artifacts/feature-spec.md

@@ -1,29 +0,0 @@
-# Feature spec: <name>
-
-> Produced before implementation (see `.claude/rules/mandatory-workflow.md`). Keep it explicit
-> enough to review.
-
-## Problem / motivation
-What user need or problem does this address? Why now?
-
-## Goals / non-goals
-- Goals:
-- Non-goals:
-
-## Acceptance criteria
-- [ ] Given … when … then …
-- [ ] …
-
-## Scope
-Affected modules / files / surfaces. Independent work streams (e.g. backend lane, frontend lane).
-
-## Design
-Approach, data model / API contract changes, key decisions (link ADRs for significant ones).
-
-## Risks & constraints
-Deadline, compatibility, security, performance, compliance.
-
-## Test plan (summary)
-What unit / integration / e2e coverage proves the acceptance criteria. (Detail in test-plan.md.)
-
-## Rollout / open questions