claude-code-kit 0.33.0__tar.gz → 0.35.0__tar.gz

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

{claude_code_kit-0.33.0 → claude_code_kit-0.35.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.33.0",
+  "version": "0.35.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.33.0 → claude_code_kit-0.35.0}/CHANGELOG.md

@@ -4,6 +4,40 @@ 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.35.0] — 2026-06-25
+
+**3-strike fix-attempt discipline** (pattern adopted from gstack's "Iron Law" + the superpowers
+`systematic-debugging` skill, both MIT; re-derived in claude-kit's idiom). Retry *budgets* existed for
+gates and operations, but nothing bounded blind *fix* attempts on a single bug:
+
+- **`rules/agent-resilience.md` — new "Fix-attempt discipline (the 3-strike rule)" section.** Attempts
+  1–2 must each test a *different, explicit* hypothesis (a near-duplicate edit doesn't count). At the
+  3rd failed attempt: STOP — re-derive the root cause (`debugging-and-error-recovery` skill), question
+  whether the *approach/architecture* is wrong (not the line), then escalate via `human-in-the-loop.md`
+  with what each attempt ruled out. Explicitly scoped against the `quality-gates.md` defect-loop budget
+  (that bounds review→fix cycles across the pipeline; this bounds blind attempts within one issue).
+
+Single-rule, count-neutral change; existing commands unaffected.
+
+## [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)

{claude_code_kit-0.33.0 → claude_code_kit-0.35.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.33.0
+Version: 0.35.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.33.0 → claude_code_kit-0.35.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.33.0"
+version = "0.35.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.33.0 → claude_code_kit-0.35.0}/rules/agent-resilience.md

@@ -41,6 +41,25 @@ Operation fails
 | **Idempotency awareness** | Before retrying a side-effecting action | Re-running a commit/write/deploy/API-POST can double-apply. Check state first; make the retry safe. |
 | **Checkpointing** | Long runs, before risky steps, pre-compaction | Write `.claude/CONTINUITY.md` so a crash/compaction resumes from the last good state, not from zero. See `.claude/rules/continuity.md`. |
 
+## Fix-attempt discipline (the 3-strike rule)
+
+Bounded retry applies to *fixes*, too. Three failed attempts at the same failure is not a
+fourth-attempt problem — it is a signal that you do not yet understand the root cause, or the design
+is wrong. Retrying variations of the same fix is the deterministic-failure trap above wearing a
+disguise.
+
+- **Attempts 1–2** — allowed, but each must test a *different, explicit* hypothesis, changing one
+  variable at a time. The same edit retried (or a near-duplicate) does not count as a new attempt.
+- **At the 3rd failed attempt — STOP.** Do not attempt a fourth blind fix. Switch modes: re-derive
+  the root cause from first principles (`.claude/skills/debugging-and-error-recovery/SKILL.md`), and
+  ask the harder question — is the *approach or architecture* wrong, not the line?
+- **Then escalate** (`.claude/rules/human-in-the-loop.md`) with what you tried, what each attempt
+  ruled out, and the hypothesis you cannot resolve — not just "it still fails."
+
+This bounds *blind fix attempts within a single issue*; the defect-loop **budget** in
+`.claude/rules/quality-gates.md` bounds how many times a finding may cycle review→fix across the
+pipeline. Different scopes, same principle: no loop is unbounded.
+
 ## Rules
 
 1. **Fail loud, never silent.** A swallowed error that lets work continue on bad state is worse than a

{claude_code_kit-0.33.0 → claude_code_kit-0.35.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.33.0 → claude_code_kit-0.35.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.33.0"
+__version__ = "0.35.0"

claude_code_kit-0.35.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.33.0 → claude_code_kit-0.35.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?