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

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

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

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

@@ -4,6 +4,25 @@ 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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.30.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

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

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.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.30.0"
+__version__ = "0.31.0"