claude-code-kit 0.32.0__tar.gz → 0.34.0__tar.gz

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

{claude_code_kit-0.32.0 → claude_code_kit-0.34.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.32.0",
+  "version": "0.34.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.32.0 → claude_code_kit-0.34.0}/CHANGELOG.md

@@ -4,6 +4,42 @@ 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.34.0] — 2026-06-25
+
+**Delta-specs + change-scoped artifacts** (pattern adopted from [OpenSpec](https://github.com/Fission-AI/OpenSpec),
+MIT; re-derived in claude-kit's idiom). The spec flow was greenfield-only — every change wrote a full
+spec. This adds an incremental path for brownfield work, mirroring how `api-change-report.md` already
+complements `feature-spec.md` for API contracts:
+
+- **New `templates/artifacts/change-proposal.md`** — a delta spec keyed to the base spec's stable
+  `R#` ids, with `ADDED` (new requirement + Given/When/Then) / `MODIFIED` (`was: … → now: …` + acceptance
+  delta) / `REMOVED` (reason + migration) sections, change-scoped scope, a backward-compat/migration
+  section, and a delta test plan. Auto-installs into `.claude/templates/` (no scaffold change).
+- **`skills/spec-driven-development/SKILL.md`** — adds a "Full spec vs delta spec" decision (new system →
+  full `feature-spec.md`; change to an already-specced system → delta `change-proposal.md`), a
+  "Keeping the Spec Alive" pointer, and an incremental-change clause in the `description:` frontmatter.
+  Delta criteria still feed the stage-1f coverage gate.
+- **`templates/artifacts/feature-spec.md`** — preamble now points incremental changes at the delta template.
+
+New test asserts the template ships with delta notation. No count changes (templates aren't counted).
+
+## [0.33.0] — 2026-06-25
+
+**Pre-code Reuse & YAGNI gate** (pattern adopted from the [ponytail](https://github.com/DietrichGebert/ponytail)
+plugin, MIT; re-derived in claude-kit's idiom, no vendored code). The kit's complexity controls were all
+*reactive* (the `over-engineering-review` skill scans bloat out after code exists). This adds the proactive
+twin:
+
+- **`rules/mandatory-workflow.md` §2a.5 — Reuse & YAGNI Gate** — a new Phase-2 stage between "read code"
+  (2a) and "write code" (2b). Before adding any new file/function/abstraction, the developer walks a
+  stop-at-first-rung ladder — *needs to exist? → already in the codebase? → stdlib? → native platform
+  feature? → existing dependency? → minimum that works?* — applying the same delete/stdlib/native/yagni/
+  shrink lenses as `over-engineering-review`, but *before* the code is written. Wired into the Quick
+  Reference flow and the pipeline-gating table.
+- **`skills/over-engineering-review/SKILL.md`** — cross-links the gate as its proactive twin.
+
+No catalog/hook/agent/count changes; existing commands unaffected.
+
 ## [0.32.0] — 2026-06-25
 
 **Two patterns adopted from Agent-Reach (MIT); no behavior change to existing commands.**

{claude_code_kit-0.32.0 → claude_code_kit-0.34.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.32.0
+Version: 0.34.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

{claude_code_kit-0.32.0 → claude_code_kit-0.34.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.32.0"
+version = "0.34.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.32.0 → claude_code_kit-0.34.0}/rules/mandatory-workflow.md

@@ -202,6 +202,30 @@ app entry points, shared barrels) require telling the user what and why, the imp
 getting approval first. NEVER add/remove/upgrade dependencies without confirmation.
 **Gate:** you understand every file/function you'll touch; the file list is task-scoped only.
 
+## 2a.5 — Reuse & YAGNI Gate `[Developer]`
+The cheapest code is the code you never write. Before adding a single new file, function, type, or
+abstraction, walk this ladder and **stop at the first rung that satisfies the need** — only what
+survives every rung gets written:
+
+1. **Does it need to exist at all?** If the task is satisfiable without this code, don't write it.
+2. **Already in the codebase?** Search first; reuse the existing utility, component, or pattern
+   rather than adding a parallel one.
+3. **Standard library?** Prefer the language's stdlib over a hand-rolled equivalent.
+4. **Native platform feature?** A built-in input type, a CSS feature, a DB constraint, a framework
+   primitive — use it before adding a dependency or custom code.
+5. **An existing dependency?** Reuse something already installed before pulling in a new one (and
+   adding a dependency needs user approval — see 2a).
+6. **The minimum that works?** No abstraction with a single caller, no config nobody sets, no layer
+   that only delegates, no flexibility no requirement asks for.
+
+Record any deliberate shortcut where you take it — `# shortcut: <ceiling> — <upgrade path>` (see
+`.claude/skills/simplification-debt/SKILL.md`) — so it is traceable, not silent debt.
+
+This is the **proactive twin** of the reactive `over-engineering-review` skill: the same
+delete/stdlib/native/yagni/shrink lenses, applied *before* the code exists rather than scanned out
+after. **Gate:** every new unit of code traces to a rung you could not satisfy more cheaply, and the
+implementation adds no abstraction the spec does not require.
+
 ## 2b — Write Implementation Code `[Developer]`
 Follow the approved spec + dev docs and your stack's rules.
 - Put files in the correct module/package; don't put module-specific code in shared dirs.
@@ -309,7 +333,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]
   → 1e.5 Plan critique [Devil's Advocate, standard+] → 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 2: 2a Read code [Developer] → 2a.5 Reuse/YAGNI gate → 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)
   → 3b.6 Security (Security Clear) → 3b.7 DevOps + Observability (if applicable)
@@ -324,6 +348,7 @@ Phase 3: 3a Unit tests ─┐ 3b E2E tests ─┘ (parallel)
 | EM `APPROVED` (1e) | Plan critique (standard+) / Story Planner starts |
 | Plan critique CONFIRMED (1e.5, standard+) | Story breakdown is final |
 | Story coverage complete — every criterion mapped, no scope creep (1f) | Developer starts coding |
+| Reuse & YAGNI gate cleared (2a.5) | Writing implementation code (2b) |
 | 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.32.0 → claude_code_kit-0.34.0}/skills/over-engineering-review/SKILL.md

@@ -18,6 +18,10 @@ description: Scans code for over-engineering ONLY and returns a terse delete-lis
   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.
+- **Proactive twin — `mandatory-workflow.md` §2a.5:** this skill scans complexity *out* after code
+  exists; the **Reuse & YAGNI Gate** (`.claude/rules/mandatory-workflow.md`, stage 2a.5) applies the
+  same five lenses *before* code is written. Run the gate to avoid the bloat; run this skill to catch
+  what slipped through.
 
 ## When to use
 

{claude_code_kit-0.32.0 → claude_code_kit-0.34.0}/skills/spec-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spec-driven-development
-description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Do NOT use when a spec or clear requirements already exist and you are ready to implement (use test-driven-development) or when you only need to pressure-test a decision that has already been made (use doubt-driven-development).
+description: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. For an incremental change to an existing, already-specced system, write a delta change-proposal (ADDED/MODIFIED/REMOVED) rather than a full spec. Do NOT use when a spec or clear requirements already exist and you are ready to implement (use test-driven-development) or when you only need to pressure-test a decision that has already been made (use doubt-driven-development).
 ---
 
 # Spec-Driven Development
@@ -19,6 +19,8 @@ Write a structured specification before writing any code. The spec is the shared
 
 **When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.
 
+**Full spec vs delta spec.** A brand-new project or feature gets a full spec (the `feature-spec.md` template). An *incremental change to a system that already has a spec* — modify existing behavior, add one route, deprecate a field — gets a **delta change-proposal** instead: capture only the `ADDED` / `MODIFIED` / `REMOVED` requirements against the base spec's stable ids, not a full rewrite. Use the `change-proposal.md` template (`.claude/templates/change-proposal.md`). It keeps the base spec authoritative, makes the diff reviewable, and still feeds the stage-1f coverage gate (every new or changed acceptance criterion maps to a story). Externally-exposed API contract deltas additionally get an `api-change-report.md`.
+
 ## The Gated Workflow
 
 Spec-driven development has four phases. Do not advance to the next phase until the current one is validated.
@@ -168,6 +170,7 @@ The spec is a living document, not a one-time artifact:
 
 - **Update when decisions change** — If you discover the data model needs to change, update the spec first, then implement.
 - **Update when scope changes** — Features added or cut should be reflected in the spec.
+- **Capture substantial changes as a delta, not a rewrite** — once a spec exists, a later change to that system is a `change-proposal.md` (ADDED/MODIFIED/REMOVED against the base R-ids), keeping history legible and the base spec authoritative rather than overwriting it.
 - **Commit the spec** — The spec belongs in version control alongside the code.
 - **Reference the spec in PRs** — Link back to the spec section that each PR implements.
 

{claude_code_kit-0.32.0 → claude_code_kit-0.34.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.32.0"
+__version__ = "0.34.0"

claude_code_kit-0.34.0/templates/artifacts/change-proposal.md

@@ -0,0 +1,42 @@
+# Change proposal: <name>
+
+> A **delta spec** for an incremental change to an existing, already-specced system — use this
+> instead of a full `feature-spec.md` when you are modifying behavior a prior spec/system already
+> defines. Reference the base spec's stable requirement ids (R1, R2, …); the **Story Planner**
+> (workflow stage 1f) maps every *new or changed* acceptance criterion to a story, exactly as for a
+> full spec. Greenfield work uses `feature-spec.md`; externally-exposed API contract deltas also get
+> an `api-change-report.md`.
+
+## Motivation / trigger
+What changed in the world (a bug, a new requirement, a deprecation, scale) that makes this edit
+necessary? Why now?
+
+## Affected requirements (delta)
+Only the requirements this change touches. Keep the base spec's ids stable; add new ones with the
+next free number. Every ADDED or MODIFIED requirement needs at least one checkable Given/When/Then.
+
+### Added
+- **R<new>** — <new requirement>
+  - [ ] Given … when … then …
+
+### Modified
+- **R<existing>** — was: <old behavior> → now: <new behavior>. Why: <reason>.
+  - [ ] Given … when … then …   ← the acceptance delta (what changed about "done")
+
+### Removed
+- **R<existing>** — removed because <reason>. Migration / cleanup: <what consumers must do>.
+
+## Scope (changed artifacts only)
+The specific files / modules / surfaces this delta touches — nothing else. Note independent lanes if
+the change spans more than one.
+
+## Backward compatibility / migration
+Is the change **additive** (existing behavior unchanged) or **breaking**? For breaking changes: the
+migration path, the deprecation window, and the version bump. For API surfaces, cross-link the
+`api-change-report.md` (the contract-clear gate).
+
+## Test plan (delta)
+Which existing tests change (and how), and which new tests prove each ADDED / MODIFIED criterion
+(reference the R-ids). Untouched requirements keep their existing coverage — do not re-litigate them.
+
+## Rollout / open questions

{claude_code_kit-0.32.0 → claude_code_kit-0.34.0}/templates/artifacts/feature-spec.md

@@ -4,6 +4,10 @@
 > 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.
+>
+> This template is for a **new** project or feature. For an *incremental change to a system that
+> already has a spec*, write a delta `change-proposal.md` (ADDED/MODIFIED/REMOVED) instead of
+> rewriting the whole spec.
 
 ## Problem / motivation
 What user need or problem does this address? Why now?