claude-code-kit 0.37.0__tar.gz → 0.38.0__tar.gz

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

{claude_code_kit-0.37.0 → claude_code_kit-0.38.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.37.0",
+  "version": "0.38.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.37.0 → claude_code_kit-0.38.0}/CHANGELOG.md

@@ -4,6 +4,27 @@ 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.38.0] — 2026-06-26
+
+**New `library-review` core skill + a property-based-testing note** (two genuinely-new ideas
+cherry-picked, stack-agnostic, from the MIT [`wdm0006/python-skills`](https://github.com/wdm0006/python-skills);
+the rest of that collection was skipped as redundant with existing core/collection skills).
+
+- **`skills/library-review/`** (core — SKILL.md only, stack-agnostic) — a structured **pre-add
+  dependency-adoption evaluation**: need & fit, alternatives (stdlib/native/existing dep),
+  maintenance & bus factor, license compatibility, security/supply-chain history, transitive weight,
+  lock-in/exit cost, and a documented adopt/reject decision. Re-cast (health-signal dimensions
+  adapted from the MIT upstream's `reviewing-python-libraries`) as an *adoption* gate. Reuse-first:
+  cross-linked to and explicitly bounded against `mandatory-workflow.md` §2a.5 (whether a dep is
+  needed at all), `over-engineering-review`, the `dependency-scanner` agent (audits *installed* deps —
+  this is its pre-add counterpart), and `code-review-and-quality` (whose 5-point Dependency
+  Discipline list now points here as its full form).
+- **`test-driven-development`** gains a **Property-Based Testing** section (count-neutral edit):
+  what it is, when to reach for it, the round-trip/idempotence/invariant/metamorphic property shapes,
+  and one-per-language ecosystem pointers (Hypothesis · fast-check · jqwik · proptest · …).
+- Counts: **97 → 98** total skills (**51 → 52** core; stack-collection unchanged at 46). No
+  `docs/stack-skills` row (core skills aren't listed there). Version bumped across the 5 parity files.
+
 ## [0.37.0] — 2026-06-26
 
 **New `temporal-developer` collection skill — Temporal *fundamentals*, language-agnostic** (re-derived

{claude_code_kit-0.37.0 → claude_code_kit-0.38.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.37.0
+Version: 0.38.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
@@ -84,7 +84,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **97** context-activated skills (51 core + 46 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **98** context-activated skills (52 core + 46 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -281,7 +281,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **97 on-demand skills** in [`skills/`](skills/) (51 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **98 on-demand skills** in [`skills/`](skills/) (52 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -437,7 +437,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. No daemon, no lock-in, no app code. |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 97 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 98 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.37.0 → claude_code_kit-0.38.0}/README.md

@@ -54,7 +54,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **97** context-activated skills (51 core + 46 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **98** context-activated skills (52 core + 46 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -251,7 +251,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **97 on-demand skills** in [`skills/`](skills/) (51 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **98 on-demand skills** in [`skills/`](skills/) (52 core + 46 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -407,7 +407,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. No daemon, no lock-in, no app code. |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 97 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 98 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.37.0 → claude_code_kit-0.38.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.37.0"
+version = "0.38.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.37.0 → claude_code_kit-0.38.0}/skills/code-review-and-quality/SKILL.md

@@ -280,6 +280,8 @@ Part of code review is dependency review:
 
 **Rule:** Prefer standard library and existing utilities over new dependencies. Every dependency is a liability.
 
+For a full pre-add evaluation of a specific candidate (maintenance/bus-factor, license, supply-chain history, transitive weight, lock-in, adopt/reject decision), use the `library-review` skill — this 5-point list is its quick form.
+
 ## The Review Checklist
 
 ```markdown

claude_code_kit-0.38.0/skills/library-review/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: library-review
+description: Structured pre-add evaluation of a candidate third-party dependency before you adopt it—need & fit, alternatives (stdlib/native/existing dep), maintenance & bus factor, adoption signals, license compatibility, security & supply-chain history, install weight & transitive deps, lock-in/exit cost, and a documented adopt/reject decision. Stack-agnostic (pip, npm, cargo, go modules, maven, gems, …). Use when proposing or choosing between new libraries, or when mandatory-workflow §2a.5 rung 5 ("can an existing dependency do it?") points at pulling in a new one. Do NOT use to decide whether you need a dependency at all (use the §2a.5 reuse/YAGNI gate + over-engineering-review) or to audit ALREADY-installed dependencies for CVEs (use the dependency-scanner agent).
+---
+
+# Library Review (pre-add dependency evaluation)
+
+> Health-signal dimensions adapted (stack-agnostic, re-cast as an *adoption* decision) from the
+> MIT-licensed [`wdm0006/python-skills`](https://github.com/wdm0006/python-skills)
+> `reviewing-python-libraries` skill (© Will McGinnis). That skill audits a library's *own* quality
+> for publishing; this one turns the same signals into a **"should we take on this dependency?"** gate.
+
+## What this is (and is not)
+
+Adding a dependency is a long-lived liability: it ships its bugs, its CVEs, its license, its
+maintainer's availability, and its transitive tree into your project, and removing it later is rarely
+free. This skill is the **structured evaluation you run before adopting a specific candidate** — or
+when choosing between two or three.
+
+It is deliberately scoped, and it composes with three things already in the kit — use those first /
+alongside, don't duplicate them:
+
+- **Do we even need a new dependency?** That is the **§2a.5 Reuse & YAGNI Gate**
+  (`.claude/rules/mandatory-workflow.md`) and the `over-engineering-review` skill — walk the ladder
+  (need it at all? → in the codebase? → stdlib? → native platform? → an *existing* dependency?) and
+  only reach this skill once a *new* dependency is genuinely on the table.
+- **Auditing dependencies you have ALREADY installed** for known CVEs / outdated versions is the
+  `dependency-scanner` agent. This skill is its **pre-add counterpart** — it runs *before* the
+  dependency is in the lockfile.
+- The 5-point "Before adding any dependency" list in `code-review-and-quality` is the quick form;
+  this skill is its full expansion.
+
+## When to use
+
+- A new third-party dependency is being proposed (by you or in review)
+- Choosing between 2–3 candidate libraries for the same need
+- §2a.5 rung 5 surfaced a *new* dependency as the cheapest option
+- A dependency upgrade crosses a major version, changes its license, or changes maintainership
+
+**When NOT to use:** deciding *whether* you need a dependency (→ §2a.5 / `over-engineering-review`);
+scanning installed deps for CVEs (→ `dependency-scanner`); reviewing your *own* code (→
+`code-review-and-quality`).
+
+## Evaluation dimensions
+
+Score each; a single hard failure (incompatible license, unpatched critical CVE, abandoned) is
+disqualifying regardless of the rest.
+
+| Dimension | What to check | Disqualifier |
+|-----------|---------------|--------------|
+| **Need & fit** | Does it solve the *actual* problem, not a superset? How much of its API will you really use? | You'd use 5% of a large lib for one function |
+| **Alternatives** | stdlib / native platform feature / an already-installed dep / ~20 lines of your own | A cheaper rung of §2a.5 satisfies it |
+| **Maintenance & bus factor** | Recent commits, release cadence, issue/PR responsiveness, number of active maintainers, is it archived/deprecated? | Abandoned (no commits ~1yr), sole unresponsive maintainer, archived |
+| **Adoption & trust** | Real-world usage; downloads/dependents as *weak* signals (not popularity contests); who else relies on it | Effectively unused / no track record for critical use |
+| **License** | Compatible with *your* project's license and distribution model. Copyleft (GPL/AGPL) vs permissive (MIT/BSD/Apache); transitive licenses too. A copyleft dep in a permissive project may mean *document, don't vendor* | Incompatible / missing license |
+| **Security & supply chain** | CVE/advisory history *and how fast they're patched*; signed/2FA'd releases; typosquat/name-confusion check; provenance | Unpatched critical CVE; suspicious provenance |
+| **Weight & transitive deps** | Install/bundle/binary size; count and quality of transitive deps (each is its own liability); platform/runtime support | Huge transitive blast radius for a small need |
+| **API fit & lock-in** | Idiomatic for your stack? Type stubs/typings? How deeply would it thread through your code — i.e. exit cost? | Pervasive lock-in with no seam to swap it |
+| **Operational fit** | Compatible version range with your runtime/other deps; maintenance burden of pinning/upgrading | Conflicts with existing pinned deps |
+
+## Red flags 🚩 / Green flags ✅
+
+**🚩** No tests · no license · last release long ago · single unresponsive maintainer · exact-pins
+everything (fragile) · heavy transitive tree for a tiny need · unpatched advisories · you'd vendor
+just one helper from it.
+
+**✅** Active, regular releases · clear changelog + semver · permissive compatible license · security
+scanning / signed releases · small focused surface · typings available · several reputable dependents.
+
+## The decision
+
+Conclude explicitly — never let a dependency slip in undecided:
+
+1. **Adopt** — passes every dimension; pin sensibly and move on.
+2. **Adopt behind a seam** — acceptable but with real lock-in/risk → wrap it behind a thin interface
+   so it can be swapped, and note the exit path.
+3. **Reject** — a disqualifier fires, or a cheaper §2a.5 rung wins → record what you'll do instead.
+
+**Adding a dependency needs user approval** (per §2a.5 rung 5 / mandatory-workflow 2a). Record the
+decision and its rationale where future readers will find it — an ADR via `documentation-and-adrs`
+for a consequential one, or at minimum a line in the PR / change proposal. A rejected candidate is
+worth recording too, so the question isn't re-litigated.
+
+## Quick checklist
+
+```
+- [ ] §2a.5 walked first — a new dependency is genuinely the cheapest rung
+- [ ] Need & fit: solves the real problem; we use a meaningful share of it
+- [ ] No cheaper alternative (stdlib / native / existing dep / a few lines)
+- [ ] Actively maintained; bus factor > 1; not archived/deprecated
+- [ ] License compatible with the project (incl. transitive)
+- [ ] No unpatched critical/high CVEs; releases are patched promptly
+- [ ] Transitive-dep weight acceptable for the value gained
+- [ ] Lock-in understood; seam added if exit cost is high
+- [ ] User approval obtained; decision + rationale recorded
+```
+
+## Related
+
+- `.claude/rules/mandatory-workflow.md` (§2a.5 Reuse & YAGNI Gate) — the gate that decides *whether* a dep is needed
+- `over-engineering-review` — reactive twin of §2a.5; stdlib/native/yagni lenses
+- `dependency-scanner` agent — audits *already-installed* deps for CVEs (this skill's post-add counterpart)
+- `code-review-and-quality` (Dependency Discipline) — the quick 5-point form of this evaluation
+- `documentation-and-adrs` — record a consequential adopt/reject as an ADR

{claude_code_kit-0.37.0 → claude_code_kit-0.38.0}/skills/test-driven-development/SKILL.md

@@ -171,6 +171,35 @@ Is it a critical user flow that must work end-to-end?
   → E2E test (large) — limit these to critical paths
 ```
 
+## Property-Based Testing
+
+Example-based tests (everything above) check the cases *you* thought of. **Property-based testing**
+checks a *property* that must hold for **all** inputs, by generating hundreds of randomized cases —
+including the boundary and adversarial inputs you'd never enumerate by hand — and shrinking any
+failure to a minimal reproducer. It complements, never replaces, example-based TDD: keep your
+hand-written cases as living documentation, and add properties where the input space is large and a
+general invariant exists.
+
+**Reach for it when** the input space is wide (parsers, serializers, numeric/data transforms,
+collection logic, state machines) and you can state a rule that should *always* be true.
+
+Common property shapes:
+
+| Property | The invariant | Example |
+|----------|---------------|---------|
+| **Round-trip** | `decode(encode(x)) == x` | serialize→deserialize, parse→format, compress→decompress |
+| **Idempotence** | `f(f(x)) == f(x)` | normalize, dedupe, sort, saturating clamp |
+| **Invariant / oracle** | a cheaper or known-correct implementation agrees | optimized vs naive; sorted output is a permutation of input and ordered |
+| **Metamorphic** | a transformed input changes the output predictably | `sort(reverse(xs)) == sort(xs)`; adding an item grows the count by one |
+
+The point isn't more assertions — it's letting the generator *find the input that breaks your
+mental model*. When it shrinks to a tiny failing case, that case becomes a permanent example-based
+regression test (the Prove-It Pattern).
+
+Ecosystem (one per language; the project's own runner/conventions live in `testing-conventions`):
+**Python** → Hypothesis · **JS/TS** → fast-check · **Java/Kotlin** → jqwik · **Rust** → proptest ·
+**Go** → built-in `testing/quick` or rapid · **Haskell/Scala** → QuickCheck/ScalaCheck.
+
 ## Writing Good Tests
 
 ### Test State, Not Interactions

{claude_code_kit-0.37.0 → claude_code_kit-0.38.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.37.0"
+__version__ = "0.38.0"