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

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

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

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

@@ -4,6 +4,36 @@ 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.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.46.0}/PKG-INFO

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

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "claude-code-kit"
-version = "0.45.0"
+version = "0.46.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.46.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.

claude_code_kit-0.46.0/skills/design-system-ops/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: design-system-ops
+description: >-
+  Operate and maintain a design system as a living product over time — the work AFTER components are
+  built. Use for design-system drift detection (tokens/components decaying out of spec), three-tier
+  token architecture governance (primitive → semantic → component, DTCG-aligned), system-health and
+  maturity assessment (library-type classification, maturity stages, AI-readiness), adoption
+  measurement (coverage ≠ adoption), and the governance lifecycle (deprecation, decision records,
+  change communication). Stack-agnostic (React/Vue/Twig/Tailwind/SCSS/CSS vars/Style Dictionary). Do
+  NOT use to BUILD or style components or check per-screen design compliance (use component-design /
+  radix-tailwind-component-patterns / ui-ux-design / frontend-ui-engineering), nor for WCAG review of a
+  single UI (use accessibility-review) — this is the system-wide, over-time operations layer above them.
+---
+
+# Design System Ops
+
+Building a design system is the easy part; keeping it alive is the work. Used 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, and measuring a design system as a living product, the way a staff-level practitioner
+would — with explicit frameworks that produce findings and decisions, not generic advice.
+
+> 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). The original is a 41-skill pack for Claude Code; this is a single
+> condensed skill carrying its highest-leverage operations frameworks.
+
+> **Sibling boundary.** This skill is the **over-time, system-wide operations** layer. It does NOT
+> build or style components (that is `component-design` and `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 when the question is about the **health, drift, governance,
+> token architecture, adoption, or maturity of the design system itself** — not about shipping one
+> feature.
+
+## When to use
+
+- "How healthy is my design system?" / "audit my tokens" / "where has the system drifted?"
+- A design system is being inherited, reviewed quarterly, or pitched for investment.
+- Tokens need a real architecture (primitives vs semantics vs component tokens) or a DTCG migration.
+- A component or token must be **deprecated**, or a consequential design-system decision recorded.
+- Adoption is unclear — teams may be re-implementing instead of consuming the library.
+- The design system needs to become **AI-ready** (machine-readable enough that agents use it correctly).
+
+## The operations lifecycle
+
+Design-system ops is a repeating loop, not a one-off. Each stage routes to a framework below.
+
+```
+AUDIT      → token-audit · component-audit · drift-detection · system-health   (what is the state?)
+GOVERN     → deprecation · decision records · contribution · change communication (control change)
+DOCUMENT   → usage guidelines · AI-component descriptions · token docs          (make intent explicit)
+VALIDATE   → design-to-code · token compliance · accessibility-per-component    (enforce the contract)
+COMMUNICATE→ adoption report · stakeholder brief · onboarding                   (close the loop)
+```
+
+Always **calibrate to the system's maturity and type** (see `references/system-health-and-maturity.md`):
+a pattern library is not a design system with gaps, and an ad-hoc system should not be judged for
+lacking platform-grade governance. Findings are framed "appropriate / below expectations for this
+stage," never against an absolute scale.
+
+## Core frameworks
+
+### Three-tier token architecture
+
+Tokens are structured in tiers, each with a distinct job; references flow **strictly downward**.
+
+- **Primitives** — raw values, the source of truth. Name by *what they are*: `color.blue.500`,
+  `spacing.4`. Never `color.primary`.
+- **Semantic** — encode *intent*; reference primitives. Name by function/role: `color.action.primary`,
+  `color.feedback.error`. This is the tier theming swaps at. A semantic token named for appearance
+  (`color.semantic.blue`) has failed.
+- **Component** *(optional, only when justified)* — scope semantic intent to a component context:
+  `button.background.default → color.action.primary`. Use for white-labelling, divergent components,
+  or large complex components; most mature systems run on primitives + semantics alone.
+
+The most damaging violation is a **cross-tier reference at the wrong level** —
+`button.background.default: {color.blue.500}` looks fine but breaks the semantic contract, so a rebrand
+or theme change never reaches it. Align to **DTCG 2025.10** (`$type`, resolvers, sets, composite-token
+sub-value validation). Full model, naming rules, and cross-platform handling:
+`references/token-architecture.md`.
+
+### System health & maturity
+
+A holistic, findings-based assessment across **seven dimensions** — tokens, components, documentation,
+adoption, governance, AI-readiness, platform maturity — not a deep dive into one. First **classify the
+library type** (design system / component library / pattern library / utility collection) from
+codebase signals, *not* the README, then **baseline the maturity stage** (ad-hoc → managed →
+systematic → measured → optimised) and grade each dimension Strong / Functional / Weak relative to that
+stage. See `references/system-health-and-maturity.md`.
+
+### Drift detection
+
+Drift is the **normal condition** of a used system; the question is whether it is intentional,
+how severe, and whether it is compounding. Detect across four kinds — **visual, behavioural, API,
+token** — then **classify each instance** (intentional divergence → maybe a contribution; accidental
+re-implementation → correct + fix root cause; system gap → the system is missing something). Token
+drift detection is styling-specific (raw values outside `var()`, SCSS literals, Tailwind arbitrary
+brackets `bg-[#ff0000]`, raw values outside a CSS-in-JS theme). See `references/drift-detection.md`.
+
+### Adoption (coverage ≠ adoption)
+
+Coverage = does the system provide what teams need; adoption = do teams actually use it. A system can
+have 100% coverage and 20% adoption. Measure four signals — installation, component consumption, token
+compliance, pattern adherence — split **leading vs lagging** indicators, and always break down
+**per-team** (a healthy system-wide average hides struggling teams). See
+`references/governance-and-adoption.md`.
+
+### Governance lifecycle
+
+Deprecation with a migration path and timeline; **decision records** for consequential token/component
+choices (route to `documentation-and-adrs` for the ADR itself); contribution workflow; and change
+communication sized to blast radius. The governance frameworks live in
+`references/governance-and-adoption.md`.
+
+### AI-readiness & Component Challenge Rating
+
+An AI-ready system can be consumed and generated-from by agents without implicit knowledge. It rests on
+three pillars — **coverage, context, validation** — and component descriptions that let an agent pick,
+configure, and use a component correctly. Calibrate documentation/audit depth by **Component Challenge
+Rating** (CR): a date picker or data table (CR 7+) needs a mandatory a11y audit + decision record + full
+anti-pattern coverage; a badge (CR 1–2) needs little. See `references/ai-readiness.md`.
+
+## Output discipline
+
+- Produce **findings, not advice** — each finding names the artefact, the problem, a severity, and a
+  recommended response; end with a prioritised action list.
+- **Calibrate to maturity and library type** (above) — never project a platform-grade roadmap onto a
+  utility collection.
+- Distinguish **measured from estimated** — if you assessed by interview rather than inspection, say
+  so and flag what needs direct verification.
+- For recurring assessments, report the **trend** (improved / steady / regressed) against the prior run,
+  not just the current snapshot.
+- A consequential decision becomes a **decision record** (`documentation-and-adrs`), not a buried note.
+
+## References
+
+- `references/token-architecture.md` — the three-tier model, 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, the five maturity stages, and how to grade/calibrate.
+- `references/drift-detection.md` — the four drift kinds, the classification scheme, styling-specific token-drift detection, severity, and trend tracking.
+- `references/governance-and-adoption.md` — deprecation, decision records, contribution + change communication, and the adoption-measurement model (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 from the MIT-licensed
+[`murphytrueman/design-system-ops`](https://github.com/murphytrueman/design-system-ops) (© 2026 Murphy
+Trueman; designsystemops.com) — its `knowledge-notes/` (token architecture, AI-readiness, adoption
+measurement, the Component Bestiary reference) and the `system-health` / `drift-detection` skills.
+DTCG references the Design Tokens Community Group 2025.10 specification. Nothing vendored; concepts are
+re-expressed in this kit's idiom with attribution. When the upstream pack and this skill disagree,
+trust upstream — it is the deeper, actively-maintained source.
+
+## Related
+
+- `ui-ux-design` — build-time design-system **compliance** of a screen/feature (this skill is the system-wide, over-time counterpart).
+- `component-design` · `radix-tailwind-component-patterns` — **building/styling** components (incl. Tailwind `@theme` tokens); this skill governs the token *architecture* and component *inventory* above them.
+- `accessibility-review` — WCAG review of a UI; design-system-ops sequences a11y work by Component Challenge Rating and tracks it per-component across the system.
+- `frontend-ui-engineering` · `frontend-repo-architecture` — building the frontend app the design system serves.
+- `documentation-and-adrs` — the home for the decision records this skill calls for.
+- `.claude/rules/documentation.md` — the kit's documentation standard that design-system docs must meet.

claude_code_kit-0.46.0/skills/design-system-ops/references/ai-readiness.md

@@ -0,0 +1,81 @@
+# AI-readiness & Component Challenge Rating
+
+The reference behind the **AI-readiness** framework in `design-system-ops`. Re-derived stack-agnostic
+from the MIT `murphytrueman/design-system-ops` `ai-readiness` and `component-bestiary-reference`
+knowledge notes.
+
+## What AI-readiness means
+
+An AI-ready design system can be consumed, reasoned about, and generated from by agents **without
+requiring implicit knowledge that was never written down**. Most systems are built for humans —
+designers infer intent from context, developers ask a colleague. Agents cannot infer, ask, or defer;
+they work only with what is explicit. "Use this to show important information" gives an agent no basis
+to know what "important" means, which components carry that role, or how this differs from three others
+that also "show information." The gap AI exposes is not new — the same implicit knowledge has always
+confused new hires and external contributors. **AI-readiness is design-systems quality applied with
+more precision.**
+
+## The context cascade
+
+Context quality at the source compounds through every downstream consumer. Strong metadata in a
+component → accurate AI-generated code → correct implementation → reliable tests. Weak metadata →
+hallucinated props → broken implementation → failing tests. There is no neutral handoff — each layer
+inherits good context or amplifies bad. So invest at the **source** (design specs, component
+descriptions, token docs): every hour making a description explicit saves multiples downstream in
+reduced misuse, fewer support requests, and better generated output.
+
+## The three pillars
+
+An agent-ready system needs all three working together:
+
+- **Coverage** — every interactive state documented (not just the happy path), every prop with type +
+  default + intent, every edge case (long strings, empty states, max density, RTL). Coverage is the raw
+  material; a component with five documented states produces reliable AI output, one with only its
+  default does not.
+- **Context** — coverage made *machine-consumable*: structured metadata alongside prose, consistent
+  section formats an agent can locate and parse, and explicit relationships ("can contain," "contained
+  in," "alternative to" — not a vague "related to"). Context is what turns a reference library into
+  infrastructure agents can reason about.
+- **Validation** — automated checks (prop-type, accessibility, token compliance) plus human sign-off
+  gates that confirm agent-generated UI is correct and safe to ship. Coverage provides the material,
+  context makes it consumable, validation closes the loop.
+
+## The six dimensions of component AI-readiness
+
+A component is AI-ready when an LLM reading only its description can:
+
+1. **Identify** the correct component for a requirement (distinguished from similar ones).
+2. **Configure** it correctly (props with types, defaults, intent).
+3. **Avoid** the common misuse patterns (anti-patterns specific to *this* component, not generic).
+4. **Place** it correctly (composition rules: what it can contain, what can contain it).
+5. **Apply it accessibly** without extra guidance (role, keyboard, focus documented at the component
+   level — not a pointer to WCAG).
+6. **Generate** correct usage examples that match real-world usage.
+
+Weak descriptions fail these in order; an audit of AI-readiness checks each.
+
+## Component Challenge Rating (CR)
+
+Borrowed from the Component Bestiary (thecomponentbestiary.com), which rates components by
+**implementation danger**, not visual complexity. CR calibrates how much documentation, anti-pattern
+coverage, and accessibility rigour a component warrants — the cost of an agent getting a modal wrong far
+exceeds getting a badge wrong.
+
+| CR | Danger | Examples | Documentation / validation bar |
+|----|--------|----------|--------------------------------|
+| **1–2** | Low | text, dividers, badges, avatars, skeletons | Light: usage guidelines, basic anti-patterns, standard a11y notes |
+| **3–4** | Moderate | buttons (variant misuse), inputs (labelling), tooltips, cards | Full anti-patterns with consequences; edge cases; a11y explicitly tested |
+| **5–6** | Significant | modals/dialogs (focus trap), select/combobox (keyboard), nav (landmarks, current state) | Full anti-pattern + explicit composition constraints; thorough AI description |
+| **7+** | High | date pickers, data tables, rich text editors, drag-and-drop | **Mandatory a11y audit before release**, a decision record, failure-mode docs, post-release misuse monitoring |
+
+**Use CR to sequence work:** audit and document high-CR components first; they carry the most
+accessibility and misuse risk. This is not licence to skip low-CR components — it is about investing
+*more time per component* at the high-CR end.
+
+## Related references
+
+- `system-health-and-maturity.md` — AI-readiness is one of the seven health dimensions.
+- `governance-and-adoption.md` — high-CR components carry a higher contribution/release bar; decision records for CR 7+.
+- `drift-detection.md` — weak machine-readable context is a leading cause of accidental re-implementation.
+- `token-architecture.md` — token documentation is part of machine-readable context.
+- Skill overview: `../SKILL.md`. Per-component WCAG review is `accessibility-review`; CR tells you which components to send there first.

claude_code_kit-0.46.0/skills/design-system-ops/references/drift-detection.md

@@ -0,0 +1,86 @@
+# Drift detection
+
+The reference behind the **drift-detection** framework in `design-system-ops`. Re-derived stack-agnostic
+from the MIT `murphytrueman/design-system-ops` `drift-detection` skill.
+
+Drift is the **normal condition** of a used design system — the accumulated distance between intent and
+actual implementation across consuming products. The question is never *whether* the system has drifted
+(it has) but whether the drift is **intentional**, how **severe**, and whether it is **compounding**.
+Not all drift is bad: a documented, deliberate exception is a design decision; an unknowing
+re-implementation with slightly different spacing is maintenance debt. The response differs, so every
+finding must be classified before it gets a recommendation.
+
+## Step 1 — Scope and reference point
+
+Scope tightly: a specific product, component set, or token scope produces a far more actionable report
+than "the whole system." Then fix the **source of truth** drift is measured against — the Figma library,
+the published package at a version, or the documented spec. If there is no single source of truth, that
+is itself the top finding.
+
+## Step 2 — Detect across four kinds of drift
+
+### Visual drift
+Differences in visual treatment vs the reference — spacing, colour (especially non-token values),
+typography, radius, shadow, icon usage. Note whether each looks intentional or accidental.
+
+### Behavioural drift
+Differences in interactive behaviour — state transitions, animation, timing, keyboard behaviour, focus
+management. Hardest to detect without testing, highest risk because it includes **accessibility
+regressions**.
+
+### API drift
+Components implemented with different props, prop names, or prop semantics than the published API —
+common when a team built a local version before the system component existed and never migrated.
+
+### Token drift
+Raw values where tokens belong; tokens referenced at the wrong tier; local overrides conflicting with
+semantic intent; inconsistent token names. Detection is **styling-specific**:
+
+| Styling | Look for |
+|---------|----------|
+| CSS custom properties | raw values outside `var()` |
+| SCSS | raw literals not using `$` variables (tier inferred from naming: `$color-blue-500` → primitive, `$color-action-primary` → semantic) |
+| Tailwind | arbitrary-value brackets (`h-[12px]`, `bg-[#ff0000]`); standard utilities resolving to configured tokens are **not** drift |
+| CSS-in-JS | raw values outside theme-object references |
+
+(See `token-architecture.md` for the tier model token drift is measured against.)
+
+## Step 3 — Classify every instance
+
+Classification drives the response:
+
+- **A — Intentional divergence.** Deliberate, documented exception → candidate to fold back as a
+  contribution, or to formalise as a variant.
+- **C — Accidental drift.** Unknowing re-implementation / local override → correct it **and** address
+  the root cause (often a discoverability or onboarding gap).
+- **E — System gap.** The drift exists because the system is *missing* something teams needed → the
+  fix is a system change (new component/token/pattern), not a correction to the consumer.
+
+(Intentional-but-undocumented and persistent drift escalate in severity — see trend, below.)
+
+## Step 4 — Severity and response
+
+Rate each finding by user impact and compounding risk (accessibility regressions rank highest), give a
+recommended response tied to its classification, and end with a prioritised list. A drift report that
+lists everything at equal weight is not actionable.
+
+## Recurring runs — track the trend
+
+Compare against the previous report: new drift, resolved drift, **persistent** drift (present 2+
+cycles → escalate), and classification shift. Report **drift velocity** (is new drift accumulating
+faster than it is resolved?) and whether the mix is shifting toward system gaps (E) or accidental drift
+(C). A rising share of E means the system is falling behind its consumers' needs.
+
+## Small-system note (fewer than 5 components)
+
+Scope to the full system (no need to sample); drift is more likely intentional (A) or a system gap (E)
+than accidental in small, aligned teams. Simplify the output to a per-component checklist; if nothing
+has drifted, say so and recommend a review cadence.
+
+## Related references
+
+- `token-architecture.md` — the tier model token drift is measured against.
+- `system-health-and-maturity.md` — drift feeds the Components and Tokens health dimensions.
+- `governance-and-adoption.md` — intentional drift may become a contribution; accidental drift signals adoption friction.
+- `ai-readiness.md` — weak machine-readable context is a leading cause of accidental re-implementation.
+- Skill overview: `../SKILL.md`. Checking ONE component against its spec is build-time `ui-ux-design`, not this system-wide sweep.