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

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

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

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.38.0",
+  "version": "0.40.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.38.0 → claude_code_kit-0.40.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.40.0] — 2026-06-26
+
+**Review grounding + addition scrutiny** (PR 2 of 4 from the MIT `athola/claude-night-market` audit;
+re-derived stack-agnostic, count-neutral — both are edits to existing skills).
+
+- **`skills/code-review-and-quality`** — Step 4 now requires every finding to be **grounded**: a
+  `file:line` Location + a verbatim Anchor snippet, re-verified before reporting; a finding whose
+  location/anchor doesn't resolve is dropped or labelled `UNVERIFIED`. Stops AI reviewers from
+  hallucinating locations/issues; the review-level form of the §2.5 evidence rule in `quality-gates.md`.
+- **`skills/over-engineering-review`** — new **Burden-of-Proof Scrutiny** section that inverts the
+  default for *additions* in diff mode: 5 scrutiny questions (priority/criticality/simplicity/evidence/
+  consequence), 6 AI-additive anti-patterns (wheel reinvention, hallucinated issue, test manipulation,
+  complexity creep, priority deviation, gold plating), a justified/needs-evidence/unjustified verdict,
+  and the subtractive question. Collapses the upstream additive-bias-defense + justify + bloat-detector
+  ideas into the kit's existing complexity-review skill.
+
+## [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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.38.0
+Version: 0.40.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) + **98** context-activated skills (52 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)).
-- **98 on-demand skills** in [`skills/`](skills/) (52 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, 98 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.38.0 → claude_code_kit-0.40.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) + **98** context-activated skills (52 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)).
-- **98 on-demand skills** in [`skills/`](skills/) (52 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, 98 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.38.0 → claude_code_kit-0.40.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.38.0 → claude_code_kit-0.40.0}/pyproject.toml

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

@@ -181,6 +181,23 @@ Label every comment with its severity so the author knows what's required vs opt
 
 This prevents authors from treating all feedback as mandatory and wasting time on optional suggestions.
 
+#### Every finding must be grounded
+
+A review finding is a **claim about a specific place in the code**, so it must be falsifiable — a
+citation a second pass (human or agent) can mechanically re-read and confirm. AI reviewers in
+particular hallucinate locations and issues; grounding is what stops that.
+
+Every finding carries:
+
+- **Location** — `file:line` (a concrete, current line, not "somewhere in the auth module").
+- **Anchor** — a short *verbatim* snippet copied from that line, so the citation can be re-verified by
+  matching text even if line numbers shift.
+
+Verify before reporting: re-read each cited `file:line` and confirm the anchor text is actually
+present. A finding whose location or anchor doesn't resolve is **dropped or labelled `UNVERIFIED`** —
+it never enters the verdict. This is the review-level form of the evidence rule in
+`.claude/rules/quality-gates.md` (§2.5): an uncited finding is a TODO, not a finding.
+
 ### Step 5: Verify the Verification
 
 Check the author's verification story:

claude_code_kit-0.40.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.38.0 → claude_code_kit-0.40.0}/skills/library-review/SKILL.md

@@ -99,6 +99,7 @@ worth recording too, so the question isn't re-litigated.
 
 - `.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)
+- `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.38.0 → claude_code_kit-0.40.0}/skills/over-engineering-review/SKILL.md

@@ -55,6 +55,37 @@ Dependencies the stdlib or platform already ships · single-implementation inter
 one product · wrappers that only delegate · modules exporting one thing · dead flags and config ·
 hand-rolled stdlib · speculative "for later" scaffolding.
 
+## Burden of proof — scrutinize each addition
+
+The five tags catch complexity that already exists. In **diff mode**, also invert the burden of proof
+on what the change *adds* — LLM-written code is additive by default (it reinvents wheels, gilds error
+handling, and abstracts for a single caller). **The default answer to "should we add this?" is no;
+the addition must earn its place.** For each added file / function / abstraction / config / dependency,
+ask:
+
+1. **Priority** — does this serve the current task/spec, or is it a detour?
+2. **Criticality** — is it needed *now*, or speculative "for later"?
+3. **Simplicity** — does a simpler or subtractive solution exist?
+4. **Evidence** — what proves it's needed (a failing test, a real requirement) rather than assumed?
+5. **Consequence** — what concretely breaks if it's omitted?
+
+If 4 and 5 can't be answered with evidence, the addition is unjustified. Watch for these **AI-additive
+anti-patterns**:
+
+| Anti-pattern | Signal | Challenge |
+|---|---|---|
+| Wheel reinvention | New helper overlapping existing code/stdlib | "Does X already do this?" |
+| Hallucinated issue | A fix for a bug with no reproduction | "Show the failing test before the fix." |
+| Test manipulation | Test changed to match new behavior, not the spec | "Did the spec change, or did you change the test?" |
+| Complexity creep | Abstraction for a single use case | "Is this the 3rd use, or the 1st?" |
+| Priority deviation | Work not traceable to the task/spec | "Which requirement does this serve?" |
+| Gold plating | Error handling / flexibility beyond need | "What breaks without this?" |
+
+Give each scrutinized addition a one-word verdict — **justified** (evidence supports it → keep),
+**needs-evidence** (plausible but unproven → prove or cut), **unjustified** (no evidence, likely
+additive bias → cut) — and fold the cuts into the delete-list below. Before accepting any addition,
+ask the subtractive question: *could this be achieved by removing code instead of adding it?*
+
 ## Output format
 
 One line per finding. Diff mode:

{claude_code_kit-0.38.0 → claude_code_kit-0.40.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.38.0 → claude_code_kit-0.40.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.38.0"
+__version__ = "0.40.0"