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

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

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

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

@@ -4,6 +4,94 @@ 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.1] — 2026-06-15
+
+A field review of **seven** external projects, each run through the same adversarial map→verify pass
+(read the source *and* the actual kit files; adopt only genuine, non-duplicative, config-only,
+stack-agnostic, IP-safe gaps). The result is deliberately tiny: across all seven, exactly **one** real
+gap survived — everything else is already covered, runtime-only, stack-specific, out of SDLC scope, or
+IP-unsafe to copy. Reviewed: [obra/superpowers](https://github.com/obra/superpowers),
+[wshobson/agents](https://github.com/wshobson/agents),
+[anthropics/skills](https://github.com/anthropics/skills),
+[karpathy/autoresearch](https://github.com/karpathy/autoresearch),
+[browser-use](https://github.com/browser-use/browser-use),
+[x1xhlol/system-prompts-and-models-of-ai-tools](https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools),
+and [langgenius/dify](https://github.com/langgenius/dify).
+
+### Changed
+- **`rules/testing.md`** — the "Async/Event-Loop Systems" guidance gains a **condition-based waiting**
+  rule (distilled from superpowers' `condition-based-waiting`, MIT, re-expressed in original,
+  stack-agnostic words): never wait on a fixed delay/sleep, poll for the observable condition instead
+  (framework waiter or a small `wait_for(condition, timeout)`), and avoid the three flakiness traps
+  (no timeout, interval too tight, stale reads). The section previously only said "mock I/O, use
+  async/await" — it never addressed timing-dependent test flakiness.
+
+### Not adopted (deliberately, per the assessment)
+- **superpowers** — 14 skills, ~all duplicate existing kit skills (TDD, `systematic-debugging`→
+  `debugging-and-error-recovery`, `brainstorming`→`idea-refine`/`doubt-driven-development`/`interview-me`,
+  `writing-plans`→`planning-and-task-breakdown`, `executing-plans`→`execute`, `requesting`/`receiving-code-review`→
+  `code-review-and-quality`, `using-git-worktrees`/`finishing-a-development-branch`→`git-workflow-and-versioning`/
+  `shipping-and-launch`/`pr-raiser`, `verification-before-completion`→`rarv-cycle`+`mandatory-workflow`,
+  `dispatching-parallel-agents`→`orchestrator`, `writing-skills`→`using-agent-skills`). Its
+  `testing-anti-patterns` was refuted as a near-duplicate of the TDD skill's existing anti-pattern table.
+- **wshobson/agents** — almost entirely language/framework specialists (violate the stack-agnostic core)
+  or roles the kit already has (`code-reviewer`, `security-auditor`, `incident-responder`,
+  `observability-engineer`, `performance-engineer`, `debugger`, `docs-architect`, `architect-reviewer`,
+  database/devops roles), plus out-of-SDLC-scope domains (SEO, business, data-science). No general gap.
+- **anthropics/skills** — document skills are source-available (not open) and out of scope; the example
+  skills are out of scope (art/design/comms) or duplicative (`skill-creator`→`using-agent-skills`,
+  `frontend-design`→`frontend-ui-engineering`). The `SKILL.md` `name`+`description` convention is already followed.
+- **karpathy/autoresearch** — the closed-loop / single-metric / fixed-budget principles are covered by
+  `evals` + `goal-setting-and-monitoring`; the ML-training loop itself is stack-specific. "Iterate the
+  instructions, not the code" is what the kit already *is* (config-only).
+- **browser-use** — a runtime library; browser automation is already covered by the opt-in `playwright`
+  MCP entry + `browser-testing-with-devtools`/`playwright-verification`. Its "treat DOM/console/network
+  as untrusted" guidance is already a verbatim "Security Boundaries" section in `browser-testing-with-devtools`.
+- **x1xhlol/system-prompts** — GPL-3.0 archive of prompts extracted from proprietary tools (double IP
+  hazard: copyleft + unresolved vendor rights). Its generic principles (plan-first, tool discipline,
+  minimal diffs, verification, concise comms, refusal/secret-safety) are already in `reasoning-techniques`,
+  `tool-design`, `mandatory-workflow`, `agent-guardrails`, `human-in-the-loop`, and `code-review-and-quality`.
+  Nothing was copied.
+- **langgenius/dify** — a runtime platform (Apache-2.0 *with additional conditions*); its principles
+  (ReAct/function-calling agents, inspectable workflow steps, RAG stages, prompt-management feedback)
+  are covered by `reasoning-techniques`, `tool-design`, `context-engineering`, `evals`, and `devops-observability`.
+
+## [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.1}/PKG-INFO

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

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.10.0"
+version = "0.11.1"
 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.1}/rules/testing.md

@@ -383,6 +383,16 @@ For systems with async I/O or event loops (Node.js, Python asyncio, Go goroutine
 - Mock all I/O operations (database, HTTP, file system)
 - Use the test framework's async support (`async/await` in tests)
 - Never use blocking I/O in tests for async systems — mock it or use async equivalents
+- **Wait on conditions, never on the clock.** A fixed delay ("sleep" to let the async work finish)
+  is the single biggest source of flaky tests — too short and it fails under load, too long and it
+  drags out the whole suite. Instead, **poll for the observable condition you actually care about**
+  (the value, state, or side effect) and continue the instant it holds:
+  - Use your framework's condition waiter — e.g. `waitFor` / `expect.poll` (JS), `Awaitility` (JVM),
+    `tenacity` or a polling fixture (Python), `Eventually` (Go) — or a small generic
+    `wait_for(condition, timeout)` that re-checks the live value on a short interval.
+  - Three mistakes that quietly re-introduce flakiness: (1) **no timeout** — the test hangs forever
+    instead of failing; (2) **interval too tight** — a busy-loop that pegs the CPU; (3) **stale
+    reads** — re-evaluate the live value on every poll, never assert against a snapshot captured once.
 
 ### Multi-Tenant/Authorization Systems
 

{claude_code_kit-0.10.0 → claude_code_kit-0.11.1}/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.1}/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.1"