claude-code-kit 0.29.0__tar.gz → 0.31.0__tar.gz

{claude_code_kit-0.29.0 → claude_code_kit-0.31.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.29.0",
+      "version": "0.31.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.29.0",
+  "version": "0.31.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.29.0 → claude_code_kit-0.31.0}/CHANGELOG.md

@@ -4,6 +4,57 @@ 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.31.0] — 2026-06-24
+
+**Sharper skill auto-triggering.** Added explicit `Do NOT use when … → use [sibling]` boundary clauses to
+the `description:` frontmatter of the most overlapping **model-invocable** skills, so the model routes to
+the right skill instead of coin-flipping between siblings whose "Use when" clauses both match a request:
+
+- **`*-driven-development`** — `test-driven-development`, `spec-driven-development`,
+  `source-driven-development`, `doubt-driven-development` now cross-route (spec before code exists, source
+  for "which API is correct", TDD for the red-green loop, doubt as the review layer *on top* of the others).
+- **Security** — `security-and-hardening`, `threat-model`, `zap-vapt-scanning`,
+  `kubernetes-workload-hardening`, `edge-to-service-trust-boundary` now disambiguate code-hardening vs
+  upfront STRIDE vs live DAST scan vs k8s-manifest/pod hardening vs the gateway signed-header trust contract.
+- **Testing** — `testing-conventions` routes the red-green loop to `test-driven-development` and pre-write
+  plan critique to `test-plan-review`.
+
+Skills carrying `disable-model-invocation: true` (slash-only; they never auto-trigger) were intentionally
+left untouched. The clauses were adversarially verified for truthful routing, coverage, and the ~1024-char
+description ceiling. Skill-`description` text only — no agent, rule, hook, catalog, or pipeline behavior change.
+
+## [0.30.0] — 2026-06-24
+
+**The flagship example is now a *real, harness-captured* `/sdlc` run — closing the credibility gap that
+the prior flagship was synthetic. Plus a harness improvement found by running it. Docs/example +
+`capture-sdlc-run.sh` only; no payload or pipeline behavior change.**
+
+### Added
+- **`examples/real-run/`** — a genuine run, produced by the kit's own
+  [`scripts/capture-sdlc-run.sh`](scripts/capture-sdlc-run.sh) harness. A real `DELETE /tasks/{id}`
+  feature was driven through every standard-profile gate on a freshly-scaffolded **Go / net-http**
+  project; the folder holds the **verbatim harness bundle** (`captured-bundle/`: the spec, the
+  deterministic `pipeline-snapshot.json` with per-gate evidence, the `stack-catalog.snapshot.yaml`, the
+  `continuity.md` verdict log, the gate evidence, and the real `git/changes.diff`), the agent verdicts
+  the harness's gate model doesn't collect (`run-artifacts/`), the reproducible Go source
+  (`sample-app/`, 7 tests / 85.2% coverage), and a **genuine terminal recording** of the gate checks
+  (`cast/`: an asciicast `.cast` + static `.svg`, recorded via a stdlib `pty` recorder).
+- **The headline:** four reviewers returned a unanimous PASS; the `devils-advocate` (spawned *because*
+  of the unanimity) attacked the id-parsing seam over a raw socket and found + **reproduced** a real
+  **Medium** — `strconv.Atoi` aliased `01`/`+1`/`%2B1` onto task `1` and deleted it. The deterministic
+  pipeline then **refused to close the next gate** while the Medium was open; a fix + a mux-level
+  regression test closed it and the devil's advocate re-verified **UPHELD**.
+
+### Changed
+- **`scripts/capture-sdlc-run.sh` now produces a self-contained bundle** (improvement surfaced by
+  actually running it): it copies the gate-evidence files the snapshot references into the bundle's
+  `evidence/` and rewrites the snapshot's `gate_evidence` paths to bundle-relative, so a published
+  bundle resolves its own pointers and leaks no local absolute filesystem paths. Degrades gracefully
+  (with a note) when `python3` is absent.
+- **The README and `examples/` index now lead with the real captured run**; the
+  `react-fastapi-postgres-feature/` walkthrough is reframed as the explicitly *synthetic* map alongside
+  it, and `docs/capture-a-real-run.md` points at the shipped real bundle as a worked reference.
+
 ## [0.29.0] — 2026-06-24
 
 **Positioning v2 (docs): lead with the trust moat, promote the comparison to a top-level block, and

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.29.0
+Version: 0.31.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
@@ -377,8 +377,9 @@ need.
   [what we adopted](#influences--what-we-adopted)).
 - **Opt-in LLM/AI security** — `security-and-hardening` covers the OWASP LLM Top 10 (input/output
   guardrails, PII vault) as bypassable guidance, distinct from the mandatory appsec gate.
-- **A worked example + self-test matrix** — [`examples/`](examples/) shows an end-to-end run, and a
-  profile×stack×scope test matrix backs the stack-agnostic claim.
+- **A real captured run + self-test matrix** — [`examples/real-run/`](examples/real-run/) is a genuine
+  run captured by the `capture-sdlc-run.sh` harness, where the `devils-advocate` found and reproduced a
+  Medium bug a unanimous review missed; a profile×stack×scope test matrix backs the stack-agnostic claim.
 
 </details>
 
@@ -477,9 +478,13 @@ is inert for non-API projects. Organization scope at `regulated` strictness adds
 (WCAG-AA on changed UI). A **fast-track** mode collapses small changes (< 5 files) to Developer →
 Code Reviewer → Tester → PR.
 
-See [`examples/`](examples/) for a synthetic end-to-end walkthrough — request → spec → story breakdown
-→ gate verdicts (with one defect-loop cycle) → sample PR diff. To capture *your own* real run as a
-publishable, redaction-scrubbed bundle, see [`docs/capture-a-real-run.md`](docs/capture-a-real-run.md).
+See [`examples/real-run/`](examples/real-run/) for a **real**, harness-captured run — a `DELETE
+/tasks/{id}` feature driven through every gate on a Go/net-http project, where the `devils-advocate`
+caught and reproduced a Medium bug a unanimous review missed and the deterministic gate refused to
+advance until it was fixed (verbatim `pipeline-snapshot.json`, agent verdicts, diff, and an asciicast of
+the green checks). A [synthetic walkthrough](examples/react-fastapi-postgres-feature/) also maps the
+default-stack flow. To capture *your own* run as a publishable, redaction-scrubbed bundle, see
+[`docs/capture-a-real-run.md`](docs/capture-a-real-run.md).
 
 ---
 

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/README.md

@@ -347,8 +347,9 @@ need.
   [what we adopted](#influences--what-we-adopted)).
 - **Opt-in LLM/AI security** — `security-and-hardening` covers the OWASP LLM Top 10 (input/output
   guardrails, PII vault) as bypassable guidance, distinct from the mandatory appsec gate.
-- **A worked example + self-test matrix** — [`examples/`](examples/) shows an end-to-end run, and a
-  profile×stack×scope test matrix backs the stack-agnostic claim.
+- **A real captured run + self-test matrix** — [`examples/real-run/`](examples/real-run/) is a genuine
+  run captured by the `capture-sdlc-run.sh` harness, where the `devils-advocate` found and reproduced a
+  Medium bug a unanimous review missed; a profile×stack×scope test matrix backs the stack-agnostic claim.
 
 </details>
 
@@ -447,9 +448,13 @@ is inert for non-API projects. Organization scope at `regulated` strictness adds
 (WCAG-AA on changed UI). A **fast-track** mode collapses small changes (< 5 files) to Developer →
 Code Reviewer → Tester → PR.
 
-See [`examples/`](examples/) for a synthetic end-to-end walkthrough — request → spec → story breakdown
-→ gate verdicts (with one defect-loop cycle) → sample PR diff. To capture *your own* real run as a
-publishable, redaction-scrubbed bundle, see [`docs/capture-a-real-run.md`](docs/capture-a-real-run.md).
+See [`examples/real-run/`](examples/real-run/) for a **real**, harness-captured run — a `DELETE
+/tasks/{id}` feature driven through every gate on a Go/net-http project, where the `devils-advocate`
+caught and reproduced a Medium bug a unanimous review missed and the deterministic gate refused to
+advance until it was fixed (verbatim `pipeline-snapshot.json`, agent verdicts, diff, and an asciicast of
+the green checks). A [synthetic walkthrough](examples/react-fastapi-postgres-feature/) also maps the
+default-stack flow. To capture *your own* run as a publishable, redaction-scrubbed bundle, see
+[`docs/capture-a-real-run.md`](docs/capture-a-real-run.md).
 
 ---
 

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/docs/capture-a-real-run.md

@@ -1,9 +1,10 @@
 # Capture a real `/sdlc` run
 
-The repo ships a **synthetic** worked example under [`examples/`](../examples/) — useful, but
-hand-written. The most convincing evidence is *your own* run: a real request that flowed through the
-pipeline, with the real spec, real gate verdicts, and the real diff it produced. This guide turns one
-completed run into a publishable, redaction-scrubbed bundle.
+The repo ships a **real, harness-captured** run under [`examples/real-run/`](../examples/real-run/)
+(produced exactly the way this guide describes) alongside a hand-written **synthetic** walkthrough. The
+most convincing evidence, though, is *your own* run: a real request that flowed through the pipeline,
+with the real spec, real gate verdicts, and the real diff it produced. This guide turns one completed
+run into a publishable, redaction-scrubbed bundle.
 
 > **You run this — not the kit.** `/sdlc` is interactive (it runs inside Claude Code). The script here
 > only *collects and scrubs* what a finished run left behind; it never drives the pipeline and never

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.29.0"
+version = "0.31.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.29.0 → claude_code_kit-0.31.0}/scripts/capture-sdlc-run.sh

@@ -101,6 +101,59 @@ else
   printf '  [skip] docs/specs/ (not found)\n'; missing=$((missing + 1))
 fi
 
+# --- 1b. Evidence files the snapshot points at -------------------------------------------------
+# The pipeline snapshot records a `gate_evidence` map of absolute paths. Pull those artifacts into
+# the bundle and rewrite the snapshot to point at the copied, bundle-relative files — so the bundle
+# is self-contained and leaks no local filesystem paths. Needs python3 (json); skipped with a note
+# if it is absent, leaving the snapshot untouched.
+snap_copy="$OUT/state/pipeline-snapshot.json"
+if [ -f "$snap_copy" ]; then
+  if command -v python3 >/dev/null 2>&1; then
+    printf '\nCollecting gate-evidence referenced by the snapshot:\n'
+    CK_PROJECT="$PROJECT" CK_OUT="$OUT" CK_SNAP="$snap_copy" python3 - <<'PY' || printf '  [skip] could not process gate_evidence (snapshot left as-is)\n'
+import json, os, pathlib, shutil
+
+project = pathlib.Path(os.environ["CK_PROJECT"]).resolve()
+out = pathlib.Path(os.environ["CK_OUT"])
+snap = pathlib.Path(os.environ["CK_SNAP"])
+data = json.loads(snap.read_text())
+ev = data.get("gate_evidence")
+if not isinstance(ev, dict):
+    raise SystemExit(0)
+changed = False
+for gate, p in list(ev.items()):
+    if not isinstance(p, str):
+        continue
+    src = pathlib.Path(p)
+    if not src.is_file():
+        print(f"  [skip] {gate}: evidence not found ({p})")
+        continue
+    resolved = src.resolve()
+    try:
+        resolved.relative_to(project)
+    except ValueError:
+        print(f"  [skip] {gate}: evidence outside the project ({p})")
+        continue
+    # the spec already lives under specs/; point there instead of duplicating it.
+    if resolved.suffix == ".md" and "specs" in resolved.parts:
+        ev[gate] = f"specs/{resolved.name}"
+        changed = True
+        print(f"  [ok]   {gate} -> specs/{resolved.name}")
+        continue
+    (out / "evidence").mkdir(parents=True, exist_ok=True)
+    dest_name = f"{gate}{resolved.suffix or '.txt'}"
+    shutil.copyfile(resolved, out / "evidence" / dest_name)
+    ev[gate] = f"evidence/{dest_name}"
+    changed = True
+    print(f"  [ok]   {gate} -> evidence/{dest_name}")
+if changed:
+    snap.write_text(json.dumps(data, indent=2) + "\n")
+PY
+  else
+    printf '\n  [skip] python3 not found — snapshot keeps absolute gate_evidence paths\n'
+  fi
+fi
+
 # --- 2. The code the run produced (git) --------------------------------------------------------
 printf '\nCollecting git evidence (base = %s):\n' "$BASE"
 if git -C "$PROJECT" rev-parse --git-dir >/dev/null 2>&1; then

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/doubt-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: doubt-driven-development
-description: Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
+description: Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later. Do NOT use as the primary authoring loop — it is the adversarial review layer ON TOP of writing specs (spec-driven-development), implementing against tests (test-driven-development), or grounding choices in docs (source-driven-development).
 ---
 
 # Doubt-Driven Development

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/edge-to-service-trust-boundary/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: edge-to-service-trust-boundary
-description: The cryptographic trust contract between an API gateway / edge and the backend services behind it — edge HMAC-signs forwarded identity and tenant headers (signature + timestamp), downstream services verify with constant-time compare and FAIL CLOSED, reject replayed/skewed requests, detect conflicts when identity is resolvable from multiple sources, and still enforce their own authz. Use when building a service that sits behind a gateway/ingress that forwards identity, designing the edge signing step, verifying forwarded headers, hardening against header spoofing or direct-to-service bypass, or reviewing code for naked-header trust and verify_signature=False.
+description: The cryptographic trust contract between an API gateway / edge and the backend services behind it — edge HMAC-signs forwarded identity and tenant headers (signature + timestamp), downstream services verify with constant-time compare and FAIL CLOSED, reject replayed/skewed requests, detect conflicts when identity is resolvable from multiple sources, and still enforce their own authz. Use when building a service that sits behind a gateway/ingress that forwards identity, designing the edge signing step, verifying forwarded headers, hardening against header spoofing or direct-to-service bypass, or reviewing code for naked-header trust and verify_signature=False. Do NOT use for general application-code hardening (use security-and-hardening) or for building the downstream auth dependencies/RBAC that consume the verified identity (use auth-and-rbac).
 ---
 
 # Edge-to-Service Trust Boundary

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/kubernetes-workload-hardening/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kubernetes-workload-hardening
-description: Runtime and manifest-layer Kubernetes security — pod/container securityContext (runAsNonRoot, non-zero UID, allowPrivilegeEscalation=false, drop ALL capabilities, readOnlyRootFilesystem, seccomp RuntimeDefault), default-deny NetworkPolicy with explicit allows, digest-pinned images, resource requests/limits, restricted PodSecurity admission, least-privilege ServiceAccount/RBAC, and secrets via secretRef not baked in. Use when writing or reviewing Kubernetes Deployment/StatefulSet/DaemonSet manifests or Helm charts, adding securityContext, locking down pod networking, pinning images, or enforcing PodSecurity standards. This is the runtime layer — image-build hardening lives in the Dockerfile skills.
+description: Runtime and manifest-layer Kubernetes security — pod/container securityContext (runAsNonRoot, non-zero UID, allowPrivilegeEscalation=false, drop ALL capabilities, readOnlyRootFilesystem, seccomp RuntimeDefault), default-deny NetworkPolicy with explicit allows, digest-pinned images, resource requests/limits, restricted PodSecurity admission, least-privilege ServiceAccount/RBAC, and secrets via secretRef not baked in. Use when writing or reviewing Kubernetes Deployment/StatefulSet/DaemonSet manifests or Helm charts, adding securityContext, locking down pod networking, pinning images, or enforcing PodSecurity standards. This is the runtime layer — image-build hardening lives in the Dockerfile skills. Do NOT use to harden application code against injection/authn/data-handling vulnerabilities (use security-and-hardening) or to threat-model a feature before building (use threat-model).
 ---
 
 # Kubernetes Workload Hardening

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/security-and-hardening/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: security-and-hardening
-description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.
+description: Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Do NOT use for upfront STRIDE threat enumeration before building (use threat-model), for running an automated DAST/penetration scan against a live app (use zap-vapt-scanning), for hardening Kubernetes workload manifests or pod security (use kubernetes-workload-hardening), or for the specific edge/gateway signed-header trust contract (use edge-to-service-trust-boundary).
 ---
 
 # Security and Hardening

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/source-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: source-driven-development
-description: Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.
+description: Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters. Do NOT use to drive the red-green-refactor implementation loop itself (use test-driven-development) or to author requirements before any code exists (use spec-driven-development).
 ---
 
 # Source-Driven Development

{claude_code_kit-0.29.0 → claude_code_kit-0.31.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.
+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).
 ---
 
 # Spec-Driven Development

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/test-driven-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: test-driven-development
-description: Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
+description: Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality. Do NOT use when no specification exists yet (use spec-driven-development first), when the open question is which library/framework API is correct rather than how to verify behavior (use source-driven-development), or for the project's specific test fixtures/runner conventions once you are writing the tests (use testing-conventions).
 ---
 
 # Test-Driven Development

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/testing-conventions/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: testing-conventions
-description: Testing conventions from production Python/FastAPI and React services — pytest + pytest-asyncio, conftest.py fixtures (session event loop, async session, authenticated client, dependency overrides, cleanup), AsyncMock for Kafka/Temporal/HTTP, factory.Factory + factory.Faker patterns, Vitest + jsdom for frontend, security-regression tests (negative authz, cross-tenant/RLS isolation, IDOR, login lockout, signed-header trust), and honest coverage gaps. Use when writing or reviewing tests, setting up pytest infrastructure, implementing async test fixtures, mocking external dependencies, writing security-regression tests for access control and tenant isolation, establishing testing baselines for services with thin coverage, configuring Vitest for React/TypeScript, or auditing test quality.
+description: Testing conventions from production Python/FastAPI and React services — pytest + pytest-asyncio, conftest.py fixtures (session event loop, async session, authenticated client, dependency overrides, cleanup), AsyncMock for Kafka/Temporal/HTTP, factory.Factory + factory.Faker patterns, Vitest + jsdom for frontend, security-regression tests (negative authz, cross-tenant/RLS isolation, IDOR, login lockout, signed-header trust), and honest coverage gaps. Use when writing or reviewing tests, setting up pytest infrastructure, implementing async test fixtures, mocking external dependencies, writing security-regression tests for access control and tenant isolation, establishing testing baselines for services with thin coverage, configuring Vitest for React/TypeScript, or auditing test quality. Do NOT use to drive the red-green-refactor loop itself (use test-driven-development) or to critique a test plan before tests are written (use test-plan-review).
 ---
 
 # Testing Conventions

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/threat-model/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: threat-model
-description: Use when adding or changing a security-relevant feature (auth, sessions, payments, data access, file upload, external integrations, multi-tenant boundaries) and you need a structured threat model. Enumerates assets, entry points, and threats (STRIDE), rates them, and proposes mitigations + tests before implementation.
+description: Use when adding or changing a security-relevant feature (auth, sessions, payments, data access, file upload, external integrations, multi-tenant boundaries) and you need a structured threat model. Enumerates assets, entry points, and threats (STRIDE), rates them, and proposes mitigations + tests before implementation. Do NOT use to write or harden the secure code itself (use security-and-hardening) or to run a live vulnerability scan (use zap-vapt-scanning).
 ---
 
 # Threat Model

{claude_code_kit-0.29.0 → claude_code_kit-0.31.0}/skills/zap-vapt-scanning/SKILL.md

@@ -9,7 +9,8 @@ description: >
   location, logo, and sign-off names are supplied at run time (never hardcoded). Use when asked to
   run a ZAP scan, perform a VAPT or DAST pass on an API, security-test endpoints, generate a
   vulnerability/penetration-test report, scan a Postman collection for security issues, or automate
-  OWASP ZAP from the command line. Only for systems the user is authorized to test.
+  OWASP ZAP from the command line. Only for systems the user is authorized to test. Do NOT use for
+  source-code-driven, exploit-by-proof white-box pentesting (use shannon-ai-pentest).
 ---
 
 # OWASP ZAP VAPT Scanning & Reporting

{claude_code_kit-0.29.0 → claude_code_kit-0.31.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.29.0"
+__version__ = "0.31.0"