claude-code-kit 0.10.0__tar.gz → 0.11.0__tar.gz

{claude_code_kit-0.10.0 → claude_code_kit-0.11.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.10.0",
+      "version": "0.11.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.10.0 → claude_code_kit-0.11.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.10.0",
+  "version": "0.11.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.10.0 → claude_code_kit-0.11.0}/CHANGELOG.md

@@ -4,6 +4,42 @@ 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.11.0] — 2026-06-15
+
+Distils a field review of [repowise](https://github.com/repowise-dev/repowise) (a runtime
+codebase-intelligence engine: dependency graph, git analytics, LLM wiki, code-health biomarkers,
+change-risk, dead code). An adversarial map→verify pass over six candidates found that repowise is
+overwhelmingly a **runtime product** whose config-equivalents claude-kit already ships — so the
+honest, reuse-first result is small: one genuine kit-owned methodology gap and one sanctioned,
+opt-in external-tool reference. No application code, no Docker, nothing bundled.
+
+### Added
+- **`catalog/mcp.yaml`** gains an **opt-in** `repowise` MCP server (codebase intelligence: hotspots,
+  change-risk, co-change coupling, dead code). It is **only** written into `.mcp.json` when explicitly
+  selected at init — the kit *references* repowise, never bundles it. The label flags that it is
+  **AGPL-3.0** and requires installing it separately (`pip install repowise`) and indexing the repo
+  once (`repowise init`); the repo path is supplied via the `${REPOWISE_PROJECT_ROOT}` env placeholder
+  (same pattern as postgres's `${DATABASE_URL}`), so this is pure catalog data with no resolver change.
+
+### Changed
+- **`skills/code-review-and-quality`** gains a **"Where to Focus: Change Hotspots & Coupling"** section:
+  a tool-agnostic, `git log`-only technique for spending review attention where defects cluster —
+  churn × complexity hotspots, co-change coupling (hidden dependencies), and single-owner/bus-factor
+  files. It notes that a codebase-intelligence MCP (e.g. the optional repowise server) provides the
+  same signals precomputed via `get_risk`/`get_health`, but always as **advisory input, never a
+  blocking gate**. A matching checklist item was added.
+
+### Not done (deliberately, per the assessment)
+- repowise's engine itself — dependency graph, dashboard (`repowise serve`), deterministic PR bot,
+  LLM wiki/RAG, the 25 code-health biomarkers — is runtime and **cannot** be config. Its
+  config-equivalents already exist and were **not** duplicated: dead-code hygiene
+  (`over-engineering-review` / `code-simplification` / `code-review-and-quality` / `mandatory-workflow`),
+  noisy-output compression a.k.a. "distill" (`tool-design` rule + `context-engineering` skill),
+  read-an-overview-first (`context-engineering` / `source-driven-development`), ADRs
+  (`documentation-and-adrs`), commit provenance (`git-workflow-and-versioning`), and auto-generated
+  project instructions (`templates/CLAUDE.md`). No new rule/agent/skill/gate (the hotspot technique is
+  advisory, so it enriches a profile-gated skill rather than becoming a mandatory rule).
+
 ## [0.10.0] — 2026-06-15
 
 Adds **LLM / AI application-security** guidance distilled from a field review of

{claude_code_kit-0.10.0 → claude_code_kit-0.11.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.10.0
+Version: 0.11.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.10.0 → claude_code_kit-0.11.0}/catalog/mcp.yaml

@@ -52,3 +52,14 @@ servers:
     config:
       type: http
       url: "https://mcp.context7.com/mcp"
+  # Repowise (github.com/repowise-dev/repowise) — optional codebase-intelligence engine exposing an
+  # MCP server: deterministic hotspots (churn × complexity), change-risk, co-change coupling, dead
+  # code, and a dependency graph. NOT bundled (claude-kit only references it): it is AGPL-3.0, so
+  # install it separately (`pip install repowise`) and index the repo once (`repowise init`) before
+  # first use. Point it at the repo via the env var below (e.g. `export REPOWISE_PROJECT_ROOT=$(pwd)`).
+  repowise:
+    label: "Repowise codebase intelligence (AGPL-3.0; needs `pip install repowise` + `repowise init`)"
+    config:
+      type: stdio
+      command: repowise
+      args: ["mcp", "${REPOWISE_PROJECT_ROOT}", "--transport", "stdio"]

{claude_code_kit-0.10.0 → claude_code_kit-0.11.0}/pyproject.toml

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

@@ -80,6 +80,21 @@ For detailed profiling and optimization, see `performance-optimization`. Does th
 - Any missing pagination on list endpoints?
 - Any large objects created in hot paths?
 
+## Where to Focus: Change Hotspots & Coupling
+
+You can't give every line equal attention — on a large change or an unfamiliar codebase, spend the most scrutiny where defects actually cluster. The project's own git history surfaces this for free, no special tooling required:
+
+- **Hotspots (churn × complexity).** Files that change *often* **and** are *large/complex* carry the most risk. List the frequently-changed files and weight review toward the complex ones among them — a rarely-touched file is usually stable, while a hotspot edited in *this* change deserves extra correctness and test scrutiny.
+  ```bash
+  # Most-churned files over the last 6 months — pair the top hits with their size/complexity
+  git log --since="6 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20
+  ```
+  Use the project's own complexity tooling if it has one; file size is only a rough proxy for complexity.
+- **Co-change coupling (hidden dependencies).** Files historically committed together often share an implicit contract. If this change touches one side of a known pair but not the other, ask whether the coupled file also needs updating — `git log` on a changed file reveals what usually moves with it.
+- **Single-owner / bus-factor files.** Code with one dominant author has had fewer eyes. Treat changes there with extra care and prefer a second reviewer.
+
+These are deterministic signals an agent can derive from `git log` alone. If a codebase-intelligence MCP server is configured (e.g. the optional **repowise** server in the catalog), its `get_risk` / `get_health` tools surface the same hotspot, coupling, and change-risk signals precomputed — use them when available, but treat the output as **advisory input to your judgment, never a blocking gate**.
+
 ## Change Sizing
 
 Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes:
@@ -272,6 +287,7 @@ Part of code review is dependency review:
 
 ### Context
 - [ ] I understand what this change does and why
+- [ ] For a large/unfamiliar change, I focused review on the riskiest files (hotspots, coupled files)
 
 ### Correctness
 - [ ] Change matches spec/task requirements

{claude_code_kit-0.10.0 → claude_code_kit-0.11.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.10.0"
+__version__ = "0.11.0"