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

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

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

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

@@ -4,6 +4,37 @@ 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.32.0] — 2026-06-25
+
+**Two patterns adopted from Agent-Reach (MIT); no behavior change to existing commands.**
+
+- **`claude-kit init --dry-run`** — preview the resolved plan (stack / profile / scope / MCP / gates)
+  and the exact list of files a fresh install would write, **without touching the target project**.
+  Implemented by running the real installer into a throwaway sandbox and discarding it, so the preview
+  can never drift from a real install. Great for CI, onboarding, and evaluation.
+- **Root `llms.txt`** — a concise, machine-readable project guide (the llmstxt.org convention) so agents
+  and tools discovering the repo get install + key-command + concept pointers fast. Repo artifact only;
+  not shipped in the wheel/sdist or scaffolded into projects.
+
+## [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.32.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.30.0
+Version: 0.32.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.32.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.30.0"
+version = "0.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.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.32.0"

{claude_code_kit-0.30.0 → claude_code_kit-0.32.0}/src/claude_kit/cli.py

@@ -23,6 +23,7 @@ from claude_kit import (
     upgrader,
     validator,
 )
+from claude_kit.models import ResolvedPlan
 
 BANNER = r"""
   ___ _      _   _ ___  ___   _  _____ _____
@@ -79,6 +80,51 @@ def _print_report(ok: bool, messages: list[str]) -> None:
         raise typer.Exit(1)
 
 
+def _resolve_plan(src: Path, *, config: Optional[str], defaults: bool) -> ResolvedPlan:
+    """Resolve the user's selection (``--config`` / ``--defaults`` / interactive) into a plan."""
+    try:
+        if config is not None:
+            selection = prompts.from_config(config, src)
+        elif defaults:
+            selection = catalog.defaults(src)
+        else:
+            selection = prompts.interactive(src)
+        return catalog.resolve(src, selection)
+    except (ValueError, FileNotFoundError) as exc:
+        typer.echo(f"error: {exc}", err=True)
+        raise typer.Exit(2) from exc
+
+
+def _print_dry_run(src: Path, target: Path, plan: ResolvedPlan) -> None:
+    """Print the resolved plan + the exact files a fresh install would write. Touches nothing."""
+    sel = plan.selection
+    stack_str = (
+        f"{sel.frontend_framework}/{sel.frontend_language} + "
+        f"{sel.backend_language}/{sel.backend_framework} + {sel.database}"
+    )
+    _, paths = scaffold.preview_install(src, target, plan)
+    typer.echo(f"\nDRY RUN — previewing install into {target} (no files written)\n")
+    typer.echo(f"  profile : {sel.profile}    scope: {sel.scope}")
+    typer.echo(f"  stack   : {stack_str}")
+    typer.echo(f"  MCP     : {', '.join(sorted(plan.mcp_servers)) or 'none'}")
+    typer.echo(
+        f"  resolves to: {len(plan.agents)} agents · {len(plan.skills)} skills · "
+        f"{len(plan.overlay_rules)} overlay rules · {len(plan.hooks)} hooks · "
+        f"{len(plan.gates)} gates"
+    )
+    if plan.gates:
+        typer.echo(f"  gates   : {', '.join(plan.gates)}")
+    typer.echo(f"\nWould write {len(paths)} file(s):")
+    for p in paths:
+        typer.echo(f"  + {p}")
+    if (target / ".claude").exists():
+        typer.echo(
+            "\nNote: this project already has .claude/ — a real run would MERGE (preserving your "
+            "files) or need --force. Use `claude-kit diff` to preview an upgrade."
+        )
+    typer.echo("\nDRY RUN — nothing was written.")
+
+
 @app.command()
 def init(
     path: Optional[str] = typer.Argument(
@@ -95,6 +141,11 @@ def init(
         "--force",
         help="overwrite existing CLAUDE.md / settings.json / .mcp.json",
     ),
+    dry_run: bool = typer.Option(
+        False,
+        "--dry-run",
+        help="preview the resolved plan and the files that would be written; write nothing",
+    ),
 ) -> None:
     """Scaffold a Claude Code SDLC configuration into a project."""
     non_interactive = defaults or config is not None
@@ -107,6 +158,14 @@ def init(
         else:
             raw = path
         target = Path(raw).expanduser().resolve()
+
+        # --dry-run: resolve + preview only. Never create the target or write anything; skip the
+        # existing-.claude handling and the install spine entirely.
+        if dry_run:
+            plan = _resolve_plan(src, config=config, defaults=defaults)
+            _print_dry_run(src, target, plan)
+            return
+
         if not target.exists():
             if not non_interactive and not typer.confirm(
                 f"Create {target}?", default=True
@@ -145,17 +204,7 @@ def init(
                 typer.echo(f"  • backed up existing .claude/ -> .claude.bak-{n}")
 
         # 3) Resolve the selection.
-        try:
-            if config is not None:
-                selection = prompts.from_config(config, src)
-            elif defaults:
-                selection = catalog.defaults(src)
-            else:
-                selection = prompts.interactive(src)
-            plan = catalog.resolve(src, selection)
-        except (ValueError, FileNotFoundError) as exc:
-            typer.echo(f"error: {exc}", err=True)
-            raise typer.Exit(2) from exc
+        plan = _resolve_plan(src, config=config, defaults=defaults)
 
         # 4) Install. Merge mode reconciles non-destructively (preserving the user's own files);
         # fresh / overwrite / backup all go through the destructive install spine.

{claude_code_kit-0.30.0 → claude_code_kit-0.32.0}/src/claude_kit/scaffold.py

@@ -15,6 +15,7 @@ from __future__ import annotations
 import hashlib
 import json
 import shutil
+import tempfile
 from contextlib import ExitStack
 from importlib.resources import as_file, files
 from pathlib import Path
@@ -566,3 +567,36 @@ def install_sdlc(
     _update_gitignore(target, log)
     _write_config(src, target, plan, log)
     return log
+
+
+def preview_install(
+    src: Path, target: Path, plan: ResolvedPlan
+) -> tuple[list[str], list[str]]:
+    """Compute what :func:`install_sdlc` would write, without touching ``target``.
+
+    Runs the real installer into a throwaway temporary directory (``force=True`` so it always writes
+    the full fresh-install set), captures its per-component log, and walks the temp tree to list the
+    files that would be created. The temp dir is discarded before returning, so the caller's project
+    is never modified. Reusing the real installer keeps the preview from ever drifting from actual
+    install behavior — there is no second code path to keep in sync.
+
+    Args:
+        src: Payload root (same as :func:`install_sdlc`).
+        target: The project that *would* be installed into — used only to label the render context
+            (project name); it is never read or written.
+        plan: The resolved install plan.
+
+    Returns:
+        ``(log_lines, would_write_paths)`` — the installer's per-component log, and the sorted list of
+        file paths (relative to the project root) that a fresh install would create.
+    """
+    # Pin the project name to the real target so the previewed context matches a real install
+    # (install_sdlc uses setdefault, so this wins over the sandbox dir name).
+    plan.context.setdefault("project_name", target.name)
+    with tempfile.TemporaryDirectory(prefix="claude-kit-dryrun-") as tmp:
+        sandbox = Path(tmp)
+        log = install_sdlc(src, sandbox, plan, force=True)
+        paths = sorted(
+            str(p.relative_to(sandbox)) for p in sandbox.rglob("*") if p.is_file()
+        )
+    return log, paths