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

claude_kit/_payload/templates/CLAUDE.stack.md.tmpl

@@ -0,0 +1,53 @@
+## Project-specific rules
+
+Configured by **claude-kit** for a **{{ frontend_label }}** ({{ frontend_language }}) frontend and a
+**{{ backend_label }}** ({{ backend_language_label }}) backend on **{{ db_label }}**, SDLC profile
+**{{ profile_label }}**. The agnostic pipeline rules above apply unchanged; the conventions below make
+them concrete for this stack.
+
+### Stack & conventions
+
+- **Frontend** — {{ frontend_label }} ({{ frontend_language }}). Conventions:
+  `.claude/rules/{{ frontend_overlay_rule }}`.
+- **Backend** — {{ backend_label }} ({{ backend_language_label }}). Conventions:
+  `.claude/rules/{{ backend_overlay_rule }}`.
+- **Database** — {{ db_label }}. Conventions: `.claude/rules/{{ db_overlay_rule }}`.
+
+Match your repository's actual layout — claude-kit configures the workflow, not your directory
+structure. Point each agent at the overlay rule for the lane it works in.
+
+### Commands (the source of truth for every agent)
+
+Backend:
+{% if backend_install_cmd %}- Install: `{{ backend_install_cmd }}`
+{% endif %}{% if backend_dev_cmd %}- Run: `{{ backend_dev_cmd }}`
+{% endif %}{% if backend_test_cmd %}- Test: `{{ backend_test_cmd }}`
+{% endif %}{% if backend_lint_cmd %}- Lint + types: `{{ backend_lint_cmd }}`
+{% endif %}{% if backend_format_cmd %}- Format: `{{ backend_format_cmd }}`
+{% endif %}{% if backend_migrate_cmd %}- Apply migrations: `{{ backend_migrate_cmd }}`
+{% endif %}{% if backend_make_migration_cmd %}- New migration: `{{ backend_make_migration_cmd }}`
+{% endif %}
+Frontend:
+{% if frontend_install_cmd %}- Install: `{{ frontend_install_cmd }}`
+{% endif %}{% if frontend_dev_cmd %}- Run: `{{ frontend_dev_cmd }}`
+{% endif %}{% if frontend_test_cmd %}- Test: `{{ frontend_test_cmd }}`
+{% endif %}{% if frontend_lint_cmd %}- Lint: `{{ frontend_lint_cmd }}`{% if frontend_typecheck_cmd %} · Types: `{{ frontend_typecheck_cmd }}`{% endif %}
+{% endif %}{% if frontend_build_cmd %}- Build: `{{ frontend_build_cmd }}`
+{% endif %}
+> Replace any command above that doesn't match your project's actual scripts — these are the
+> defaults for the selected stack and are what the agents will run.
+
+### Two independent lanes
+
+Backend and frontend are the canonical parallel lanes from
+`.claude/rules/mandatory-workflow.md`. When a feature spans both, the **API is the shared
+contract**: backend response/request schemas and frontend types must agree. The Merge Reviewer
+verifies this at the join point.
+
+### Adding a feature
+
+Follow the resource recipes in the overlays — `.claude/rules/{{ backend_overlay_rule }}`
+(model → schema → repository → service → router → migration → tests) and
+`.claude/rules/{{ frontend_overlay_rule }}` (types → api → hook → component → tests). Keep the API
+contract in sync across both lanes, and follow `.claude/rules/{{ db_overlay_rule }}` for schema and
+migration changes.

claude_kit/_payload/templates/CONTINUITY.template.md

@@ -0,0 +1,35 @@
+# CONTINUITY — Working Memory
+
+> Seed template. The `load-continuity.sh` SessionStart hook copies this to `.claude/CONTINUITY.md`
+> (gitignored) on first run. Overwrite the sections below as work progresses — keep it short and truthful.
+> Protocol: read at turn start, write at turn end. See `.claude/rules/continuity.md`.
+
+## Current Phase
+[none — idle]
+
+## Active Tasks
+- [none]
+
+## Completed (this session)
+- [none]
+
+## Decisions Made
+- [none]
+
+## Mistakes & Learnings
+- [none]  (promote durable ones to agent-memory via the remember skill)
+
+## Next Steps
+1. [await next requirement]
+
+## Open Questions
+- [none]
+
+## Blocked Items
+- [none]
+
+## Modified Files
+- [none]
+
+## Test/Build Status
+- backend: [unknown]   frontend: [unknown]

claude_kit/_payload/templates/README.claude-sdlc.md.tmpl

@@ -0,0 +1,219 @@
+# {{ project_name }} — Claude Code SDLC config
+
+This repository has a **claude-kit** autonomous-SDLC configuration installed. Claude Code reads it
+automatically when you open the project; nothing here is application code.
+
+- **Stack:** {{ frontend_label }} ({{ frontend_language }}) · {{ backend_label }}
+  ({{ backend_language_label }}) · {{ db_label }}
+- **SDLC profile:** {{ profile_label }}
+- **MCP integrations:** {{ mcp_list }}
+- **Installed:** ~{{ agent_count }} agents · {{ skill_count }} skills · stack overlay rules
+  ({{ overlay_rules_list }})
+
+## What got installed
+
+```
+CLAUDE.md                  entry point — rules + your stack's commands ("Project-specific rules")
+README.claude-sdlc.md      this file
+.claude/
+  settings.json            hooks (working memory, learnings, guardrails, quality checks)
+  rules/                   the engineering rule set + your stack's overlay rules
+  agents/                  the SDLC agents for the chosen profile (+ stack specialists)
+  skills/                  on-demand skills, including sdlc/ — the pipeline entry point
+  hooks/                   the hook scripts referenced by settings.json
+  templates/               artifact templates (feature-spec, adr, test-plan, …)
+  config/                  init-options.json (selection + checksums) + the catalog snapshot
+  state/  tmp/             runtime scratch (gitignored)
+{% if mcp_list != "none" %}.mcp.json                  the MCP servers you selected (fill in the ${ENV} placeholders)
+{% endif %}```
+
+How Claude Code discovers it: `CLAUDE.md` is loaded as project context; `.claude/agents/*.md`,
+`.claude/skills/*/SKILL.md`, and the hooks in `.claude/settings.json` are auto-discovered;
+`.mcp.json` (if present) registers MCP servers.
+
+## Start the workflow
+
+Open the project in Claude Code and run the pipeline entry point:
+
+```
+/sdlc Build JWT authentication for the backend
+```
+
+The orchestrator asks a few ordered questions, classifies the work, then delegates to specialist
+agents through the pipeline phases — enforcing a quality gate between each. With this profile the
+active gates are: **{{ profile_label }}**.
+
+You can also invoke any single skill directly (e.g. `/spec-driven-development`, `/code-review-and-quality`)
+or ask Claude to use a specific agent.
+
+## Core rules (non-negotiable)
+
+- Never read or print secrets. Never run destructive commands without confirmation.
+- Plan before large edits; write a spec before implementing a feature.
+- Run the project's validation (lint, type-check, tests) before declaring work complete.
+
+See `CLAUDE.md` and `.claude/rules/` for the full set.
+
+## Extending the config
+
+- **Add a stack** (frontend framework, backend language/framework, or database): add an entry to the
+  claude-kit catalog and a `templates/stacks/<stack_dir>/` folder with overlay rules — then re-run
+  `claude-kit init`. It's a data change, not code.
+- **Add a skill / agent:** drop a `.claude/skills/<name>/SKILL.md` or `.claude/agents/<name>.md`.
+- **Enable MCP later:** add servers to `.mcp.json` (see `claude-kit list-options` for the catalog).
+- **Upgrade safely:** `claude-kit diff` to preview, then `claude-kit upgrade` (your edits are backed
+  up, never silently overwritten). `claude-kit doctor` checks config health.
+
+## Organization-wide vibe-coding capabilities
+
+claude-kit isn't just for one developer. Engineers, PMs, designers, QA, DevOps, security, data,
+support, and founders can all drive work in natural language — creating features, fixing bugs, writing
+tests, reviewing code, generating docs, shipping releases, and maintaining systems — through a shared,
+safe, consistent set of **skills · agents · rules · hooks · workflows · MCP**.
+
+- **This project's scope:** `{{ scope }}`{% if scope == "organization" %} · **teams:** {{ teams_list }} · **autonomy:** `{{ autonomy }}` ({{ autonomy_policy }}) · **review strictness:** `{{ review_strictness }}` · **packs:** {{ org_packs_list }}{% endif %}
+- **The vocabulary:** *Skills* are reusable playbooks (slash commands). *Agents* are specialized
+  workers with isolated context and tool limits. *Rules* are always-on (or path-scoped) conventions.
+  *Hooks* are deterministic checks at lifecycle events. *Workflows* orchestrate agents+skills.
+  *MCP* connects Claude to GitHub, Jira, Linear, databases, browsers, and docs.
+
+### 1. Skills for org-wide reusable workflows
+`/sdlc` (the pipeline), `/spec-driven-development`, `/planning-and-task-breakdown`,
+`/code-review-and-quality`, `/test-driven-development`, `/security-and-hardening`, `/threat-model`,
+`/accessibility-review`, `/performance-optimization`, `/shipping-and-launch`, `/refresh-docs`, and the
+non-engineer playbooks `/feature-from-idea`, `/prompt-to-safe-task`, `/prototype-to-production`,
+`/customer-issue-to-fix`, `/repo-onboarding`.
+
+### 2. Agents by role/team
+Orchestration/quality: `orchestrator`, `risk-classifier`, `sdlc-code-reviewer`, `acceptance-reviewer`,
+`merge-reviewer`, `devils-advocate`. Product: `pm-copilot`, `spec-doc-writer`, `story-planner`,
+`ui-designer`. Engineering: `developer`, `senior-backend-dev`, `senior-frontend-dev`,
+`technical-architect` (+ DB specialists). Quality: `tester`, `unit-tester`, `e2e-tester`,
+`senior-tester`. Security/reliability: `security-reviewer`, `owasp-reviewer`, `secret-scanner`,
+`dependency-scanner`, `policy-validator`, `devops-engineer`, `observability-engineer`,
+`incident-responder`. Non-engineers: `pm-copilot`, `founder-prototype-agent`, `support-ticket-engineer`,
+`data-workflow-agent`, `internal-tools-builder`.
+
+### 3. Rules to share across repositories
+`mandatory-workflow`, `quality-gates`, `autonomy-levels`, `risk-classification`, `human-in-the-loop`,
+`agent-guardrails`, plus the policy set `secrets-policy`, `pii-policy`, `production-data-policy`,
+`branch-and-pr-policy`, `compliance-policy`, and the vibe-coding set `prompt-to-task-conversion`,
+`non-engineer-safe-coding`, `prototype-boundaries`, `ambiguity-resolution`.
+
+### 4. Hooks to enforce for safety & quality
+`guard-rm-rf` (dangerous shell), `protect-secrets` + `guard-commit-secrets` (secrets),
+`warn-sensitive-files` (auth/payments/migrations/infra), `validate-frontmatter` + `validate-settings`,
+`warn-large-edits`, `warn-missing-tests`, `audit-log` (local, org mode), `lint-fix`, `type-check`.
+Conservative by default; higher autonomy levels enable more. Disable any per-repo in
+`.claude/settings.local.json`.
+
+### 5. Optional MCP integrations
+GitHub (issues/PRs), Jira/Linear (tickets), the project database (read), Playwright (browser/E2E),
+and Context7 (live library docs). Select at init; they land in `.mcp.json` with `${ENV}` placeholders.
+
+### 6. Distributing capabilities across projects
+| Layer | Lives in | Use for |
+|-------|----------|---------|
+| **Project** | `.claude/`, `CLAUDE.md`, `.mcp.json` (committed) | what this repo needs — the per-repo source of truth |
+| **User** | `~/.claude/` (per developer, not committed) | personal preferences, personal skills, local overrides |
+| **Organization** | reusable packs / plugins, versioned + changelogged in an approved registry | shared, governed capabilities adopted across repos |
+
+**Never commit:** local secrets, `.env`, personal tokens, personal `settings.local.json`.
+(Planned: `claude-sdlc package-org-pack` / `install-org-pack` to package + install approved packs.)
+
+### 7. Governing changes, versions, security & adoption
+See `.claude/org-packs/README.md` for the pack registry and governance: how to add a skill/agent,
+retire duplicates, approve hooks, review sensitive rules, version packs, roll out across repos, run
+different autonomy levels per repo, and measure adoption.
+
+## Capability matrix
+
+| Capability area | Skills | Agents | Rules | Hooks | Example |
+|---|---|---|---|---|---|
+| Feature development | `/sdlc`, `/spec-driven-development`, `/incremental-implementation` | `orchestrator`, `developer`, `sdlc-code-reviewer` | `mandatory-workflow`, `quality-gates` | `lint-fix`, `type-check` | `/sdlc Add team invites` |
+| Bug fixing | `/debugging-and-error-recovery`, `/triage` | `developer`, `tester`, `sdlc-code-reviewer` | `testing`, `rarv-cycle` | `warn-missing-tests` | `/sdlc Fix 500 on empty title` |
+| Refactoring | `/code-simplification` | `developer`, `sdlc-code-reviewer` | `code-organization`, `design-patterns` | `warn-large-edits` | `/refactor-safely the billing service` |
+| Test generation | `/test-driven-development`, `/unit-test` | `tester`, `unit-tester`, `e2e-tester`, `senior-tester` | `testing` | `warn-missing-tests` | `/write-tests password-reset links` |
+| PR review | `/code-review-and-quality` | `sdlc-code-reviewer`, `merge-reviewer`, `devils-advocate` | `quality-gates`, `branch-and-pr-policy` | `guard-push-main` | `/review-pr` |
+| Product discovery | `/idea-refine`, `/interview-me`, `/feature-from-idea` | `pm-copilot`, `story-planner` | `ambiguity-resolution` | — | `/feature-from-idea team invites` |
+| Requirements clarification | `/interview-me`, `/scope`, `/prompt-to-safe-task` | `pm-copilot`, `spec-doc-writer`, `risk-classifier` | `prompt-to-task-conversion`, `ambiguity-resolution` | — | `/prompt-to-safe-task make dashboard faster` |
+| Architecture decisions | `/spec-driven-development`, `/decision`, `/documentation-and-adrs` | `technical-architect` | `design-patterns` | — | ADR for a new module |
+| API design | `/api-and-interface-design` | `technical-architect`, `senior-backend-dev` | `design-patterns`, `documentation` | — | `/api-contract` for invites |
+| Database design | `/spec-driven-development` | `postgres-specialist`/`mongodb-specialist`, `migration-specialist` | (stack overlay db rules) | `warn-sensitive-files` | schema + migration for invites |
+| Frontend implementation | `/frontend-ui-engineering`, `/component-design`, `/ui-ux-design` | `senior-frontend-dev`, `ui-designer`, `developer` | `frontend-best-practices`, `responsive-and-accessibility` | `lint-fix` | `/design-to-frontend` the invite modal |
+| Backend implementation | `/incremental-implementation`, `/api-and-interface-design` | `senior-backend-dev`, `developer` | `code-organization` | `lint-fix`, `type-check` | implement the invites endpoint |
+| Security review | `/security-and-hardening`, `/security-verification`, `/threat-model` | `security-reviewer`, `owasp-reviewer`, `secret-scanner`, `dependency-scanner`, `policy-validator` | `secrets-policy`, `agent-guardrails` | `protect-secrets`, `guard-commit-secrets`, `warn-sensitive-files` | `/security-review` the auth change |
+| Performance review | `/performance-optimization`, `/load-testing` | `db-performance-reviewer` (PostgreSQL) | `risk-classification` | — | `/performance-review` the list endpoint |
+| Accessibility review | `/accessibility-review` | `ui-designer` | `responsive-and-accessibility` | — | `/accessibility-review` the modal |
+| DevOps / release | `/shipping-and-launch`, `/ci-cd-and-automation` | `devops-engineer`, `pr-raiser`, `observability-engineer` | `devops-observability`, `branch-and-pr-policy` | `guard-push-main` | `/release-plan`, `/rollback-plan` |
+| Incident response | `/incident-postmortem` | `incident-responder` | `devops-observability` | `audit-log` | `/incident-runbook` for SEV1 |
+| Documentation | `/documentation-and-adrs`, `/refresh-docs` | `technical-architect` | `documentation` | — | `/docs-update` after an API change |
+| Onboarding | `/repo-onboarding` | `Explore`, `technical-architect` | `documentation`, `code-organization` | — | `/repo-onboarding` for a new hire |
+| Data analysis | (planning, read-only) | `data-workflow-agent` | `production-data-policy`, `pii-policy` | — | plan a report query safely |
+| Customer-support engineering | `/customer-issue-to-fix` | `support-ticket-engineer`, `developer`, `tester` | `risk-classification` | — | `/customer-issue-to-fix` invoice export |
+| Internal tools | `/prototype-to-production`, `/feature-from-idea` | `internal-tools-builder`, `founder-prototype-agent` | `non-engineer-safe-coding`, `prototype-boundaries` | `warn-sensitive-files` | build an internal admin utility |
+| Prototype-to-production hardening | `/prototype-to-production` | `founder-prototype-agent`, `security-reviewer`, `tester` | `prototype-boundaries`, `risk-classification` | `warn-large-edits`, `warn-missing-tests` | `/prototype-to-production` a CSV script |
+
+## Autonomy model
+
+How much Claude may do before a human acts (set per repo; default `assisted`). Full detail in
+`.claude/rules/autonomy-levels.md`.
+
+| Level | May do | Must not, without a human |
+|-------|--------|----------------------------|
+| advisory | inspect · explain · plan · review | edit files unless asked |
+| assisted *(default)* | edit after explaining the plan | broad/cross-cutting changes without asking |
+| autonomous-local | implement locally + run validation | push, open PRs, leave the repo |
+| autonomous-pr | create branches + PR-ready changes | **merge** (human review required) |
+| enterprise-controlled | work through strict gates + audit | edit sensitive files / complete without security + review |
+
+## Risk classification
+
+Every task is classified **low · medium · high · restricted** before work starts
+(`.claude/rules/risk-classification.md`). High-risk areas — authentication, authorization, payments,
+secrets, production data, database migrations, infrastructure, security controls, compliance, destructive
+operations, dependency upgrades, many-file changes — require: a plan · explicit approval · security
+review · test review · rollback notes · a residual-risk summary. Restricted work cannot start without
+written human authorization.
+
+## Governance & adoption
+
+- **Add a skill/agent:** create it in the kit's `templates/org/…`, list it in the pack's `pack.yaml`,
+  document it in the pack README. **Reuse before creating** — never add a competing duplicate.
+- **Retire duplicates:** prefer one canonical component; deprecate aliases via `/deprecation-and-migration`.
+- **Approve hooks & sensitive rules:** security/DevOps review before rollout; keep hooks conservative.
+- **Version & roll out:** version packs, keep a changelog, roll out repo-by-repo with `claude-kit diff`
+  then `claude-kit upgrade` (edits are backed up).
+- **Different teams, different autonomy:** choose the level per repo (a regulated service vs an internal tool).
+- **Collect feedback:** capture recurring prompts (→ new skills) and recurring mistakes (→ new rules)
+  via the `remember` skill.
+
+### Metrics worth tracking
+tasks completed through `/sdlc` · PRs created with Claude assistance · test-coverage change · escaped
+defects · review comments per PR · idea→PR time · security findings caught pre-merge · rollback
+frequency · docs updated with code · unsafe actions blocked by hooks · repeated prompts that should
+become skills · repeated mistakes that should become rules.
+
+## Examples for different org users
+
+```text
+# PM — idea to reviewable plan (asks product questions, writes acceptance criteria + stories,
+#      routes to engineering, STOPS for approval before any code)
+/feature-from-idea Add team invites to the admin dashboard
+
+# Engineer — behavior-preserving refactor (reads files, classifies risk, plans, proposes tests,
+#            small changes, invokes code + test review)
+/refactor-safely Simplify the billing service without changing behavior
+
+# QA — regression coverage (finds modules, proposes unit/integration/e2e tests, writes + validates,
+#      summarizes coverage gaps)
+/write-tests Add regression coverage for failed password-reset links
+
+# Support — issue to fix (repro report, asks for logs/steps, finds code paths, proposes fix +
+#           validation checklist)
+/customer-issue-to-fix Customer cannot export invoices over 10MB
+
+# Founder/operator — prototype to production (identifies risks, asks about users + data sensitivity,
+#                    adds validation/auth/error handling/logging/tests, requires review)
+/prototype-to-production Turn this internal CSV upload script into a safe admin feature
+```

claude_kit/_payload/templates/agent-memory/MEMORY.md

@@ -0,0 +1,30 @@
+# Agent Memory Index
+
+Categorized, durable learnings captured across Claude sessions for this project. Each entry
+links to a detailed memory file. Captured via the `remember` skill; injected into context each
+session by the `load-learnings.sh` SessionStart hook.
+
+Before design or implementation work, open the category file flagged by an entry's "applies
+when" hook and follow it.
+
+## Categories
+
+### Architecture Decisions
+<!-- - [Title](architecture/filename.md) — one-line description | applies when: ... -->
+
+### Debugging Insights
+<!-- - [Title](debugging/filename.md) — one-line description | applies when: ... -->
+
+### Project Patterns
+<!-- - [Title](patterns/filename.md) — one-line description | applies when: ... -->
+
+### API & Integration
+<!-- - [Title](api/filename.md) — one-line description | applies when: ... -->
+
+### Performance
+<!-- - [Title](performance/filename.md) — one-line description | applies when: ... -->
+
+### Gotchas & Pitfalls
+<!-- - [Title](gotchas/filename.md) — one-line description | applies when: ... -->
+
+_No learnings recorded yet. They accumulate here automatically as you work._

claude_kit/_payload/templates/artifacts/adr.md

@@ -0,0 +1,18 @@
+# ADR <NNNN>: <title>
+
+- **Status:** proposed | accepted | superseded by ADR-<NNNN>
+- **Date:** <YYYY-MM-DD>
+- **Deciders:** <who>
+
+## Context
+The forces at play: the problem, constraints, and what makes this decision non-trivial.
+
+## Decision
+The choice made, stated in active voice ("We will …").
+
+## Alternatives considered
+- Option A — pros / cons / why not.
+- Option B — pros / cons / why not.
+
+## Consequences
+What becomes easier and what becomes harder. Follow-ups, migrations, and risks created.

claude_kit/_payload/templates/artifacts/feature-spec.md

@@ -0,0 +1,29 @@
+# Feature spec: <name>
+
+> Produced before implementation (see `.claude/rules/mandatory-workflow.md`). Keep it explicit
+> enough to review.
+
+## Problem / motivation
+What user need or problem does this address? Why now?
+
+## Goals / non-goals
+- Goals:
+- Non-goals:
+
+## Acceptance criteria
+- [ ] Given … when … then …
+- [ ] …
+
+## Scope
+Affected modules / files / surfaces. Independent work streams (e.g. backend lane, frontend lane).
+
+## Design
+Approach, data model / API contract changes, key decisions (link ADRs for significant ones).
+
+## Risks & constraints
+Deadline, compatibility, security, performance, compliance.
+
+## Test plan (summary)
+What unit / integration / e2e coverage proves the acceptance criteria. (Detail in test-plan.md.)
+
+## Rollout / open questions

claude_kit/_payload/templates/artifacts/release-plan.md

@@ -0,0 +1,23 @@
+# Release plan: <version / change>
+
+## Summary
+What's shipping and the user-visible impact.
+
+## Pre-flight
+- [ ] All quality gates green (review, tests, security; pipeline/observability if applicable).
+- [ ] Migrations reviewed and reversible; back-fill plan for new constraints.
+- [ ] Config / env vars / feature flags documented and set per environment.
+
+## Steps
+1. …
+2. …
+
+## Verification (post-deploy)
+- Health/readiness checks pass; key user journeys smoke-tested.
+- Dashboards/alerts show expected baselines.
+
+## Rollback
+Exact steps to revert (deploy + data). Trigger conditions.
+
+## Comms
+Who to notify, changelog entry, and any user-facing notes.

claude_kit/_payload/templates/artifacts/runbook.md

@@ -0,0 +1,24 @@
+# Runbook: <service / capability>
+
+> Operational reference (see `.claude/rules/devops-observability.md`).
+
+## Overview
+What this service does and its critical user journeys / SLOs.
+
+## Health & dashboards
+- Health endpoint(s): …
+- Dashboards / logs / traces: …
+- Key metrics & alert thresholds: …
+
+## Common operations
+- Deploy / rollback: …
+- Run/replay a migration: …
+- Rotate credentials: …
+
+## Incident playbook
+| Symptom | Likely cause | First checks | Mitigation |
+|---|---|---|---|
+| … | … | … | … |
+
+## Escalation
+On-call / owners and when to escalate.

claude_kit/_payload/templates/artifacts/security-review.md

@@ -0,0 +1,23 @@
+# Security review: <change>
+
+> Output of the Security Clear gate (see `.claude/rules/quality-gates.md`). Findings are classified
+> Critical / High / Medium / Low / Cosmetic; Critical/High/Medium block.
+
+## Scope
+What changed and what attack surface it touches (inputs, auth, data, dependencies, config).
+
+## Findings
+| # | Severity | Area | Finding | Recommendation | Status |
+|---|---|---|---|---|---|
+| 1 | … | secrets/deps/owasp/policy | … | … | open/fixed |
+
+## Checklist
+- [ ] No hardcoded secrets / keys / tokens committed.
+- [ ] Dependencies free of known Critical/High CVEs.
+- [ ] Input validated & queries parameterized (no injection).
+- [ ] AuthN/AuthZ enforced on new surfaces; least privilege.
+- [ ] Sensitive data not logged; errors don't leak internals.
+- [ ] CORS / rate limiting / secure cookie flags as required by policy.
+
+## Verdict
+PASS / FAIL (with the blocking findings, if any).

claude_kit/_payload/templates/artifacts/test-plan.md

@@ -0,0 +1,22 @@
+# Test plan: <feature>
+
+> Maps every acceptance criterion to concrete tests (see `.claude/rules/testing.md`).
+
+## Coverage matrix
+| Acceptance criterion | Test type (unit/integration/e2e) | Test name / location |
+|---|---|---|
+| … | … | … |
+
+## Unit
+Happy paths, edge cases, error paths for new/changed units.
+
+## Integration
+Component/contract boundaries (API ↔ client, service ↔ data layer).
+
+## End-to-end
+The full user journeys the feature enables.
+
+## Edge cases & negative tests
+Invalid input, auth failures, empty/loading/error states, concurrency, limits.
+
+## Out of scope / not tested (with rationale)

claude_kit/_payload/templates/org/README.md

@@ -0,0 +1,53 @@
+# Organization capability packs
+
+This directory is the **org capability layer** claude-kit installs when you scaffold with
+`scope: organization`. Each subdirectory is a **capability pack** — a `pack.yaml` manifest plus a
+`README.md` — that bundles a coherent set of skills, agents, rules, and hooks for a way of working.
+
+> **Packs are manifests, not copies.** A pack *references* components by name; the runnable
+> skills/agents/rules it lists are installed in the standard auto-discovered locations
+> (`.claude/skills/`, `.claude/agents/`, `.claude/rules/`) so Claude Code picks them up normally. This
+> directory is the **catalog + governance** layer: it documents which capabilities exist, who they're
+> for, and how to adopt them — it is not itself executed.
+
+## The packs
+
+| Pack | For | Purpose |
+|------|-----|---------|
+| `engineering-core` | Engineering | Feature dev, refactoring, debugging, review, tests, release prep |
+| `product-to-code` | Product · Founders | Ideas/tickets/PRDs/feedback → specs, stories, acceptance criteria, tasks |
+| `quality-and-review` | QA · Engineering | Test planning, regression, PR/security/perf/acceptance review |
+| `security-and-compliance` | Security · DevOps | Secrets, insecure code, unsafe commands, dependency/auth/data risk |
+| `devops-and-release` | DevOps · Engineering | CI/CD, deploy/rollback planning, release notes, observability, runbooks |
+| `onboarding-and-docs` | Engineering · Support | Understand the repo, generate/keep docs in sync, onboarding paths |
+| `non-engineer-builder` | Product · Design · Founders · Support · Data | Safe vibe-coding for non-engineers (clarify, plan, limited scope, approval gates) |
+
+## How capabilities reach this repo
+
+| Layer | Lives in | Use for |
+|-------|----------|---------|
+| **Project** | `.claude/`, `CLAUDE.md`, `.mcp.json`, this README — committed | what this repo needs; the source of truth per repo |
+| **User** | `~/.claude/` (per developer, not committed) | personal preferences, personal skills, local overrides |
+| **Organization** | reusable packs/plugins distributed across repos | the shared, approved, versioned capabilities below |
+
+**Never commit:** local secrets, `.env`, personal tokens, or personal `settings.local.json`.
+
+## Autonomy & risk
+
+Every pack operates under the project's **autonomy level** (`.claude/rules/autonomy-levels.md`) and
+**risk classification** (`.claude/rules/risk-classification.md`). High-risk or restricted work (auth,
+payments, secrets, production data, migrations, infrastructure) always requires a plan, explicit human
+approval, security + test review, and rollback notes — regardless of pack or autonomy level.
+
+## Governance (adopt · change · version)
+
+- **Add a skill/agent/rule to a pack:** add the file to the kit's `templates/org/…`, list it in the
+  pack's `pack.yaml`, and document it in the pack README. Reuse an existing component before creating a
+  new one (avoid duplicate, competing components).
+- **Approve hooks & sensitive rules:** security-relevant hooks and policy rules change through review by
+  the owning team (security/DevOps) before rollout.
+- **Version & roll out:** packs are versioned; record changes in a changelog and roll out repo-by-repo
+  with `claude-kit diff` / `claude-kit upgrade` (your edits are backed up, never silently overwritten).
+- **Different teams, different autonomy:** pick the autonomy level per repo; a regulated repo can run
+  `enterprise-controlled` while an internal tool runs `assisted`.
+- **Measure adoption & quality:** see the "Metrics" section in `README.claude-sdlc.md`.

claude_kit/_payload/templates/org/agents/data-workflow-agent.md

@@ -0,0 +1,59 @@
+---
+name: data-workflow-agent
+description: Data-workflow partner for analysts. Turns a described query, report, or transformation into a sanity-checked, runnable plan — READ-ONLY by default. Plans and clarifies — never runs queries or writes data; requires human approval before any production access, write/delete, or PII handling.
+tools: Read, Glob, Grep, SendMessage
+mode: plan
+model: sonnet
+color: green
+tier: specialist
+---
+
+You are the **Data Workflow Agent** — an analyst's partner for safe data work. You turn a described
+query, report, or transformation into a reviewable, runnable plan. You are **read-only by default**
+and do **not** run queries or modify data.
+
+## MANDATORY: Read Before Acting
+1. `.claude/rules/production-data-policy.md` — what production data access requires.
+2. `.claude/rules/pii-policy.md` — how sensitive/personal data must be handled.
+3. `.claude/rules/risk-classification.md` — classify the workflow before planning.
+
+## Role
+Translate a described query, report, or data transformation into a sanity-checked, ordered plan the
+analyst can run safely — surfacing risk, scope, and data-sensitivity first.
+
+## Responsibilities
+- Clarify the question: inputs, the data store(s) involved, expected output, and filters.
+- Sanity-check the logic for join/grain errors, missing filters, double-counting, and unbounded scans.
+- Classify risk (with `risk-classifier`) and flag any production, write/delete, or PII exposure.
+- Produce a step-by-step **runnable plan** the analyst executes, or route via `/repo-onboarding` for context.
+
+## Allowed tools
+Read, Glob, Grep (to inspect schemas/definitions read-only) and SendMessage (to delegate). No editing, no running.
+
+## Forbidden actions
+- Do not run, execute, or schedule queries, transformations, or shell commands.
+- Do not perform destructive or write/delete operations under any circumstances.
+- Do not touch PII or production data, or export sensitive data, without explicit human approval.
+
+## Required inputs
+A described query, report, or transformation. If the data store, grain, or output is unclear, ask before planning.
+
+## Output schema
+```
+GOAL: <what the analyst needs, 1–2 sentences>
+DATA STORE(S): <sources> / GRAIN: <one row = ...>
+LOGIC CHECK: <joins, filters, dedup, scope concerns found>
+RUNNABLE PLAN (ordered): <step 1 ... step n — read-only unless approved>
+RISK: <low|medium|high|restricted> — <why>
+SENSITIVITY: <prod? write/delete? PII? export?>
+APPROVAL NEEDED: <what the human must confirm before running>
+```
+
+## Escalation conditions
+Ambiguous grain or scope; logic that risks double-counting or unbounded scans; anything touching
+production, writes/deletes, or PII; work exceeding the active autonomy level → escalate via
+`.claude/rules/human-in-the-loop.md`.
+
+## Human-approval conditions
+Always for any production-data access; always for any write/delete or PII handling; always before
+exporting sensitive data; whenever the plan changes materially after approval.