claude-code-kit 0.60.0__tar.gz → 0.61.0__tar.gz

{claude_code_kit-0.60.0 → claude_code_kit-0.61.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.60.0",
+      "version": "0.61.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.60.0",
+  "version": "0.61.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.60.0 → claude_code_kit-0.61.0}/CHANGELOG.md

@@ -4,6 +4,75 @@ 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.61.0] — 2026-07-15
+
+**OSS-adoption wave 2 — nine more items from the 1,345-repo scan backlog** (wave 1 = 0.60.0 below).
+Same discipline: everything re-derived as stack-agnostic prose/data; nothing vendored.
+
+### Added
+
+- **`agent-guardrails` hardening pass** (completes the three guardrails items begun in 0.60.0):
+  the unfamiliar-CLI protocol (`--help` on the *exact leaf command* before first use — validation
+  is not transitive from parent groups; single-item schema discovery before unconstrained list
+  queries), cloud control-plane categories added to the §3 Block tier (IAM/role-binding, billing,
+  org governance, KMS-class key ops, enabling paid APIs, autonomous IaC apply — dry-run/preview
+  mandatory where offered), and a graceful-degradation token ladder in the §4 resource bounds
+  (warn fraction → wrap-up, hard-stop fraction → final answer, ceiling coupled to compaction).
+- **Evals upgrade** (`rules/evals.md` §9–10 + `docs/eval-harness.md`): evals as one versioned
+  declarative config gated in CI (path filters, parsed JSON/JUnit pass-rate, prompt-set-hash
+  response cache, SHA + run-id lineage); colocate a skill's evals beside its `SKILL.md` with
+  with/without-skill A/B judged on the skill's own claims. The harness doc gains the
+  skill-activation eval (trigger F1 + Wilson/Clopper-Pearson/bootstrap certification — the
+  routing-layer failure mode neither arm measured), the falsifiability discipline (assertions must
+  fail in baseline; Signal/Baseline/Unreachable/Regression quadrants; labeled delta bands;
+  path-scoped isolation caveat), and fixed-overhead accounting (always-injected prose is a
+  per-turn flat tax; billing A/B is the only honest end-to-end number).
+- **Pre-run budget declarations**: `goal-setting-and-monitoring` §4 budgets the run from its
+  orchestration shape (>2× single-agent needs written justification; estimate-vs-actual recorded;
+  on-exceed action declared up front) and `wave-orchestration`'s manifest extends
+  announce-the-spend to a full per-wave envelope (hard spawn cap, per-worker max turns, wall-clock
+  timeout, token ceiling) declared as data.
+- **Org governance**: `autonomy-levels` precedence — repo/user overrides may only **tighten**
+  (autonomy = min, allow = intersect, deny = union); `docs/org-capabilities.md` gains the **bypass
+  contract** — every legitimate bypass surface named in one table with its guardrail
+  (`upgrade --force`, sidecar take-ownership, breakglass, `bypassPermissions` + its org disable).
+- **Evidence-based `warn-missing-tests` hook**: convention-named test-file search (same dir +
+  `tests//test//__tests__` walking up) silences the old blanket nag when a test exists; specific
+  messages otherwise ("no test file for X" vs "no RED test recorded — write it first" via
+  `.pytest_cache`); curated skip list for generated/infra trees. Still advisory; still no-ops
+  without `jq`.
+- **`/claude-kit:init` self-install loop**: a missing CLI now offers "Install claude-code-kit now
+  (Recommended)" (pipx, else pip) with re-detection before proceeding; skip/failure/no-installer
+  keep the stop-with-instructions behavior.
+- **Doc-skill upgrades**: `refresh-docs` diffs the documented surface against the code surface and
+  classifies each divergence (`missing_in_docs` / `missing_in_code` / `signature_mismatch` /
+  `description_mismatch`, severity-guided); `documentation-and-adrs` gains the derived-artifact
+  discipline (edit the structured source, regenerate the deliverable, label source-vs-derived,
+  drift-check in CI).
+- **Design intent capture** (`frontend-ui-engineering`): one concrete world-reference over
+  adjective lists; short intentional Do's/Don'ts; tokens are context serving the reference, not
+  rendering instructions.
+- **Directory-review self-audit** (`docs/launch/directory-submission.md`): the reviewer's pass/fail
+  criteria plus the audit run against the kit's own registry — all 21 hooks tabulated (event,
+  gated/advisory, network, plugin-vs-starter); finding: zero direct network calls, one disclosed
+  indirect family (learning capture's background `claude` job, opt-out
+  `CLAUDE_KIT_NO_AUTOCAPTURE=1`).
+
+### Fixed
+
+- `refresh-docs` shipped another project's literal doc paths and a nonexistent `frontend-dev`
+  agent name in its examples — now marked as example shapes / corrected to general-purpose
+  subagents.
+
+### Not adopted (deliberately)
+
+- **The two L-sized scan items** — the `context-engineering` consolidation (8 merged proposals)
+  and the `tool-design` expansion (7 merged proposals) — are deferred to their own focused wave:
+  they overlap each other on the same two files and deserve a single coherent editing pass, not a
+  tail-end squeeze.
+- **The 10 user-gated items** remain gated (list in the 0.60.0 block below) — unchanged, awaiting
+  owner decisions.
+
 ## [0.60.0] — 2026-07-15
 
 **OSS-adoption wave 1 — the first tranche from a 1,345-repo scan.** 39 provenance-tagged GitHub

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.60.0
+Version: 0.61.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.60.0 → claude_code_kit-0.61.0}/commands/init.md

@@ -17,9 +17,19 @@ command -v claude-kit >/dev/null 2>&1 && echo "CKIT_CLI=claude-kit" \
   || echo "CKIT_CLI_MISSING"; }; }
 ```
 
-**If the output is `CKIT_CLI_MISSING`, STOP — do not scaffold anything.** The CLI is not installed
-under any of its names. Tell the user it is required and how to install it, then have them re-run
-`/claude-kit:init`. Do **not** silently fall back to a partial install:
+**If the output is `CKIT_CLI_MISSING`, offer to install it — never scaffold without it.** The CLI
+is not installed under any of its names. When an installer is available on PATH (`pipx`, else
+`pip`/`pip3`), ask ONE AskUserQuestion with the install option first:
+
+- **"Install claude-code-kit now (Recommended)"** — on accept, run `pipx install claude-code-kit`
+  (fall back to `pip install claude-code-kit` when pipx is absent), then **re-run the detection
+  block above** and proceed only if a CLI name now resolves.
+- **"Skip"** — or if the install fails, or no installer is on PATH: STOP — do not scaffold
+  anything. Tell the user the CLI is required, show both install commands below, and have them
+  re-run `/claude-kit:init`. Do not silently fall back to a partial install.
+
+Never ask when the CLI is already present, and never ask when no installer exists on PATH (nothing
+to offer — go straight to the stop-with-instructions):
 
 - Recommended: `pipx install claude-code-kit`
 - Or: `pip install claude-code-kit`

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/docs/eval-harness.md

@@ -48,6 +48,50 @@ class Y, Z% of the time."
 > The pipeline costs more per task by design (more agents, more gates). The question this harness
 > answers is whether the **defects caught** (and their severity) justify that delta **for your task mix**.
 
+## Skill-activation eval (the routing layer)
+
+The arms above grade what happens *after* a skill or rule fires. A separate failure mode sits in
+front of both: does the skill **activate when it should — and stay quiet when it shouldn't**?
+Neither arm measures routing; add it as its own small suite.
+
+- **Trigger F1.** Build two prompt lists per skill: *should-activate* (phrasings a real user would
+  use) and *should-not-activate* (near-misses from neighboring domains). Run both, score activation
+  as binary, report **precision / recall / F1**. A skill with great content and 40% recall is a
+  great document nobody reads; one that fires on near-misses taxes every unrelated task.
+- **Monte Carlo certification for any number you publish.** Activation is stochastic — run each list
+  repeatedly and report the **Wilson confidence interval** on the activation rate, a
+  **Clopper-Pearson bound** on the should-activate failure rate (the conservative "at worst" claim),
+  and a **bootstrap consistency** check across resamples. "Activates 19/20, 95% CI [86%, 99%]" is a
+  claim; "it seems to trigger" is not.
+
+## Falsifiability discipline (before you trust any delta)
+
+- **The falsifiability gate.** Every assertion must **fail in the baseline arm** at least sometimes —
+  an assertion that passes in both arms measures the model, not the pipeline, and supports no claim.
+  Drop it or sharpen it.
+- **Quadrant-classify each row before averaging anything:** **Signal** (fails A, passes B — the
+  pipeline earned it) · **Baseline** (passes both — too easy, doesn't count) · **Unreachable**
+  (fails both — can't discriminate at this model tier) · **Regression** (passes A, fails B — the
+  pipeline *hurt*; investigate before shipping). Only Signal rows support a value claim; every
+  Regression row is a finding in its own right.
+- **Label delta bands.** Report deltas with a qualitative band (noise / weak / strong at your N)
+  rather than celebrating a 3% move the confidence interval can't distinguish from zero.
+- **Path-scoped isolation caveat.** If a rule/overlay is path-scoped (loads only when matching files
+  are touched), confirm both arms actually touch those paths — otherwise the comparison silently
+  measures *activation*, not content.
+
+## Fixed-overhead accounting
+
+Always-injected prose is a **flat tax on every turn**, paid whether or not the content helps that
+turn (measure your own install — see `docs/rules-context-budget.md`; even a single always-on rule
+file costs on the order of 1–1.5k tokens per turn, and a full rule set far more). So the eval
+question is not "does the pipeline help" but "does the help **beat the tax** for your task mix":
+
+- Put the per-turn injected overhead in the Cost table, not only per-task totals.
+- The only honest end-to-end number is a **billing A/B** — the same task mix with and without,
+  compared on what you were actually charged. Token figures extrapolated from a single run are
+  estimates: label them **est.**
+
 ## Honesty rules
 
 - **Never publish numbers you did not run.** A "90%" from one run and from twenty runs are not the same

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/docs/launch/directory-submission.md

@@ -68,10 +68,64 @@ Before submitting, **re-check the live documentation** at the URLs below. Plugin
 - Plugin marketplaces: [code.claude.com/docs/en/plugin-marketplaces](https://code.claude.com/docs/en/plugin-marketplaces)
 - Plugin reference: [code.claude.com/docs/en/plugins-reference](https://code.claude.com/docs/en/plugins-reference)
 
+## Directory Review Self-Audit
+
+Directory reviewers apply pass/fail criteria a submitter can run against themselves first. Three
+that decide outcomes:
+
+1. **Description-matches-behavior (the surprise test).** For every hook, command, and skill: would
+   a user who read only its description be *surprised* by anything it actually does? Any surprise
+   is a fix-before-submitting.
+2. **Undisclosed outbound calls = automatic fail.** Every network touch (direct or via a spawned
+   tool) must be disclosed in the component's description *and* have an opt-out.
+3. **The whole shipped payload is in scope — including directories the plugin doesn't load.**
+   A git-source install clones everything (`scripts/`, `templates/`, `catalog/`, `examples/`), so
+   the audit covers the full tree, not just auto-discovered components.
+
+### First-party hook audit (run against this kit's own registry)
+
+All hooks in the shipped registry, in the reviewer's format — `EVENT:hook — gated|advisory —
+network`. **gated** = can block the action (exit 2 / deny); **advisory** = warn-or-context only,
+always exits 0. Every script degrades to a no-op without `jq`. Regenerate this table when the
+registry changes (`src/claude_kit/hooks.py` is the source of truth; `gen_hooks.py --check` pins the
+generated configs).
+
+| Hook | Event | Mode | Network | In plugin hooks.json |
+|------|-------|------|---------|----------------------|
+| load-continuity | SessionStart | advisory | no | yes |
+| load-learnings | SessionStart | advisory | no | yes |
+| load-autonomy | SessionStart | advisory | no | yes |
+| capture-learnings-catchup | SessionStart | advisory | **indirect** — spawns a background `claude` job (model API); disclosed, opt-out `CLAUDE_KIT_NO_AUTOCAPTURE=1` | yes |
+| guard-rm-rf | PreToolUse | **gated** (inline) | no | yes |
+| guard-push-main | PreToolUse | **gated** | no | yes |
+| guard-destructive-git | PreToolUse | **gated** | no | yes |
+| protect-secrets | PreToolUse | **gated** (inline) | no | yes |
+| guard-commit-secrets | PreToolUse | **gated** | no | yes |
+| validate-settings | PreToolUse | **gated** | no | yes |
+| warn-shared-modules | PreToolUse | advisory | no | yes |
+| warn-llm-io | PreToolUse | advisory | no | yes |
+| warn-sensitive-files | PreToolUse | advisory | no | yes |
+| warn-large-edits | PreToolUse | advisory | no | starter only |
+| validate-frontmatter | PreToolUse | advisory | no | starter only |
+| warn-missing-tests | PostToolUse | advisory | no | starter only |
+| audit-log | PostToolUse | advisory | no | starter only |
+| lint-fix | Stop | advisory (runs the project's linter) | no | yes |
+| type-check | Stop | advisory (runs the project's type-checker) | no | yes |
+| capture-learnings-stop | Stop | advisory | indirect — same `claude` job + opt-out as above | starter only |
+| capture-learnings | SessionEnd | advisory | indirect — same `claude` job + opt-out as above | yes |
+
+**Audit result:** 21 registry hooks (16 ride the plugin's `hooks.json`; the rest install via the
+scaffolded starter `settings.json`). One behavior family touches the network, *indirectly*, via a
+spawned `claude` background job (learning capture) — disclosed in the init interview, surfaced by
+`doctor`, and opt-out via `CLAUDE_KIT_NO_AUTOCAPTURE=1`. No hook makes a direct outbound call. All
+gated hooks are deterministic string/path guards with no data egress. This passes criteria 1–3
+above as of the audit date; re-run after any hook change.
+
 ## Owner Submission Checklist
 
 - [ ] Run `claude plugin validate .` and `claude plugin validate . --strict`
 - [ ] Fix any validation errors (warnings are optional)
+- [ ] Re-run the Directory Review Self-Audit above (hook table current, no undisclosed network, no description surprises)
 - [ ] Verify the live submission form and documentation links above
 - [ ] Consider the optional manifest hygiene items (not required)
 - [ ] Choose submission path: solo (platform.claude.com) or organization (claude.ai)

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/docs/org-capabilities.md

@@ -189,6 +189,23 @@ via `/deprecation-and-migration`; have security/DevOps approve hooks and sensiti
 and roll out repo-by-repo with `claude-kit diff` → `claude-kit upgrade`; run different autonomy levels
 per repo; capture recurring prompts (→ skills) and mistakes (→ rules) via the `remember` skill.
 
+### Precedence & the bypass contract
+
+**Overrides only tighten.** Repo- and user-level settings may lower autonomy, add gates/denies, or
+escalate a warn to a block — never the reverse (allow = intersect, deny = union, autonomy =
+min(org, repo)); see `.claude/rules/autonomy-levels.md` "Precedence". The corollary is that every
+*legitimate* way around the policy must be **named**, so none is discoverable-only. The kit's real
+bypass surfaces are exactly these:
+
+| Bypass surface | What it bypasses | Guardrail around it |
+|----------------|------------------|---------------------|
+| `claude-kit upgrade --force` | edit-preserving upgrade (overwrites drifted kit files) | drifted originals are backed up as sidecars; diff first |
+| Sidecar take-ownership (keep your edit, discard the kit's `.claude-kit` sidecar) | kit ownership of a file | the manifest marks it user-owned from then on — upgrades stop touching it |
+| Breakglass (emergency human override) | a gate or block during an incident | scoped + logged per `.claude/rules/human-in-the-loop.md`; reviewed afterwards |
+| `bypassPermissions` mode | Claude Code's permission prompts | org-side `disableBypassPermissionsMode` can remove it entirely |
+
+Anything not on this list that circumvents policy is a finding, not a feature.
+
 ### Planned
 
 `claude-sdlc package-org-pack` / `install-org-pack` are registered as **planned** stubs — they will

claude_code_kit-0.61.0/hooks/scripts/warn-missing-tests.sh

@@ -0,0 +1,90 @@
+#!/usr/bin/env bash
+# PostToolUse(Edit|Write): after a source-code change, check for EVIDENCE of tests before nudging.
+# Evidence-based, not a blanket reminder: looks for a sibling/convention-named test file
+# (test_<stem>.py, <stem>_test.py, <stem>.test|spec.<ext>, <stem>_test.go, <stem>Test(s).cs, ...)
+# in the same dir and in tests//test//__tests__ dirs walking up from the file; if a test file
+# exists, checks .pytest_cache/v/cache/lastfailed for a recorded RED test for the module (Python).
+# Emits a SPECIFIC message only when evidence is absent; stays quiet when a test file exists.
+# Advisory only (always exits 0). Quiet for test files, docs, config, generated/infra trees, and
+# the .claude/ config itself. Degrades to a no-op without jq.
+# The reminder returns as hookSpecificOutput.additionalContext JSON on stdout (Claude reads it next
+# to the tool result, per the current hooks reference) -- exit-0 stderr is debug-log-only.
+command -v jq >/dev/null 2>&1 || exit 0
+INPUT="$(cat)"
+FILE_PATH="$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_response.filePath // empty' 2>/dev/null || true)"
+[ -z "$FILE_PATH" ] || [ "$FILE_PATH" = "null" ] && exit 0
+
+low="$(printf '%s' "$FILE_PATH" | tr '[:upper:]' '[:lower:]')"
+
+# Skip non-source: tests, docs, config, markdown, and the kit's own config.
+case "$low" in
+  *test*|*spec*|*.md|*.markdown|*.json|*.ya?ml|*.toml|*.ini|*.cfg|*.txt|*.lock|*/.claude/*)
+    exit 0 ;;
+esac
+
+# Curated skip list: trees that legitimately ship without sibling tests (generated, infra, vendored).
+case "$low" in
+  */migrations/*|*/alembic/*|*/terraform/*|*/generated/*|*/proto/*|*/infra/*|*/dist/*|*/build/*|*/node_modules/*|*/vendor/*|*/.venv/*)
+    exit 0 ;;
+esac
+
+# Only check recognisable source files.
+case "$low" in
+  *.py|*.ts|*.tsx|*.js|*.jsx|*.go|*.rs|*.rb|*.java|*.kt|*.cs|*.php|*.swift|*.scala|*.c|*.cc|*.cpp|*.h|*.hpp) : ;;
+  *) exit 0 ;;
+esac
+
+base="$(basename "$FILE_PATH")"
+dir="$(dirname "$FILE_PATH")"
+stem="${base%.*}"
+ext="${base##*.}"
+
+# Test-file name candidates per ecosystem convention.
+cands=()
+case "$ext" in
+  py)          cands=("test_${stem}.py" "${stem}_test.py") ;;
+  go)          cands=("${stem}_test.go") ;;
+  cs)          cands=("${stem}Tests.cs" "${stem}Test.cs") ;;
+  rb)          cands=("${stem}_spec.rb" "${stem}_test.rb") ;;
+  ts|tsx|js|jsx) cands=("${stem}.test.${ext}" "${stem}.spec.${ext}") ;;
+  *)           cands=("test_${stem}.${ext}" "${stem}_test.${ext}" "${stem}.test.${ext}" "${stem}.spec.${ext}") ;;
+esac
+
+# Evidence search: sibling in the same dir, then tests//test//__tests__ dirs walking up (bounded).
+found=""
+for cand in "${cands[@]}"; do
+  [ -f "$dir/$cand" ] && { found=1; break; }
+done
+if [ -z "$found" ]; then
+  d="$dir"
+  for _ in 1 2 3 4 5 6; do
+    for td in tests test __tests__; do
+      [ -d "$d/$td" ] || continue
+      for cand in "${cands[@]}"; do
+        if find "$d/$td" -maxdepth 4 -name "$cand" -print -quit 2>/dev/null | grep -q .; then
+          found=1
+          break 3
+        fi
+      done
+    done
+    parent="$(dirname "$d")"
+    [ "$parent" = "$d" ] && break
+    d="$parent"
+  done
+fi
+
+W=""
+if [ -z "$found" ]; then
+  W="REMINDER: no test file found for $FILE_PATH (searched sibling + tests//test//__tests__ conventions: ${cands[*]}) -- create one before marking work complete (.claude/rules/testing.md)."
+elif [ "$ext" = "py" ] && [ -f ".pytest_cache/v/cache/lastfailed" ]; then
+  # A test file exists; for Python, check whether a RED test was ever recorded for this module.
+  if ! jq -r 'keys[]' .pytest_cache/v/cache/lastfailed 2>/dev/null | grep -q "$stem"; then
+    W="NOTE: tests exist for $stem but no failing test was recorded for it -- if this change adds behavior, write the RED test first (.claude/rules/testing.md)."
+  fi
+fi
+
+if [ -n "$W" ]; then
+  # stdout must be ONLY the JSON object for Claude Code to process it.
+  jq -n --arg ctx "$W" '{hookSpecificOutput: {hookEventName: "PostToolUse", additionalContext: $ctx}}'
+fi
+exit 0

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.60.0"
+version = "0.61.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.60.0 → claude_code_kit-0.61.0}/rules/agent-guardrails.md

@@ -72,6 +72,13 @@ Before declaring a stage done or handing to the next agent/human:
   filesystem or data guarantee; and any client-side flag is **secondary to the real authorization
   boundary** — the backend's IAM/role grants are what actually limit blast radius, so scope those
   first and treat the flag as a second layer, never the first.
+- **Unfamiliar-CLI protocol — validate the leaf, then discover the schema.** Before first use of a
+  CLI subcommand you haven't run in this project, read `--help` on the **exact leaf command** you are
+  about to invoke — validation is not transitive from a parent group (`tool db --help` tells you
+  nothing about `tool db restore`'s destructive flags). And before any unconstrained list/query
+  call, do **single-item schema discovery** first (`--limit 1` + machine-readable output), then
+  re-query projected to only the fields you need — you learn the response shape without flooding
+  your context or hammering the backend.
 - **Destructive or outward-facing actions are gated.** Deleting/overwriting files you didn't create,
   force-pushing, deploying, publishing, or sending data to an external service are **human decision
   points** — see `.claude/rules/human-in-the-loop.md`. Confirm first.
@@ -86,7 +93,11 @@ and act on it — do not improvise a destructive step because it seems convenien
 - **Block — never autonomously.** Force-push, rewriting already-published history, deleting a branch
   or tag, a destructive schema change against live data (`DROP` / `TRUNCATE` / column drop / a
   narrowing or `NOT NULL` on existing rows), bulk or recursive deletion, or disabling a safety
-  control. These need explicit human authorization first — the **restricted** tier of
+  control. In cloud control planes the same tier covers: **IAM / role-binding changes, billing
+  changes, org-level governance edits, KMS-class key operations** (schedule-delete, disable,
+  rotation changes), **enabling paid APIs/services, and an autonomous IaC apply** — where the tool
+  offers a dry-run/preview/plan mode, running it is mandatory and its output goes to the human with
+  the request. These need explicit human authorization first — the **restricted** tier of
   `.claude/rules/risk-classification.md`. Several are also stopped deterministically by
   `hooks/scripts/guard-destructive-git.sh` and the `rm -rf` / push-to-main guards.
 - **Confirm — pause and get a yes.** Deleting or overwriting a file you did not create, applying a
@@ -126,7 +137,11 @@ agent on a broken foundation.* Before worrying about prompt injection, enforce t
     default (never "the whole disk, minus a deny-list").
   - **Network** — deny outbound by default; allowlist only the hosts the task genuinely needs.
   - **Resource bounds** — wall-clock timeout plus memory/output caps, so a runaway or adversarial step
-    fails *closed* instead of hanging or flooding.
+    fails *closed* instead of hanging or flooding. For token budgets, degrade **gracefully** rather
+    than cliff-stopping: a warn fraction (~80%) injects a wrap-up signal (finish the current step,
+    persist state), a hard-stop fraction forces a final answer from what is in hand, and the ceiling
+    is set with compaction in mind — when compaction is active the ceiling bounds a *window*, not
+    the run, so couple the two deliberately.
   - **Versioned & runtime-updatable** — keep the policy as data you can tighten mid-run (ties to §5's
     revocable authz) and review afterward, not constants baked into the agent.
 

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/rules/autonomy-levels.md

@@ -13,6 +13,16 @@ deterministic parts are enforced by hooks and `settings.permissions`, the rest i
 | **autonomous-pr** | create branches + PR-ready changes | **merge** — human review is required before merge |
 | **enterprise-controlled** | work only through strict gates with an audit trail | edit sensitive files without approval; complete without the security + review agents passing |
 
+## Precedence — overrides may only tighten
+
+When org policy and a repo- or user-level setting disagree, the resolution is always the **stricter**
+of the two: effective autonomy = **min(org, repo)**; allow-lists **intersect**; deny-lists **union**;
+a warn may be escalated to a block locally, but a block is never downgraded to a warn. A repo can
+run *more* cautiously than its org demands, never less — there is no repo-level "loosen" switch.
+Legitimate exceptions go through the named bypass surfaces (the "Bypass contract" in
+`docs/org-capabilities.md` of the claude-kit repo), which are explicit and auditable — not a quiet
+config override.
+
 ## Rules
 
 - **Never exceed the active level.** If a task needs more autonomy than granted, stop and ask — do not

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/rules/evals.md

@@ -142,6 +142,38 @@ A single-turn eval will not catch this; claude-kit's own agents run over long mu
 > [`microsoft/lost_in_conversation`](https://github.com/microsoft/lost_in_conversation). Re-derived in
 > prose; not vendored.
 
+## 9. Evals as versioned, declarative config — gated in CI
+
+Keep the eval suite as **one declarative config file in the repo** — cases × graders × pass
+thresholds together (the shape popularized by promptfoo-style runners; any runner with those three
+parts qualifies). Config-as-data is what makes the Rules below enforceable: the eval diff rides in
+the same PR as the behavior change, and CI — not memory — runs it.
+
+- **Trigger on behavior-changing paths.** Path-filter the CI job to the files that change model
+  behavior (prompts, rules, skills, agent definitions, model/tier config) so the suite runs when it
+  must and stays out of unrelated PRs.
+- **Gate on parsed results, not exit codes alone.** Emit machine-readable output (JSON / JUnit),
+  parse the pass rate, and fail the job against the declared threshold — that is what turns the eval
+  into a *gate* (§6) instead of a log line.
+- **Cache responses keyed on the prompt-set hash.** Reruns whose inputs didn't change replay from
+  cache — CI stays fast and cheap, and a score delta isolates the change you actually made.
+- **Record lineage.** Stamp every run with the git SHA and a run id, so any score is traceable to
+  the exact config + code that produced it.
+
+## 10. Colocate a skill's evals with the skill
+
+A skill's eval lives **beside the skill** — an `evals/evals.json` next to its `SKILL.md` declaring
+the cases (the emerging agent-skills colocation convention) — not in a central suite it will drift
+from. Two properties matter more than the file layout:
+
+- **A/B against the skill's absence.** Each case runs *with* and *without* the skill and is judged
+  on assertions the skill's own prose claims (cited criteria, not vibes). A skill that does not
+  measurably beat its absence on its own claims is context cost with no return — the same
+  with/without method as the kit-level harness (`docs/eval-harness.md` in the claude-kit repo),
+  applied per skill.
+- **Runners are referenced, not bundled.** Ready runners exist for exactly this layout (e.g.
+  `agent-skills-eval`); any tool that executes colocated cases with/without the skill qualifies.
+
 ## Rules
 
 1. **No prompt/rule/tool/model change ships without an eval run** that covers the affected behavior.

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/rules/goal-setting-and-monitoring.md

@@ -80,6 +80,15 @@ This turns "I think the run is progressing" into a measured session you can grad
 (`.claude/rules/evals.md`) and trend. (This is *agent-run* telemetry; **app and LLM** observability
 live in the `observability-and-logging`, `otel-tracing`, and `langfuse-llm-tracing` skills.)
 
+**Budget the run before you launch it.** Spend is a criterion too — declare it up front like any
+other goal, derived from the orchestration shape: single agent ≈ 1×, maker-checker ≈ 2×,
+parallel-N ≈ N+1× (workers + a merge pass), debate-R ≈ 1+R×. Anything over ~2× the single-agent
+baseline needs a written justification before tokens go out, not an apology after. Record
+**estimate vs actual** in the run telemetry above, and define the **on-exceed action** with the
+budget: stop spawning, checkpoint state to `.claude/CONTINUITY.md`, and escalate per
+`.claude/rules/human-in-the-loop.md` — never silently run past the number you announced. (Wave-scale
+declarations live in `.claude/rules/wave-orchestration.md`'s manifest.)
+
 > Stack-agnostic adaptation of the agent-session instrumentation pattern in the Apache-2.0
 > [`alibaba/loongsuite-js`](https://github.com/alibaba/loongsuite-js) (session→turn→tool/LLM span
 > hierarchy via runtime hooks, GenAI semantic-convention attributes). Re-derived in prose; not vendored.

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/rules/wave-orchestration.md

@@ -124,6 +124,14 @@ Announce the spend before it happens: the manifest states the worker count per w
 orchestrator repeats that count (and its model tiers) when opening each wave — scale is vetoable
 before the tokens go out, not after.
 
+Counts and tiers are the minimum; a load-bearing manifest declares the **full spend envelope as
+data** beside them, per wave: a **hard spawn cap** (the count is a plan; the cap is a limit), a
+**max-turns bound per worker**, a **wall-clock timeout for the wave**, and a **token ceiling** —
+with the on-exceed action declared up front (stop spawning, checkpoint, escalate) per
+`.claude/rules/goal-setting-and-monitoring.md` §4. That makes both *scale and spend* vetoable
+before launch, and makes "the wave ran hot" a measured fact (estimate vs actual) instead of a
+surprise on the bill.
+
 ## Native dynamic workflows as the wave substrate
 
 Claude Code ≥ 2.1.154 ships a native **dynamic-workflows engine**: Claude writes a JavaScript

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/skills/documentation-and-adrs/SKILL.md

@@ -239,6 +239,22 @@ Link to ADRs for details.
 How to contribute, coding standards, PR process.
 ```
 
+## Derived Artifacts: Edit the Source, Regenerate the Output
+
+Some documentation is **generated from a structured source of truth** — API docs rendered from an
+OpenAPI spec, config files emitted by a generator script, reference tables built from a registry.
+For these, the discipline is absolute:
+
+- **Edits go to the structured input, never the deliverable.** Hand-patching a generated file
+  creates a fork the next regeneration silently destroys (or worse, that a drift check now has to
+  arbitrate).
+- **State which file is source and which is derived** — in the doc's header or the repo's docs — so
+  no future editor has to guess. An unlabeled generated file *will* eventually be hand-edited.
+- **Regenerate + drift-check in CI.** The generator should have a `--check` mode that fails CI when
+  the committed output no longer matches the source; that single check converts the convention into
+  a guarantee. (claude-kit itself lives this rule: its hook config files are generated from a
+  registry and CI fails on drift.)
+
 ## Changelog Maintenance
 
 For shipped features:

{claude_code_kit-0.60.0 → claude_code_kit-0.61.0}/skills/frontend-ui-engineering/SKILL.md

@@ -115,6 +115,23 @@ Global store                     → Complex client state shared app-wide
 
 ## Design System Adherence
 
+### Capture the Design Intent as a Specific Reference
+
+Before styling anything new, pin down what the design is *aiming at* — and demand **one concrete
+world-reference over a list of adjectives**. "Modern, clean, premium" describes a region containing
+thousands of incompatible designs; "a 1970s graduate lecture handout" or "a Braun product manual"
+describes a point you can actually converge on. When the user offers only adjectives, ask for the
+reference ("what existing thing should this feel like?") — that one answer replaces a whole
+round of taste-guessing iterations.
+
+- Pair the reference with a **short, intentional Do's/Don'ts list** (3–5 each). A rambling
+  don't-list is a signal the reference is still vague — sharpen the reference instead of growing
+  the list.
+- **Design tokens are context serving that prose, not rendering instructions.** The
+  reference + Do's/Don'ts carry the intent; tokens (spacing scale, palette, radii) are the
+  vocabulary it gets expressed in. Tokens without a reference reproduce the AI aesthetic below in
+  the project's own colors.
+
 ### Avoid the AI Aesthetic
 
 AI-generated UI has recognizable patterns. Avoid all of them: