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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.37.0",
+  "version": "0.39.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.39.0}/CHANGELOG.md

@@ -4,6 +4,46 @@ 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.39.0] — 2026-06-26
+
+**Supply-chain defense** (first of four adoptions from the MIT [`athola/claude-night-market`](https://github.com/athola/claude-night-market);
+re-derived stack-agnostic, nothing vendored). Closes the pre-install gap between "should we add a dep"
+(§2a.5 / `library-review`) and "are our installed deps vulnerable" (`dependency-scanner`).
+
+- **`skills/dependency-verification/`** (new core skill) — pre-install verification that a package
+  **name** actually exists in its registry (PyPI/npm/crates.io/…) and isn't a typosquat/slopsquat,
+  before any install command or manifest edit. Defends against LLM-hallucinated package names
+  (~5–22% of model-suggested packages don't exist; the recurring names get pre-registered with
+  malware). Three states — exists / nonexistent / unverified — and **never fails closed on a network
+  error**. Cross-linked into the supply-chain layer chain (§2a.5 → library-review → this → install →
+  dependency-scanner).
+- **`agents/dependency-scanner.md`** gains a **Supply-Chain Integrity mode** (post-resolve):
+  lockfile/hash integrity, artifact + lifecycle-script scanning, known-bad-versions cross-check, and
+  provenance signals — beyond the existing CVE audit.
+- **`skills/security-and-hardening`** + **`skills/library-review`** updated to point at the new layers.
+- Counts: **98 → 99** total skills (**52 → 53** core; stack-collection unchanged at 46).
+
+## [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.39.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.37.0
+Version: 0.39.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) + **99** context-activated skills (53 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
+- **99 on-demand skills** in [`skills/`](skills/) (53 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, 99 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.39.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) + **99** context-activated skills (53 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
+- **99 on-demand skills** in [`skills/`](skills/) (53 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, 99 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.39.0}/agents/dependency-scanner.md

@@ -83,6 +83,29 @@ Backend deps: {N} · Frontend deps: {N} · Vulns: Critical {N} / High {N} / Medi
 
 Return counts by severity + the finding table to `security-reviewer`. If a CVE has no patch, recommend a workaround or replacement and mark it for an allowlist-with-review-date decision (route to the human via the Orchestrator). Log durable findings to `.claude/CONTINUITY.md`.
 
+## SUPPLY-CHAIN INTEGRITY MODE (beyond CVEs)
+
+CVE scanning catches *known-vulnerable* versions; it does not catch a *compromised* or *impersonated*
+package. When auditing for a supply-chain advisory, during incident response, or before a release, add
+these checks (still report-only — never modify lockfiles):
+
+- **Lockfile / hash integrity.** Confirm the lockfile pins integrity hashes and that resolved
+  artifacts match them (`pip`'s `--require-hashes`, `npm ci` against `package-lock.json`,
+  `cargo`'s `Cargo.lock`, `go.sum`). Flag lockfile drift (manifest and lockfile disagree) and any
+  dependency resolved from an unexpected source/registry.
+- **Artifact scan.** Inspect what an install would actually run: post-install/lifecycle scripts
+  (`package.json` `postinstall`, `pyproject`/`setup.py` build hooks), and suspicious payload files
+  (e.g. `.pth` files that execute on interpreter start, obfuscated blobs). Report; don't execute.
+- **Known-bad versions.** Cross-check resolved versions against a known-bad/compromised-version list
+  for the project's ecosystem (maintain the project's own list and the public advisory feeds). A
+  matched version is an **auto-Critical** finding.
+- **Provenance signals.** Prefer packages with signed releases / 2FA-published maintainers; flag a
+  dependency that recently changed maintainer or publishing key.
+
+This is the **post-resolve** half of the kit's supply-chain story; the **pre-install** half (verifying
+a package *name* exists and isn't a typosquat/slopsquat, before it ever enters a lockfile) is the
+`.claude/skills/dependency-verification` skill. Cite it; don't restate it.
+
 ## CADENCE MODE (whole-project maintenance pass)
 
 The same audit can be dispatched **standalone** — outside any one feature — as a recurring

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

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.37.0"
+version = "0.39.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.39.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.39.0/skills/dependency-verification/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: dependency-verification
+description: Pre-install verification that a package NAME actually exists in its registry (PyPI/npm/crates.io/…) and is not a typosquat/slopsquat, before you run an install command or write it into a manifest. Defends against LLM-hallucinated package names — a measured 5–22% of model-suggested packages do not exist, and attackers pre-register the names that recur. Use before adding, installing, or recommending any dependency. Do NOT use to judge whether a real package is worth adopting (use library-review) or to audit ALREADY-installed dependencies for known CVEs (use the dependency-scanner agent) — this is the narrower "does this name even exist" check that runs first.
+---
+
+# Dependency Verification (pre-install name check)
+
+> A package name the model produced is a **claim**, not a fact. The registry is the fact. Verify
+> before you install. Adapted (stack-agnostic) from the MIT-licensed
+> [`athola/claude-night-market`](https://github.com/athola/claude-night-market) `dependency-verification` skill.
+
+## Why this exists
+
+Code-generating models recommend packages that **do not exist** at a measured rate of ~5% (commercial
+models) to ~22% (open models), and ~58% of the hallucinated names *recur* across reruns — so an
+attacker can predict a commonly-hallucinated name, register the empty slot, and ship malware. This is
+**"slopsquatting"** (the LLM-era cousin of typosquatting). A proof-of-concept package registered
+against a frequently-hallucinated name drew tens of thousands of installs. The rate does *not* fall to
+zero with a better model. The defense is cheap: **confirm the name exists in its registry before you
+install or recommend it.**
+
+## When to use
+
+Before any of:
+- running an install command — `pip install`, `uv add`, `npm install`, `pnpm add`, `yarn add`,
+  `cargo add`, `go get`, `poetry add`, `gem install`, `composer require`, …
+- writing a dependency into a manifest — `pyproject.toml`, `requirements.txt`, `package.json`,
+  `Cargo.toml`, `go.mod`, `Gemfile`, …
+- **recommending a package to the user in prose** (a hallucinated recommendation is still a defect).
+
+## The two failure signals
+
+A candidate fails verification on **either**:
+
+1. **Nonexistent** — the name is absent from its registry (e.g. HTTP 404). Likely a hallucination.
+   Do not install; find the correct name, or confirm the package was renamed/removed.
+2. **Typosquat / slopsquat** — the name is one or two edits from a popular package (`reqeusts` vs
+   `requests`, `python-dateutil` vs a look-alike). Either a typo or deliberate impersonation —
+   restate the exact name you intend and confirm before proceeding.
+
+## Three states (never fail closed on a network error)
+
+| State | Registry result | Action |
+|-------|-----------------|--------|
+| **exists** | 200 / found | pass |
+| **nonexistent** | 404 / not found | block — likely hallucination |
+| **unverified** | timeout / rate-limit / offline / non-404 error | **warn only, never block** — don't fail closed on a network problem |
+
+## Verification procedure
+
+1. Extract the exact names the command or manifest edit would fetch (strip version specifiers/flags).
+2. Confirm existence in the ecosystem's registry. A common, well-known package needn't be checked;
+   verify anything unfamiliar, freshly-suggested, or near a popular name.
+3. For any name close to a popular package, restate the intended name and confirm.
+4. Capture the check as evidence (registry URL + HTTP status) when the install lands in a PR.
+
+### Registry existence endpoints
+
+| Ecosystem | URL (`{name}` = package) | Exists / Absent |
+|-----------|--------------------------|------------------|
+| PyPI | `https://pypi.org/pypi/{name}/json` | 200 / 404 |
+| npm | `https://registry.npmjs.org/{name}` | 200 / 404 |
+| crates.io | `https://crates.io/api/v1/crates/{name}` | 200 / 404 |
+| other | the ecosystem's registry/index API | found / not-found |
+
+```bash
+# Prints the HTTP status: 200 = exists, 404 = does not. (PyPI shown; swap the URL per ecosystem.)
+curl -s -o /dev/null -w '%{http_code}\n' "https://pypi.org/pypi/requests/json"
+```
+
+## A confidence signal, not a second gate
+
+Once a name clears the two signals, real-world usage is a *softer* signal that the name is the
+established one, not a freshly-registered impostor: GitHub dependents / code-search hits for the exact
+name, repo stars + recent activity, download history (a popular-sounding name registered yesterday is
+a red flag; a modest name with years of releases is reassuring). **Low usage never blocks on its own**
+— new, niche, internal, and private packages are legitimately low-usage. Use it to build confidence
+and disambiguate two similar names, then hand a *real* candidate to `library-review` for the full
+adopt/reject evaluation.
+
+## Where this sits (the supply-chain layers)
+
+```
+need a dep at all?      → mandatory-workflow.md §2a.5 (Reuse & YAGNI gate)
+which dep, is it healthy?→ library-review skill (adopt/reject evaluation)
+does this NAME exist?    → THIS skill (pre-install: hallucination/typosquat)   ◄── you are here
+            install
+installed deps: CVEs?    → dependency-scanner agent (post-install CVE/outdated audit)
+lockfile/artifact integrity? → dependency-scanner agent (supply-chain integrity mode)
+```
+
+**Optional enforcement:** a `PreToolUse` hook on install commands can run this check automatically
+(warn-by-default; block on nonexistent/typosquat when configured). The hook is a backstop — verify
+deliberately when you add a dependency rather than waiting for the gate.
+
+## Exit criteria
+
+- [ ] Every package in the install command / manifest edit is confirmed present in its registry, or the install is abandoned
+- [ ] Any name within ~2 edits of a popular package is restated and confirmed before install
+- [ ] A name that couldn't be verified online is reported as *unverified* and not silently installed
+- [ ] For PR-bound installs, the registry check is captured as evidence

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

@@ -0,0 +1,105 @@
+---
+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-verification` — the *pre-install* name check (does this package name even exist / is it a typosquat) that runs before this evaluation
+- `dependency-scanner` agent — audits *already-installed* deps for CVEs + lockfile/artifact integrity (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.39.0}/skills/security-and-hardening/SKILL.md

@@ -322,6 +322,12 @@ def validate_upload(content_type: str, size: int) -> None:
 
 ## Triaging Dependency Audit Results
 
+> **Supply-chain layers.** A CVE audit catches *known-vulnerable* versions — it does not catch a
+> *hallucinated*, *typosquatted*, or *compromised* package. Pair it with the `dependency-verification`
+> skill (pre-install: confirm the package name exists and isn't a typosquat/slopsquat) and the
+> `dependency-scanner` agent's supply-chain integrity mode (post-resolve: lockfile-hash + artifact
+> scanning + known-bad versions). Pre-install name check → install → CVE + integrity audit.
+
 Not every finding is an emergency. Decision tree:
 
 ```

{claude_code_kit-0.37.0 → claude_code_kit-0.39.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.39.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.39.0"