claude-code-kit 0.7.0__py3-none-any.whl

claude_kit/_payload/skills/refresh-docs/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: refresh-docs
+description: Scan for stale reference docs and update them by reading current source code and data files.
+argument-hint: [--since N | path/to/doc.md]
+disable-model-invocation: true
+---
+
+Refresh stale documentation by scanning source code and updating docs that have fallen behind.
+
+## Arguments
+
+- No args: full scan of all reference and spec docs
+- `--since N`: only check source files changed in the last N commits
+- `path/to/doc.md`: refresh a specific doc file
+
+## Steps
+
+1. **Identify what changed**:
+   - If `$ARGUMENTS` is a file path: skip the scan, just refresh that specific doc.
+   - If `$ARGUMENTS` contains `--since`: run `git diff --name-only HEAD~N` to find changed source files in the last N commits.
+   - Otherwise: compare docs against source files to find stale documentation.
+
+2. **Map changes to docs**: Determine which docs are affected by the changes:
+   - Component changes → `docs/reports/DEVELOPER_HANDOFF.md` (component inventory), `CLAUDE.md` (architecture section)
+   - Data file changes → `docs/reports/DEVELOPER_HANDOFF.md` (data model section)
+   - Route changes → `docs/reports/DEVELOPER_HANDOFF.md` (routing section)
+   - KPI/RAG threshold changes → `docs/reference/AOCT_Apex_CT_RAG_Definitions.md`, `docs/reference/Apex_CT_Metric_Formulas.md`
+   - New pages/features → `docs/specs/USER_JOURNEY.md`
+
+3. **Categorize results**: Group into:
+   - **Existing docs to refresh**: docs that exist but have newer source files
+   - **Missing docs to create**: coverage gaps
+   Present both lists to the user with counts.
+
+4. **Ask the user what to refresh**: Use AskUserQuestion to ask which docs to update.
+
+5. **For each doc to refresh/create**:
+   - **Read the source files** that affect this doc
+   - **Read the existing doc** to understand current structure
+   - **Update the doc** following the existing structure and conventions:
+     - For existing docs: update only the sections affected by source changes
+     - Include file paths with line numbers for key components
+     - Keep the doc concise but comprehensive
+
+6. **Verify**: Run `git diff --stat` to confirm what was changed.
+
+7. **Summarize**: Tell the user what was updated, what was created, and what (if anything) was skipped.
+
+## Key Documentation Files
+
+| Doc | Source Dependencies |
+|-----|-------------------|
+| `CLAUDE.md` | `src/components/ui/`, `src/lib/`, `src/hooks/`, project structure |
+| `docs/reports/DEVELOPER_HANDOFF.md` | All `src/` files |
+| `docs/reference/Apex_CT_Metric_Formulas.md` | `src/data/ragThresholds.ts`, `src/data/kpiRegistry.ts` |
+| `docs/reference/AOCT_Apex_CT_RAG_Definitions.md` | `src/data/ragThresholds.ts`, `src/data/mockControlTower.ts` |
+
+## Guidelines
+
+- **Don't rewrite docs that are only slightly stale.** If the source change was minor (a small bug fix, import reorder), note it but skip the update.
+- **Preserve existing structure.** When updating, match the existing doc's heading structure and level of detail.
+- **Use the Explore agent** to understand source files before writing docs. Don't guess at behavior from file names alone.
+- **Parallelize with Task agents** when refreshing 5+ docs — spawn `frontend-dev` agents to handle batches concurrently.

claude_kit/_payload/skills/remember/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: remember
+description: Capture a durable learning so future sessions reuse it automatically. Use whenever the user corrects Claude, states a preference or rule (UX, code style, architecture, API behavior), shares a hard-won debugging insight, or explicitly says "remember this" / "note this for next time" / "don't make this mistake again". Writes a structured entry into .claude/agent-memory/ and updates the index. Pairs with the SessionStart hook that loads these learnings back into context each session.
+---
+
+# Remember — Durable Learning Capture
+
+Turn a one-off correction or insight into a permanent, reusable learning. This is the **capture** half of the self-improving loop. The **application** half is automatic: the `load-learnings.sh` SessionStart hook injects the index below into context at the start of every session, so anything recorded here is surfaced before future work.
+
+## When to invoke this skill
+
+**This is now automatic.** A `UserPromptSubmit` hook semantically scans every message you send; when it detects a durable learning it injects a `LEARNING DETECTED` note telling Claude to invoke this skill silently. You do not need to type `/remember` — though you still can to force a capture. Invoke proactively whenever any of these happen:
+
+- The user **corrects** something Claude did ("no, buttons should be 44px touch targets", "always validate at the boundary").
+- The user states a **preference or rule** for how work should be done (UX, design, naming, architecture, testing, tone).
+- A **debugging session** uncovered a non-obvious root cause that took real effort to find.
+- An **API / integration quirk** surfaced that isn't visible in the code.
+- The user says "remember this", "note this", "next time…", "don't repeat this", or similar.
+
+Do **not** record:
+- Facts already visible in the codebase or the rules under `.claude/rules/`.
+- Standard framework behavior (look it up instead).
+- Temporary task state (that's what tasks are for).
+- Anything already captured — update the existing entry instead of duplicating.
+
+## How to capture (4 steps)
+
+### 1. Decide the category
+
+Map the learning to one folder under `.claude/agent-memory/`:
+
+| Category | Folder | What goes here |
+|----------|--------|----------------|
+| UX / Design | `ux/` | Interaction rules, design-system preferences, accessibility musts, layout/visual decisions |
+| Architecture | `architecture/` | Why X over Y, structural decisions, module boundaries |
+| Debugging | `debugging/` | Root causes of tricky bugs, non-obvious failure modes |
+| Patterns | `patterns/` | Recurring project-specific patterns and conventions |
+| API & Integration | `api/` | API quirks, auth flows, endpoint behaviors |
+| Performance | `performance/` | Optimization discoveries, bottleneck insights |
+| Gotchas | `gotchas/` | Looks-right-but-isn't traps, common mistakes |
+
+If unsure, pick the closest fit; UX preferences go in `ux/`.
+
+### 2. Check for an existing entry
+
+Read `.claude/agent-memory/MEMORY.md` and skim the relevant category folder. If a similar learning exists, **edit that file** (refine, add nuance, correct it) rather than creating a duplicate.
+
+### 3. Write the learning file
+
+Filename: lowercase kebab-case describing the insight, e.g. `touch-target-min-size.md`, `filter-resets-on-persona-change.md`. Write to `.claude/agent-memory/<category>/<filename>.md` using this format:
+
+```markdown
+---
+title: {short descriptive title}
+category: {category name}
+date: {YYYY-MM-DD}
+trigger: {when this applies — e.g. "designing any UI", "writing an HTTP endpoint"}
+---
+
+## Context
+{What situation produced this learning — keep it brief}
+
+## Learning
+{The rule/insight, stated as a clear, actionable directive Claude can follow next time}
+
+## Evidence
+{How it was discovered — the user's words, an error, debugging steps}
+
+## Apply when
+{Concrete signal that this learning is relevant to the current task}
+```
+
+The `trigger` and `Apply when` fields matter most — they are how a future session knows to pull this learning before acting.
+
+### 4. Update the index
+
+Add a one-line entry to `.claude/agent-memory/MEMORY.md` under the matching `###` section:
+
+```markdown
+- [Title](category/filename.md) — one-line hook | applies when: {trigger}
+```
+
+Keep each index line under ~150 chars. The index is what the SessionStart hook injects, so it must stay scannable.
+
+## After capturing
+
+Confirm to the user in one line what was recorded and where, e.g.:
+> Recorded: "44px minimum touch targets" → `agent-memory/ux/touch-target-min-size.md`. I'll apply it automatically next time I design UI.
+
+## How application works (for reference)
+
+You do not need to do anything to apply learnings — the loop closes on its own:
+
+1. `load-learnings.sh` runs on **SessionStart** and prints the MEMORY.md index into context.
+2. Before doing design/implementation work, open the relevant category file(s) flagged by `Apply when` and follow them.
+3. When you learn something new, this skill records it — and it shows up automatically next session.

claude_kit/_payload/skills/scope/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: scope
+description: Generate a detailed scope document for a backlog item by analyzing the codebase, dependencies, and reference docs.
+argument-hint: [backlog item number]
+disable-model-invocation: true
+---
+
+Scope backlog item #$ARGUMENTS for implementation.
+
+## Steps
+
+1. **Read the backlog entry**: Read `docs/backlog/README.md` to find which horizon file contains item #$ARGUMENTS, then read that horizon file (e.g., `docs/backlog/now.md`) and find the item. Extract the title, priority, status, and full description.
+
+2. **Read the scope template**: Read the [scope template](scope-template.md) to understand the output structure.
+
+3. **Gather context**: Based on what the backlog item describes, read the relevant reference docs:
+   - For domain-specific definitions: read any reference docs in `docs/reference/` that define terminology, metrics, or business rules
+   - For component/UI changes: read `CLAUDE.md` for design system rules and component patterns
+   - For user journey changes: read product specs or user journey documentation
+   - For role/authorization changes: read architecture docs defining roles and permissions
+
+4. **Explore the codebase**: Use the Explore agent to find the actual code that's relevant:
+   - Find existing components, modules, and data files that would be modified
+   - Identify data structures (schemas, models, mock data) that need changes
+   - Find state management (stores, hooks, contexts) that would change
+   - Look for existing patterns to follow in similar modules
+
+5. **Check dependencies**: Look at the execution horizons in `docs/backlog/README.md` to find items that block or are blocked by this one. Check the dependency chain.
+
+6. **Generate the scope doc**: Create a slug from the item title (e.g., "Semantic HTML Landmarks" → "semantic-html"). Write the scope document to `docs/planning/{slug}/scope.md` following the template structure. Fill in:
+   - Problem statement from the backlog entry
+   - Current state from your codebase exploration (with file paths and line references)
+   - Target state with specific, testable outcomes
+   - Component/module changes: specific components/modules to create/modify, with file paths
+   - Data/schema changes: new data structures or modifications to existing ones
+   - Route/endpoint changes: new or modified routes/endpoints
+   - State changes: state management additions or modifications
+   - Wireframes (ASCII) for any new or modified screens (frontend changes)
+   - Dependencies from the backlog
+   - Open questions that need human decision
+
+7. **Summarize**: Tell the user what you wrote, list the open questions that need their input, and suggest they review the scope doc before asking for a sprint plan.
+
+## Guidelines
+
+- Be specific — reference actual file paths, function names, and module names from the codebase
+- Don't be vague ("add a module") — name the module, its interface, and where it integrates
+- Identify the riskiest parts and call them out
+- If the item is too large for a single sprint, suggest how to break it into phases
+- Mark the scope doc status as "Draft"
+- **Frontend wireframes**: If the feature has any frontend impact (new screens, modified screens, new UI components), you MUST include wireframes in the scope doc. Use ASCII wireframes for visual review so the user can validate layout, flow, and information hierarchy before implementation.
+- Adapt to the project's architecture — scope documents should reflect whether the project has a backend/frontend split, is frontend-only, is a CLI tool, is a library, etc.

claude_kit/_payload/skills/scope/scope-template.md

@@ -0,0 +1,82 @@
+# Scope: {Item Title} (Backlog #{N})
+
+> **Status**: Draft | In Review | Approved
+> **Backlog Item**: [#{N} — {Title}](../../docs/backlog/README.md)
+> **Author**: {name}
+> **Date**: {YYYY-MM-DD}
+
+---
+
+## Problem Statement
+
+What problem does this solve? Why now?
+
+## Current State
+
+What exists today that's relevant? Link to reference docs and source files.
+
+## Target State
+
+What does "done" look like? Be specific about user-visible outcomes.
+
+## Component Changes
+
+### New Components
+
+- [ ] {component name} — {file path} — {purpose}
+
+### Modified Components
+
+- [ ] {component name} — {file path} — {what changes}
+
+### Wireframes
+
+> Include ASCII wireframes for any new or modified screens. Show layout, key elements, and user flow.
+
+```
+{wireframe here}
+```
+
+## Data / Mock Data Changes
+
+### New Data Files
+
+- [ ] {file path} — {what data, key interfaces}
+
+### Modified Data Files
+
+- [ ] {file path} — {what changes to existing mock data}
+
+## Route Changes
+
+- [ ] {new or modified routes in src/App.tsx}
+
+## State Changes
+
+- [ ] {Zustand store or hook changes}
+
+## Dependencies & Blockers
+
+| Dependency | Status | Notes |
+|------------|--------|-------|
+| | | |
+
+## Related ADRs
+
+| ADR | Relevance |
+|-----|-----------|
+| [NNNN — Title](../../docs/architecture/decisions/NNNN-slug.md) | {how this ADR relates to the scope} |
+
+## Verification Checklist
+
+Run through after implementation to confirm everything works end-to-end.
+
+| # | Check | How to verify |
+|---|-------|---------------|
+| 1 | TypeScript compiles | `npm run build` |
+| 2 | No lint errors | `npm run lint` |
+| 3 | {what to verify} | {manual step or command} |
+
+## Open Questions
+
+1. {question}

claude_kit/_payload/skills/sdlc/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: sdlc
+description: Run the autonomous SDLC pipeline on a task — the single entrypoint that drives spec → review → build → code review → test → security → delivery through the profile's quality gates. Use when asked to "run the SDLC", build/ship a feature end to end, or take a task through the full pipeline with gates.
+argument-hint: <feature or task description>
+---
+
+# Autonomous SDLC
+
+You are the **entrypoint** to claude-kit's autonomous software development lifecycle. The request to
+handle is:
+
+> $ARGUMENTS
+
+Your job is to **delegate to the `orchestrator` agent** and let it drive the pipeline — you do not
+implement the work yourself here. The orchestrator never writes code; it classifies the work,
+sequences the phases, spawns the specialist agents, and enforces the gates.
+
+## 1. Load the contract
+
+Before doing anything, read:
+
+- `CLAUDE.md` — the project's rules and the exact build/test/lint commands.
+- `.claude/rules/mandatory-workflow.md` — the full phase pipeline and the defect loop.
+- `.claude/rules/quality-gates.md` — the severity model (zero Critical/High/Medium to pass a gate)
+  and the blind-review + Devil's Advocate protocol.
+- `.claude/rules/rarv-cycle.md` — the Reason → Act → Reflect → Verify self-check every agent runs.
+
+## 2. Discover the active profile (this decides which gates run)
+
+Read `.claude/config/stack-catalog.snapshot.yaml`. Its `gates:` and `agents:` lists are the
+**authoritative set** of what the installed profile activated. Also read
+`.claude/config/init-options.json` for the stack `selection` (frontend / backend / database) so you
+point each lane at the right overlay rule.
+
+- If those files are absent (a minimal/no-pip install), fall back to the **standard** pipeline.
+
+Run **only** the gates present in the snapshot's `gates:` list. The three profiles resolve to:
+
+| Profile | Gates that run |
+|---|---|
+| **lean** | code-review · build-green |
+| **standard** | spec-complete · em-approved · code-review · build-green · test-coverage · security-clear |
+| **enterprise** | standard + pipeline-green · observability-ready · acceptance |
+
+Never run a gate (or spawn its agent) that isn't in the active set — that's what makes lean fast and
+enterprise thorough. Conversely, never skip a gate that *is* in the set.
+
+## 3. Drive the pipeline
+
+Spawn the `orchestrator` agent via the Agent tool with: the task ($ARGUMENTS), the active gate list,
+and the stack selection. Instruct it to:
+
+1. **Classify** the work — bug fix vs. feature; single-stream vs. parallel lanes (backend/frontend);
+   fast-track (< 5 files) vs. full pipeline. Fast-track collapses to the lean gate set regardless of
+   profile.
+2. **Record** the plan and initial state in `.claude/CONTINUITY.md` (working memory survives
+   compaction — update it at every phase transition).
+3. **Run each active phase with its gate**, in order, using only the profile's agents:
+   spec & dev-docs → story planning → (design, if UI) → senior/architect/EM review →
+   implementation (one worktree per lane) → code review → unit + e2e tests → test-coverage merge →
+   security clear → pipeline-green + observability-ready (enterprise) → acceptance (enterprise) → PR.
+4. **Enforce gates** with the `quality-gates.md` severity model and a green RARV Verify before each
+   handoff. On a unanimous PASS, run the `devils-advocate` agent before the gate counts.
+5. **Run the defect loop** when a gate fails: document, re-run only the affected lane(s), re-merge,
+   re-test — never patch informally around the process.
+
+If the `orchestrator` agent is unavailable in this session, act as the orchestrator yourself,
+following the same steps.
+
+## 4. Stop for the human where required
+
+Pause and ask the user at the points the workflow requires: ambiguous requirements, spec
+confirmation, destructive or project-wide changes, and choice of deploy/release target. In the
+enterprise profile, the **acceptance** gate hands off to a human before the PR is finalized.
+
+## 5. Close the loop
+
+When the active gates are green: summarize what shipped, list any open issues by severity, ensure
+`.claude/CONTINUITY.md` reflects the final state, and promote any durable lessons with the
+`remember` skill (into `.claude/agent-memory/`).
+
+Begin by confirming your classification, the active profile + gate set, and the stage plan — then
+proceed.