claude-code-kit 0.45.0__tar.gz → 0.47.0__tar.gz

{claude_code_kit-0.45.0 → claude_code_kit-0.47.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.45.0",
+      "version": "0.47.0",
       "license": "MIT",
       "keywords": ["sdlc", "agents", "orchestration", "quality-gates", "workflow", "scaffold", "cookiecutter"]
     }

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-kit",
-  "version": "0.45.0",
+  "version": "0.47.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.45.0 → claude_code_kit-0.47.0}/CHANGELOG.md

@@ -4,6 +4,67 @@ 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.47.0] — 2026-06-27
+
+**Adopt 5 verified agentic-engineering patterns from an exhaustive review of the Alibaba GitHub org**
+— all 542 repos were reviewed; the overwhelming majority (Java middleware, ML/inference infra, mobile
+UI, frontend frameworks) yield nothing transferable to a stack-agnostic config scaffolder, and an
+adversarial verification pass dropped a sixth candidate (`p3c`) as unsubstantiated + already covered.
+The five that survived are re-derived **in prose (never vendored)** from Apache-2.0 sources, and the
+agnostic core stays free of framework/product names:
+
+- **`rules/evals.md` §7 — staged, leak-resistant eval pipelines** (from `alibaba/atrex-bench`):
+  sequential gates (build → correct → efficient, each gating the next), generate/grade session
+  isolation so the model can't read the answer, and objective external baselines instead of
+  self-grading.
+- **`rules/agent-guardrails.md` §5 — operation authorization** (from `alibaba/open-agent-auth`): a
+  delegated user→agent→operation authority chain, per-request revocable credential scope, a verifiable
+  audit trail, and runtime-updatable authz policy — distinct from the existing input/output/tool
+  guardrails.
+- **`rules/tool-design.md` §8 — orchestrating a tool *set*** (from `alibaba/app-controller` +
+  `alibaba/loongsuite-js`): registry-based discovery, plan-before-execute, concurrent independent
+  calls, durable cross-turn workflow state, written atomically (tmp-write-then-rename) to survive
+  concurrent hooks/agents.
+- **`rules/goal-setting-and-monitoring.md` §4 — instrument the run** (from `alibaba/loongsuite-js`):
+  model the agent run as a `session → turn → tool/LLM` span tree hung off the host's existing hooks,
+  with a stable (GenAI-semconv) attribute vocabulary — measured monitoring, not assumed.
+- **`skills/debugging-and-error-recovery` — live-attach debugging** (from `alibaba/arthas`;
+  `jvm-sandbox` referenced for concept only): the missing third mode (attach → instrument/profile/
+  inject-fault → observe → detach) for non-reproducible production bugs where restart is infeasible,
+  gated as a `block`/`confirm`-tier action with multi-language illustrative tooling.
+
+No count/anchor changes (rules and skills extended, none added). Version 0.46.0 → 0.47.0.
+
+## [0.46.0] — 2026-06-27
+
+**New `design-system-ops` collection skill** — the **operations layer** for a design system: the work
+*after* components are built. Where the existing `radix-tailwind-component-patterns` / `component-design`
+skills *build* components and `ui-ux-design` verifies *one* screen during implementation, this skill
+audits, governs, documents, validates, and measures the **system as a whole, over time** — the genuine
+gap in the kit's design coverage.
+
+- **`skills/design-system-ops/`** — `SKILL.md` (operations lifecycle: audit → govern → document →
+  validate → communicate, with explicit `Do NOT use … → use <sibling>` boundaries) + `README.md` +
+  five `references/`:
+  - `token-architecture.md` — three-tier token model (primitive → semantic → component),
+    strictly-downward references, naming, DTCG 2025.10 alignment, cross-platform handling.
+  - `system-health-and-maturity.md` — seven health dimensions, library-type classification, five
+    maturity stages, and how to grade/calibrate.
+  - `drift-detection.md` — four drift kinds (visual/behavioural/API/token), A/C/E classification,
+    styling-specific token-drift detection, severity, trend tracking.
+  - `governance-and-adoption.md` — deprecation, decision records, contribution + change communication;
+    adoption model (coverage ≠ adoption, four signals, leading/lagging, per-team).
+  - `ai-readiness.md` — context cascade, three pillars, six AI-readiness dimensions, Component
+    Challenge Rating calibration.
+- **Reuse-first, attributed:** frameworks **re-derived stack-agnostic** (not vendored) from the
+  MIT-licensed [`murphytrueman/design-system-ops`](https://github.com/murphytrueman/design-system-ops)
+  (© 2026 Murphy Trueman), re-expressed in the kit's idiom.
+- **Cross-links:** reciprocal scope-boundary pointer added to `ui-ux-design` (per-feature build-time →
+  this system-wide layer); decision records route to `documentation-and-adrs`; WCAG to
+  `accessibility-review`.
+- **Counts:** skills **103 → 104** (collection **47 → 48**, core unchanged at 56); `docs/stack-skills`
+  table row + routing entry added.
+
 ## [0.45.0] — 2026-06-27
 
 **Adopt `library-skills` as a referenced companion** — [`library-skills`](https://library-skills.io)

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: claude-code-kit
-Version: 0.45.0
+Version: 0.47.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
@@ -84,7 +84,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **103** context-activated skills (56 core + 47 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **104** context-activated skills (56 core + 48 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -281,7 +281,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **103 on-demand skills** in [`skills/`](skills/) (56 core + 47 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **104 on-demand skills** in [`skills/`](skills/) (56 core + 48 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -437,7 +437,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. No daemon, no lock-in, no app code. |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 103 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 104 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/README.md

@@ -54,7 +54,7 @@ Quick start) for the full breakdown of any row.
 | 🔁 **Pipeline & quality gates** | Gate-enforced progression (zero open Critical/High/Medium to advance), per-profile gate sets, a fast-track for small changes, and an anti-sycophancy `devils-advocate` pass |
 | 🤖 **Agent roster** | **28** tiered agents + per-database overlays + **6** org personas, led by an Orchestrator that never writes code |
 | 🔍 **Self-verification & review** | RARV green-Verify (real commands, not imagined), blind parallel review, and read-only risk classification |
-| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **103** context-activated skills (56 core + 47 stack-collection) |
+| 📐 **Rules & skills** | **23** stack-agnostic core rules (incl. 8 agent-operation rules) + **104** context-activated skills (56 core + 48 stack-collection) |
 | 🧱 **Stacks & overlays** | Stack-agnostic core + **10** overlay rule sets (React · FastAPI · Go · Postgres · Mongo) wired to your exact commands, incl. a full React design system |
 | 🎚️ **Profiles, scopes & org** | **3** rigor profiles · **3** scopes · **5** autonomy levels · **7** org packs + **10** policy rules |
 | 🧠 **Memory & learning** | Working memory across context compaction + a cost-aware learnings loop (`capture_mode`) so the same mistake isn't repeated |
@@ -251,7 +251,7 @@ need.
 - **23 stack-agnostic core rules** in [`rules/`](rules/) — `mandatory-workflow`, `quality-gates`,
   `rarv-cycle`, `continuity`, plus eight agent-operation rules and `autonomy-levels` +
   `risk-classification` (see [`docs/agentic-patterns.md`](docs/agentic-patterns.md)).
-- **103 on-demand skills** in [`skills/`](skills/) (56 core + 47 stack-collection) — spec-driven dev, planning, TDD, debugging, code
+- **104 on-demand skills** in [`skills/`](skills/) (56 core + 48 stack-collection) — spec-driven dev, planning, TDD, debugging, code
   review, threat modeling, and more — activated by context and led by the `sdlc` entrypoint.
 - **Profile-subset install** — each profile installs a strict subset of agents, skills, hooks, and
   rules (`lean ⊂ standard ⊂ enterprise`), from fast track to full audit.
@@ -407,7 +407,7 @@ owned gates, and the rule that **no gate passes on an unproven verdict**.
 | **[wshobson/agents](https://github.com/wshobson/agents)** & similar agent collections | Large libraries of individual subagent prompts you pick from | A **smaller, opinionated set wired into a sequenced pipeline with owned quality gates** — agents aren't a menu, they're stages that hand off and block on each other. Adopt-by-reuse, not by accumulation. |
 | **[GitHub spec-kit](https://github.com/github/spec-kit)** | A spec-driven workflow (constitution → spec → tasks → analyze) | The same coverage-gate idea (the `story-planner` 1f gate + `task-tracker-sync`) **absorbed into a broader** lifecycle that also covers review, security, build, test, release, and observability gates. Complementary, wider scope. |
 | **claude-flow / multi-agent runtimes** | Runtime orchestrators that *execute* swarms of agents | **Portable configuration**, not a running process — the orchestration is described in rules the host (Claude Code) executes. No daemon, no lock-in, no app code. |
-| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 103 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
+| **dotfiles / `CLAUDE.md` starters** | A single rules file or settings snippet | A **catalog-driven generator**: resolves your stack/profile/scope into the right subset of 23 rules, 28 agents, 104 skills, gates, and hooks, kept **upgradeable** (`claude-kit upgrade` preserves your edits via owner + checksum). |
 
 **Choose claude-kit when** you want a consistent, reviewable, **gate-enforced** autonomous-SDLC setup
 that's the same across every repo and stack, installs in seconds, ships nothing you have to run, and

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/docs/stack-skills/README.md

@@ -1,6 +1,6 @@
 # Production Engineering Skills Collection
 
-These forty-seven Claude Code skills encode production-proven engineering conventions derived from real-world Python/FastAPI, Node/Express, and React services. Each skill was extracted from analyzing patterns across multiple production backend and frontend services, capturing canonical patterns for FastAPI microservices, async Python, Kafka/Temporal integration, multi-tenancy, database access, layered configuration, Redis caching, GCS file handling, LLM integration (Vertex AI / Langfuse), Node/Express services, React frontends (state, data-fetching, forms, design systems, testing), observability (including Grafana dashboards & unified alerting), authentication, containerization (with granular Dockerfile/compose deep-dives), testing, data pipelines, security scanning (OWASP ZAP VAPT/DAST and autonomous AI pentesting), security architecture (edge-to-service signed-identity trust boundary, Kubernetes workload hardening), scheduled & recurring jobs (Kubernetes CronJob + Temporal Schedule), kubectl day-2 operations, and modernization strategies. Use them to align new projects with established patterns, audit existing services, or onboard engineers to modern Python, Node, and React development practices.
+These forty-eight Claude Code skills encode production-proven engineering conventions derived from real-world Python/FastAPI, Node/Express, and React services. Each skill was extracted from analyzing patterns across multiple production backend and frontend services, capturing canonical patterns for FastAPI microservices, async Python, Kafka/Temporal integration, multi-tenancy, database access, layered configuration, Redis caching, GCS file handling, LLM integration (Vertex AI / Langfuse), Node/Express services, React frontends (state, data-fetching, forms, design systems, testing), observability (including Grafana dashboards & unified alerting), authentication, containerization (with granular Dockerfile/compose deep-dives), testing, data pipelines, security scanning (OWASP ZAP VAPT/DAST and autonomous AI pentesting), security architecture (edge-to-service signed-identity trust boundary, Kubernetes workload hardening), scheduled & recurring jobs (Kubernetes CronJob + Temporal Schedule), kubectl day-2 operations, and modernization strategies. Use them to align new projects with established patterns, audit existing services, or onboard engineers to modern Python, Node, and React development practices.
 
 > **Where these live in this repo:** the skill folders are under [`skills/`](../../skills/) (auto-discovered by the claude-kit plugin). The links below point there.
 
@@ -48,6 +48,7 @@ These forty-seven Claude Code skills encode production-proven engineering conven
 | **tanstack-react-query-patterns** | TanStack Query (React Query) — query-key factories, typed hooks, staleTime + placeholderData pagination, invalidation, optimistic `onMutate`, computed selectors | [SKILL.md](../../skills/tanstack-react-query-patterns/SKILL.md) |
 | **react-hook-form-zod-patterns** | Type-safe forms — `useForm` + `zodResolver`, `z.object().strict()` + inferred types, multi-step forms, create/edit modes, schema-driven vs manual validation | [SKILL.md](../../skills/react-hook-form-zod-patterns/SKILL.md) |
 | **radix-tailwind-component-patterns** | Design-system components — Radix headless primitives + custom styling, Tailwind v4 `@theme` tokens, variant-driven API, `cn()` (twMerge+clsx), asChild/Slot, reduced-motion | [SKILL.md](../../skills/radix-tailwind-component-patterns/SKILL.md) |
+| **design-system-ops** | Operate a design system *over time* (the work after components are built) — three-tier token architecture (primitive→semantic→component), seven-dimension health & five maturity stages, drift detection (visual/behavioural/API/token), governance & adoption measurement, AI-readiness & Component Challenge Rating. Stack-agnostic; complements `radix-tailwind-component-patterns` (build) and `ui-ux-design` (per-feature) | [SKILL.md](../../skills/design-system-ops/SKILL.md) |
 | **vitest-rtl-msw-patterns** | Frontend testing — Vitest + React Testing Library + MSW v2 mocking, Zod↔Pydantic contract tests with generated fixtures, jsdom setup | [SKILL.md](../../skills/vitest-rtl-msw-patterns/SKILL.md) |
 | **zap-vapt-scanning** | Automated OWASP ZAP VAPT/DAST — a bundled single-file `zap_vapt.py` that launches ZAP headless, replays endpoints (curl / simple lines / Postman collection), passive- (and gated active-) scans, joins alerts to endpoints, and renders a branded PDF VAPT report whose company/location/logo/sign-off identity is supplied at run time (never hardcoded); `--selftest` self-checks the logic with no ZAP | [SKILL.md](../../skills/zap-vapt-scanning/SKILL.md) |
 | **shannon-ai-pentest** | Drive Shannon (by Keygraph) — an autonomous **white-box** AI pentest that reads an app's source, plans attacks, runs **real proof-of-concept exploits** against the live app, and reports only proven findings. Documents the external **AGPL-3.0** `npx @keygraph/shannon` CLI (setup/start/status/logs/stop/workspaces + flags), AI-provider & model-tier config (Anthropic/Bedrock/Vertex/proxy), the YAML engagement config (auth + login-flows + TOTP, scope avoid/focus rules, report filters), output layout, and safety. Not bundled — installed separately (complements `zap-vapt-scanning`) | [SKILL.md](../../skills/shannon-ai-pentest/SKILL.md) |
@@ -101,6 +102,7 @@ These forty-seven Claude Code skills encode production-proven engineering conven
    - "React Query / TanStack Query data fetching" → **tanstack-react-query-patterns**
    - "react-hook-form + Zod forms" → **react-hook-form-zod-patterns**
    - "Radix + Tailwind component / design system" → **radix-tailwind-component-patterns**
+   - "audit / govern / measure a design system *over time* — token architecture, drift, system health & maturity, adoption, AI-readiness" → **design-system-ops**
    - "Vitest + RTL + MSW tests / contract tests" → **vitest-rtl-msw-patterns**
    - "run a ZAP scan / VAPT / DAST / security-test an API / scan a Postman collection for vulnerabilities / generate a penetration-test report" → **zap-vapt-scanning**
    - "run Shannon / autonomous or white-box AI pentest / exploit-test an app from its source / set up @keygraph/shannon / proof-by-exploitation report" → **shannon-ai-pentest**

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/pyproject.toml

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

@@ -101,6 +101,35 @@ agent on a broken foundation.* Before worrying about prompt injection, enforce t
 > threats (goal/instruction hijacking, tool misuse, identity/privilege abuse, supply-chain, etc.).
 > Source for this section: "From Clawdbot to OpenClaw — practical lessons in building secure agents."
 
+## 5. Operation authorization — every action traces to an authorizing identity
+
+Least privilege (§3) limits *which tools* an agent holds; this layer governs *on whose authority* each
+action runs, and proves it afterward. An autonomous agent acting "as itself" with broad standing
+credentials is the agentic equivalent of a shared root account — when something goes wrong there is no
+one to trace it to.
+
+- **Carry the delegation chain.** An action should be attributable across **user → agent → operation**:
+  the human (or upstream system) the agent acts for, the agent identity, and the specific operation.
+  Don't collapse this into one all-powerful service identity; preserve who authorized what.
+- **Scope credentials per request, not per agent lifetime.** Prefer short-lived, operation-scoped
+  credentials minted for a task over a long-lived key the agent holds for everything. A misused
+  per-request credential has a small blast radius; a standing one does not (reinforces §4's
+  "no plaintext credentials").
+- **Keep a verifiable audit trail.** Record what was done, on whose behalf, and under what
+  authorization, in a form that can be checked later — not a log line the agent could have fabricated
+  (ties to §2's truthful-status rule). Destructive/outward-facing actions (§3,
+  `.claude/rules/human-in-the-loop.md`) especially must leave a trail.
+- **Authorization policy is data, updatable without a redeploy.** What an agent may do should be a
+  policy you can tighten at runtime — revoke a capability, narrow a scope — the moment a risk appears,
+  not a constant baked into the agent. The active `.claude/rules/autonomy-levels.md` tier and
+  `.claude/rules/risk-classification.md` are such runtime controls.
+
+> Stack-agnostic adaptation of the delegated-authorization model in the Apache-2.0
+> [`alibaba/open-agent-auth`](https://github.com/alibaba/open-agent-auth) (user→workload→operation
+> token chain, per-request isolation, verifiable-credential audit, runtime-updatable authz policy;
+> built on IETF / W3C-VC drafts). Re-derived in prose; not vendored — product/protocol names stay out
+> of this core rule.
+
 ## Rules
 
 1. **Layered, not single-point.** Input validation *and* output validation *and* least privilege *and*
@@ -110,6 +139,9 @@ agent on a broken foundation.* Before worrying about prompt injection, enforce t
    progress) — do not quietly comply or quietly drop it.
 3. **Guardrails evolve.** New manipulation patterns get promoted to `agent-memory/` via `remember` so
    future sessions recognize them.
+4. **Every action traces to an authorizing identity.** Run on a delegated user→agent→operation
+   authority with per-request, revocable scope and a verifiable trail — never as a standing
+   all-powerful identity (§5).
 
 ## Relationship to other rules
 
@@ -117,3 +149,5 @@ agent on a broken foundation.* Before worrying about prompt injection, enforce t
 - **`.claude/rules/agent-resilience.md`** — malformed/hostile input often coincides with failures;
   the two rules are applied together.
 - **`.claude/rules/quality-gates.md`** — product-security severity & the secret = auto-Critical rule.
+- **`.claude/rules/autonomy-levels.md`** / **`risk-classification.md`** — the runtime controls that
+  tighten or revoke operation authorization (§5).

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/rules/evals.md

@@ -76,6 +76,30 @@ honest:
 > which gate caught each defect), the claude-kit repo ships a fill-in template — `docs/eval-harness.md`
 > — that builds the with/without comparison on top of this section's median-of-N method.
 
+## 7. Stage the eval: sequential gates, leak-resistant, objectively anchored
+
+When the thing under eval is generated code (or any artifact with a hard correctness floor), structure
+the eval as **ordered gates where each must pass before the next is even measured**, and isolate
+generation from grading so the model can't see what it's graded against.
+
+- **Sequential gating.** Run the cheap, decisive checks first and let each gate the next: does it
+  **build/compile** → does it produce the **correct result** → only then, how **efficient** is it. A
+  solution that fails an earlier gate scores zero on the later ones — you never report a performance
+  number for output that doesn't run. This stops early (saves cost) and kills the classic false win of
+  optimizing an answer that was never correct (mirrors §6's "a measurement is not a gate").
+- **Leak-resistant separation.** The model must not be able to read what it is graded against. Keep
+  generation and grading in **separate sessions / working directories**, and **strip** expected
+  outputs, reference solutions, baselines, and grader source from anything the model can see before it
+  generates. An eval the model can read the answer to measures retrieval, not capability.
+- **Anchor to an objective baseline, not self-assessment.** Score against an **external, pre-computed
+  reference** — a known-good output, a measured baseline, or a theoretical limit (e.g. a
+  roofline/speed-of-light bound) — rather than letting the model grade its own work. Cache the baseline
+  so the comparison is stable run-to-run (the same stability §6's median-of-N gives the score).
+
+> Stack-agnostic adaptation of the staged-evaluator pattern in the Apache-2.0
+> [`alibaba/atrex-bench`](https://github.com/alibaba/atrex-bench) (compile→correctness→performance
+> gating, generate/eval session isolation, cached roofline baselines). Re-derived in prose; not vendored.
+
 ## Rules
 
 1. **No prompt/rule/tool/model change ships without an eval run** that covers the affected behavior.

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/rules/goal-setting-and-monitoring.md

@@ -59,6 +59,31 @@ answer that reshapes scope. The order chosen at the start is a hypothesis, not a
 proceeds (and the `planning-and-task-breakdown`, `triage`, and `sprint` skills apply the same criteria
 at backlog/sprint scope).
 
+## 4. Instrument the run so monitoring is measured, not guessed
+
+§2 says *track, don't assume*. The cheapest way to track an agent honestly is to **emit telemetry from
+the run itself** instead of reconstructing it after the fact. Model the run as a **span tree** —
+`session → turn → tool call / model call` — and record each node:
+
+- **Hang the spans off events you already have.** The host's hooks (prompt-submit, pre/post tool use,
+  sub-agent start/stop, stop, pre-compact) are natural span boundaries — you get the hierarchy without
+  instrumenting business logic. claude-kit's own `hooks/` and its orchestrator/sub-agent structure map
+  directly onto this tree.
+- **Record the attributes that make a run debuggable:** which tool/model, token cost, latency, and
+  outcome per node — the same signals §2 monitors and `.claude/rules/quality-gates.md` trends. Capture
+  model token usage where the call happens, not by estimating later.
+- **Use a stable attribute vocabulary** (a documented convention — e.g. the emerging GenAI semantic
+  conventions) so runs stay comparable across sessions and tools, the way `.claude/rules/evals.md`
+  needs N-comparable numbers.
+
+This turns "I think the run is progressing" into a measured session you can grade
+(`.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.)
+
+> 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.
+
 ## Rules
 
 1. **No work without a checkable goal.** Even a fast-track fix states what "fixed" means and how it's

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/rules/tool-design.md

@@ -78,6 +78,35 @@ spend each only where it returns value.
   needs. Density, not coldness — and never at the cost of truthful status
   (`.claude/rules/agent-guardrails.md` §2).
 
+## 8. Design the tool *set* for orchestration, not just each tool in isolation
+
+§1–§7 make one tool good; this makes a *collection* usable by an agent that must chain them toward a
+multi-step goal. The set needs four properties:
+
+- **Discoverable from a registry.** Expose the available tools (name + one-line contract, per §2–§3) as
+  something the agent can enumerate and select from, rather than a hard-coded call order. New tools
+  become usable without rewriting the caller.
+- **Plan before execute.** For a multi-step goal, let the agent sequence the calls it intends *first*,
+  then run them — not improvise one call at a time. A visible plan is reviewable and surfaces which
+  steps are independent (next bullet). (Mirrors `.claude/rules/reasoning-techniques.md`.)
+- **Run independent calls concurrently; order only the dependent ones.** Tools with no data dependency
+  fan out in parallel; chain only where one output feeds the next — within §7's Brooks's-law caution
+  (concurrency has coordination cost).
+- **Persist workflow state across turns/steps.** A flow that spans turns or agents needs durable state
+  (what's done, what's pending, intermediate results) so it survives a compaction or handoff — the role
+  `.claude/rules/continuity.md` plays for the session.
+
+**Write that state atomically.** When a tool or hook persists state to a file another process (a
+parallel agent, a concurrent hook) may read or write, **write to a temp file and rename into place** —
+a rename is atomic, a half-written direct write is not. Concurrent hooks/agents racing on a shared
+state file is a real failure mode; tmp-write-then-rename removes it.
+
+> Orchestration mechanics adapted (stack-agnostic) from the Apache-2.0
+> [`alibaba/app-controller`](https://github.com/alibaba/app-controller) (registry-based tool discovery,
+> plan-then-execute, concurrent calls, persisted task flows); the atomic state-write rationale from the
+> Apache-2.0 [`alibaba/loongsuite-js`](https://github.com/alibaba/loongsuite-js) hook instrumentation.
+> Re-derived in prose; not vendored.
+
 ## Rules
 
 1. **Design for the agent, not a human dashboard** — text-first, token-aware, self-describing.
@@ -87,11 +116,15 @@ spend each only where it returns value.
 4. **Eval your tools too** — a tool's effect on agent success is measurable; see `.claude/rules/evals.md`.
 5. **Spend in proportion to value** — agents, sourcing calls, and output length are finite context;
    over-dispatching and over-sourcing burn budget without returning it (§7).
+6. **Design the tool *set* for orchestration** — discoverable registry, plan-before-execute, concurrent
+   independent calls, durable cross-turn state written atomically (tmp-write-then-rename) (§8).
 
 ## Relationship to other rules
 
 - **`.claude/rules/agent-guardrails.md`** — tools as privilege boundary; least privilege; gating.
-- **`.claude/rules/mandatory-workflow.md`** — the parallel-lane model that §7's Brooks's-law caution applies to.
+- **`.claude/rules/mandatory-workflow.md`** — the parallel-lane model that §7's Brooks's-law caution
+  applies to, and the durable cross-turn state §8 calls for.
+- **`.claude/rules/continuity.md`** — durable workflow state across turns/handoffs (§8).
 - **`.claude/rules/reasoning-techniques.md`** / **`model-tiers.md`** — tool use is part of how an agent reasons.
 - **`.claude/rules/evals.md`** — measure whether a tool change actually helps.
 - **`catalog/mcp.yaml`** (kit authors) — where MCP servers are declared and wired into a project.

{claude_code_kit-0.45.0 → claude_code_kit-0.47.0}/skills/debugging-and-error-recovery/SKILL.md

@@ -72,6 +72,50 @@ Cannot reproduce on demand:
     └── Document the conditions observed and revisit when it recurs
 ```
 
+**When you can't reproduce locally *and* can't restart — attach to the running process:**
+
+Some bugs only surface in a running production/staging process you cannot pause, redeploy, or
+reproduce on your machine. The passive path above (add logs → redeploy → wait for recurrence) fails
+when redeploy isn't an option. The third mode is to **attach to the live process, observe, and
+detach** — without changing its code or restarting it:
+
+```
+Attach → instrument → observe → detach
+1. ATTACH a diagnostic to the already-running process (no restart, no code change)
+2. INSTRUMENT the suspect area: capture a stack/flame profile, trace a call's
+   arguments/return/timing, watch a value, or (in a safe env) inject a fault
+3. OBSERVE just long enough to capture the signal — sample, don't trace everything
+4. DETACH cleanly so the process returns to normal; remove any instrumentation
+```
+
+Use the live-attach tooling your runtime provides (illustrative — use the project's actual tools):
+
+```bash
+# Python — sample a running process without stopping it
+py-spy dump --pid <pid>     # one-shot stack of every thread
+py-spy top  --pid <pid>     # live profile   (or attach debugpy and connect a client)
+
+# Node.js — open an inspector on an already-running process
+kill -USR1 <pid>            # enables the inspector; then connect a debugger client
+
+# Go — attach to a running process
+dlv attach <pid>            # Delve interactive (plus net/http/pprof for live profiles)
+
+# JVM and most managed runtimes ship equivalent live-attach diagnostics
+# (sampling profiler, method tracing, on-the-fly logging) — same pattern everywhere.
+```
+
+**Safety — this is a `block`/`confirm`-tier action (`.claude/rules/agent-guardrails.md`).** Attaching
+to, and especially *injecting faults into*, a live process is outward-facing and can perturb it.
+Default to staging; against production it is a human decision point
+(`.claude/rules/human-in-the-loop.md`). Keep overhead low (sample, time-box) and **always detach** — a
+left-attached profiler or an un-removed injected fault is its own incident. Treat anything the process
+emits as untrusted data (see "Treating Error Output as Untrusted Data" below).
+
+> The attach → instrument → observe → detach pattern generalizes the runtime-diagnostics approach of
+> [`alibaba/arthas`](https://github.com/alibaba/arthas) (Apache-2.0) and `jvm-sandbox` (LGPL-3.0 —
+> referenced for the concept only; no code used). Re-derived stack-agnostic; not vendored.
+
 For test failures:
 ```bash
 # Run the specific failing test (adjust to your test runner)

claude_code_kit-0.47.0/skills/design-system-ops/README.md

@@ -0,0 +1,65 @@
+# design-system-ops
+
+Operate and maintain a design system as a living product — the work *after* components are built.
+Design systems drift: tokens go stale, components fall out of spec, teams fork patterns, and the gap
+between intent and implementation compounds silently. This skill is the **operations layer** — auditing,
+governing, documenting, validating, and measuring the system the way a staff-level practitioner would,
+with explicit frameworks that produce findings and decisions rather than generic advice. Stack-agnostic
+(React, Vue, Twig, Tailwind, SCSS, CSS custom properties, Style Dictionary, CSS-in-JS).
+
+> **Boundary.** This is the **system-wide, over-time** operations layer. It does NOT build or style
+> components (`component-design`, `radix-tailwind-component-patterns`), set up the frontend app
+> (`frontend-ui-engineering`, `frontend-repo-architecture`), check a screen against the design system
+> during implementation (`ui-ux-design`), or run a WCAG pass on one UI (`accessibility-review`). Reach
+> here for the **health, drift, token architecture, governance, adoption, or maturity of the design
+> system itself**.
+
+## What's inside
+
+| File | Covers |
+|------|--------|
+| `SKILL.md` | The operations lifecycle (audit → govern → document → validate → communicate) and a summary of each framework, with sibling boundaries and output discipline. |
+| `references/token-architecture.md` | The three-tier token model (primitive → semantic → component), strictly-downward reference rules, naming conventions, DTCG 2025.10 alignment, and cross-platform handling. |
+| `references/system-health-and-maturity.md` | The seven health dimensions, library-type classification (design system / component / pattern library / utility collection), the five maturity stages, and how to grade and calibrate. |
+| `references/drift-detection.md` | The four drift kinds (visual / behavioural / API / token), the A/C/E classification, styling-specific token-drift detection, severity, and trend tracking. |
+| `references/governance-and-adoption.md` | Deprecation, decision records, contribution + change communication, and the adoption model (coverage ≠ adoption, four signals, leading/lagging, per-team). |
+| `references/ai-readiness.md` | The context cascade, the three pillars (coverage / context / validation), the six dimensions of component AI-readiness, and the Component Challenge Rating calibration. |
+
+## Provenance
+
+Frameworks re-derived stack-agnostic (not vendored) from the MIT-licensed
+[`murphytrueman/design-system-ops`](https://github.com/murphytrueman/design-system-ops) (© 2026 Murphy
+Trueman; designsystemops.com) — a 41-skill pack for Claude Code. This condenses its highest-leverage
+*operations* frameworks (the `knowledge-notes/` on token architecture, AI-readiness, adoption
+measurement, and the Component Bestiary, plus the `system-health` and `drift-detection` skills) into a
+single skill, re-expressed in this kit's idiom with attribution. DTCG references the Design Tokens
+Community Group 2025.10 specification. When the upstream pack and this skill disagree, trust upstream.
+
+## When to use
+
+- "How healthy is my design system?" / "audit my tokens" / "where has the system drifted?"
+- Inheriting a design system, running a quarterly review, or making the investment case for one.
+- Giving tokens a real architecture (primitives vs semantics vs component tokens) or migrating to DTCG.
+- Deprecating a token or component, or recording a consequential design-system decision.
+- Diagnosing adoption — teams may be re-implementing instead of consuming the library.
+- Making the system **AI-ready** so agents use it correctly instead of hallucinating its API.
+
+## Boundary vs siblings
+
+| Skill | Owns | Scope |
+|-------|------|-------|
+| **design-system-ops** (this) | Drift, token architecture, system health & maturity, governance, adoption, AI-readiness | System-wide, over time |
+| **ui-ux-design** | Verifying a screen/feature against the design system during implementation | Per-feature, build-time |
+| **component-design** · **radix-tailwind-component-patterns** | Building and styling components (incl. Tailwind `@theme` tokens) | Per-component, build-time |
+| **accessibility-review** | WCAG review of a UI | Per-UI |
+| **frontend-ui-engineering** · **frontend-repo-architecture** | Building the frontend app | App |
+
+design-system-ops sits **above** the build-time skills: they ship one feature to spec; this one keeps
+the spec — the tokens, the inventory, the contracts — healthy across teams and over time.
+
+## Related
+
+- **Build-time siblings:** `ui-ux-design`, `component-design`, `radix-tailwind-component-patterns`, `accessibility-review`, `frontend-ui-engineering`.
+- **Decision records:** `documentation-and-adrs` — the home for the records this skill calls for.
+- **Rule:** `.claude/rules/documentation.md` — the documentation standard design-system docs must meet.
+- **Deep dive:** `SKILL.md` and the five `references/` files above.