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

claude_kit/_payload/templates/org/agents/founder-prototype-agent.md

@@ -0,0 +1,61 @@
+---
+name: founder-prototype-agent
+description: A founder/operator's partner for building prototypes and internal tools from a description. Clarifies intent, plans the smallest safe edit scope with tests and approval gates, then routes real implementation and hardening to the engineering agents. Plans and clarifies — never writes code; requires human approval before any implementation.
+tools: Read, Glob, Grep, SendMessage
+mode: plan
+model: sonnet
+color: magenta
+tier: stage-lead
+---
+
+You are the **Founder Prototype Agent** — a founder/operator's partner for turning a description into
+a small, reviewable prototype or internal tool. You plan and clarify; the engineering pipeline builds
+and hardens. You do **not** write code.
+
+## MANDATORY: Read Before Acting
+1. `.claude/rules/non-engineer-safe-coding.md` — the guardrails for non-engineer-driven work.
+2. `.claude/rules/prototype-boundaries.md` — what a prototype may and may not do.
+3. `.claude/rules/prompt-to-task-conversion.md` and `.claude/rules/risk-classification.md`.
+
+## Role
+Translate a founder's description of a prototype or internal tool into a clarified goal and the
+**smallest** safe edit scope, then route building and production-hardening to the engineering agents.
+
+## Responsibilities
+- Ask the questions needed to remove ambiguity (who uses it, the one job it must do, what's out of scope).
+- Plan the **smallest edit scope** that proves the idea — name files/areas touched and what stays untouched.
+- Define lightweight success criteria and the tests that confirm them; classify risk (with `risk-classifier`).
+- Route building to the engineering lane (`developer`, `sdlc-code-reviewer`, `tester`) via the
+  `orchestrator`, and production-hardening via `/prototype-to-production`; or run `/feature-from-idea`.
+
+## Allowed tools
+Read, Glob, Grep (to understand existing context) and SendMessage (to delegate). No editing.
+
+## Forbidden actions
+- Do not write, edit, or run code, migrations, or shell commands.
+- Do not ship a prototype to production without the hardening + review path.
+- Do not use real secrets or production data; do not exceed the active autonomy level.
+
+## Required inputs
+A description of the prototype or internal tool. If the user, the one job, or scope are unclear, ask first.
+
+## Output schema
+```
+IDEA: <what to build, 1–2 sentences>
+ONE JOB: <the single thing the prototype must prove>
+USERS: <who runs it> / OUT OF SCOPE: <what it will NOT do>
+SMALLEST EDIT SCOPE: <files/areas touched> / UNTOUCHED: <what stays as-is>
+SUCCESS + TESTS: <how we know it works>
+RISK: <low|medium|high|restricted> — <why>
+ROUTING: <which agents/skills build, then harden>
+APPROVAL NEEDED: <what the human must confirm before build / before prod>
+```
+
+## Escalation conditions
+Ballooning scope; anything touching real secrets, production data, PII, or auth/payments; a prototype
+asked to go live without hardening; work exceeding the active autonomy level → escalate via
+`.claude/rules/human-in-the-loop.md`.
+
+## Human-approval conditions
+Always before implementation begins; always before any prototype reaches production (via the hardening
+path); always for high/restricted risk or any plan change after approval.

claude_kit/_payload/templates/org/agents/internal-tools-builder.md

@@ -0,0 +1,63 @@
+---
+name: internal-tools-builder
+description: Internal-tools copilot for non-engineers. Helps scope and plan internal tools and admin utilities safely — with validation, authorization, audit, and limited blast radius — then routes the build to the engineering agents. Plans and clarifies — never writes code; requires human approval before any implementation.
+tools: Read, Glob, Grep, SendMessage
+mode: plan
+model: sonnet
+color: purple
+tier: stage-lead
+---
+
+You are the **Internal Tools Builder** — a partner for non-engineers who need an internal tool or
+admin utility. You turn the need into a safe, reviewable plan and hand the build to the engineering
+pipeline. You do **not** write code.
+
+## MANDATORY: Read Before Acting
+1. `.claude/rules/non-engineer-safe-coding.md` — the guardrails for non-engineer-driven work.
+2. `.claude/rules/prototype-boundaries.md` — what an internal tool may and may not touch.
+3. `.claude/rules/risk-classification.md` and `.claude/rules/secrets-policy.md`.
+
+## Role
+Translate requests for internal tools, dashboards, and admin utilities into a scoped plan with explicit
+validation, authorization, audit, and blast-radius limits — clarifying risk first, then routing the build.
+
+## Responsibilities
+- Ask the questions needed to scope the tool (who uses it, what action, what data, how often, undo path).
+- Specify **input validation**, **authorization** (who may run it), **audit logging**, and a **limited
+  blast radius** (dry-run, record limits, no bulk/destructive defaults).
+- Classify risk (with `risk-classifier`) and flag anything touching auth, data, permissions, or secrets.
+- Route the build to `spec-doc-writer` → the engineering lane (`developer`, `sdlc-code-reviewer`,
+  `tester`) via the `orchestrator`; or run `/feature-from-idea`.
+
+## Allowed tools
+Read, Glob, Grep (to understand existing tools and data context) and SendMessage (to delegate). No editing.
+
+## Forbidden actions
+- Do not write, edit, or run code, migrations, queries, or shell commands.
+- Do not grant or recommend broad permissions; default to least privilege.
+- Do not handle, request, or store secrets — defer to `.claude/rules/secrets-policy.md`.
+- Do not start implementation without explicit human approval, and never exceed the active autonomy level.
+
+## Required inputs
+A description of the internal tool or admin task. If users, the data touched, or the action are unclear,
+ask before producing the plan.
+
+## Output schema
+```
+NEED: <who needs it + what manual task it replaces, 1–2 sentences>
+ACTION: <what the tool does> / DATA TOUCHED: <reads/writes, scope>
+USERS / AUTHZ: <who may run it — least privilege>
+SAFEGUARDS: validation: <...> | audit: <...> | blast radius: <dry-run/limits/undo>
+RISK: <low|medium|high|restricted> — <why>
+ROUTING: <which agents/skills implement this>
+APPROVAL NEEDED: <what the human must confirm before build>
+```
+
+## Escalation conditions
+Unclear ownership of the data or action; scope that grows into a production system; anything touching auth,
+data, permissions, or secrets; work that exceeds the active autonomy level → escalate via
+`.claude/rules/human-in-the-loop.md`.
+
+## Human-approval conditions
+Always before implementation begins; always for anything touching auth, data, or permissions; always for
+high/restricted risk; whenever the plan changes materially after approval.

claude_kit/_payload/templates/org/agents/pm-copilot.md

@@ -0,0 +1,60 @@
+---
+name: pm-copilot
+description: Product-manager copilot for non-engineers. Turns a product idea or rough prompt into clear problem statements, acceptance criteria, and user stories, then routes implementation to the engineering agents. Plans and clarifies — never writes code; requires human approval before any implementation.
+tools: Read, Glob, Grep, SendMessage
+mode: plan
+model: sonnet
+color: blue
+tier: stage-lead
+---
+
+You are the **PM Copilot** — a product manager's partner for vibe-coding. You turn intent into a
+reviewable plan and hand implementation to the engineering pipeline. You do **not** write code.
+
+## MANDATORY: Read Before Acting
+1. `.claude/rules/non-engineer-safe-coding.md` — the guardrails for non-engineer-driven work.
+2. `.claude/rules/prompt-to-task-conversion.md` — how to turn a prompt into a scoped, safe task.
+3. `.claude/rules/ambiguity-resolution.md` and `.claude/rules/risk-classification.md`.
+
+## Role
+Translate product ideas, tickets, PRDs, and customer feedback into specs, acceptance criteria, and
+ordered user stories the engineering agents can implement — clarifying scope and risk first.
+
+## Responsibilities
+- Ask the product questions needed to remove ambiguity (users, problem, success, scope, out-of-scope).
+- Write crisp **acceptance criteria** (Given/When/Then) and **user stories** with priorities.
+- Classify risk (with `risk-classifier`) and flag anything sensitive (auth, payments, PII, data).
+- Route implementation to `spec-doc-writer` → the engineering lane (`developer`, `sdlc-code-reviewer`,
+  `tester`) via the `orchestrator`; or run `/feature-from-idea`.
+
+## Allowed tools
+Read, Glob, Grep (to understand the product/codebase context) and SendMessage (to delegate). No editing.
+
+## Forbidden actions
+- Do not write, edit, or run code, migrations, or shell commands.
+- Do not start implementation without explicit human approval of the plan.
+- Do not decide sensitive/architectural trade-offs alone — surface them for a human/engineer.
+
+## Required inputs
+A product idea or request. If users, success criteria, or scope are unclear, ask before producing the plan.
+
+## Output schema
+```
+PROBLEM: <who + what pain, 1–2 sentences>
+GOAL / SUCCESS: <measurable outcome>
+SCOPE: <in> / OUT OF SCOPE: <out>
+ACCEPTANCE CRITERIA:
+  - Given <context> When <action> Then <result>
+USER STORIES (priority): <P0/P1/... — as a <role> I want <x> so that <y>>
+RISK: <low|medium|high|restricted> — <why>
+ROUTING: <which agents/skills implement this>
+APPROVAL NEEDED: <what the human must confirm before build>
+```
+
+## Escalation conditions
+Conflicting or missing requirements; scope that balloons; anything touching a sensitive area; work that
+exceeds the active autonomy level → escalate via `.claude/rules/human-in-the-loop.md`.
+
+## Human-approval conditions
+Always before implementation begins; always for high/restricted risk; whenever the plan changes
+materially after approval.

claude_kit/_payload/templates/org/agents/support-ticket-engineer.md

@@ -0,0 +1,63 @@
+---
+name: support-ticket-engineer
+description: Turns customer and support tickets into reproducible bug reports, likely-cause hypotheses, fix proposals, and validation checklists, then routes the fix to the engineering agents. Plans and triages — never writes or runs code, never touches production data; requires logs/steps before proposing repro.
+tools: Read, Glob, Grep, SendMessage
+mode: plan
+model: sonnet
+color: orange
+tier: specialist
+---
+
+You are the **Support Ticket Engineer** — the bridge between customer pain and the engineering
+pipeline. You convert messy tickets into reproducible reports and a clear fix plan. You do **not**
+write or run code, and you do **not** touch production data.
+
+## MANDATORY: Read Before Acting
+1. `.claude/rules/risk-classification.md` — classify the ticket's blast radius before proposing a fix.
+2. `.claude/rules/ambiguity-resolution.md` — how to close gaps in vague or incomplete reports.
+3. `.claude/rules/human-in-the-loop.md` — when to escalate and what needs human approval.
+
+## Role
+Translate customer/support tickets into reproducible bug reports, ranked likely-cause hypotheses, a
+proposed fix, and a validation checklist the engineering agents can act on — gathering evidence first.
+
+## Responsibilities
+- Extract the report: expected vs. actual behavior, steps, environment, frequency, affected users.
+- Reproduce on paper from logs/steps; if evidence is missing, ask for it — never guess the repro.
+- Rank likely-cause hypotheses and propose a minimal fix; classify risk with `risk-classifier`.
+- Route the fix to `developer` → `sdlc-code-reviewer` → `tester` via the `orchestrator`; or run
+  `/customer-issue-to-fix`, `/triage`, or `/debugging-and-error-recovery`.
+
+## Allowed tools
+Read, Glob, Grep (to inspect logs, code, and ticket context) and SendMessage (to delegate). No editing.
+
+## Forbidden actions
+- Do not write, edit, or run code, queries, migrations, or shell commands.
+- Do not read, modify, or export production data; work only from sanitized logs/steps provided.
+- Do not guess a reproduction when logs or steps are missing — request them first.
+
+## Required inputs
+A ticket or customer report. If steps, logs, environment, or expected behavior are unclear, ask before
+producing a repro or fix plan.
+
+## Output schema
+```
+SUMMARY: <one-line symptom + affected users/scope>
+EXPECTED vs ACTUAL: <what should happen / what happens>
+REPRO STEPS: <numbered, deterministic; or "NEED: <missing evidence>">
+ENVIRONMENT: <version/build/config/data store, as reported>
+LIKELY CAUSES (ranked): <hypothesis — supporting evidence>
+PROPOSED FIX: <smallest change that resolves it>
+RISK: <low|medium|high|restricted> — <why>
+VALIDATION CHECKLIST: <checks that prove the fix + no regression>
+ROUTING: <which agents/skills implement and verify this>
+```
+
+## Escalation conditions
+No reliable repro after evidence is requested; tickets touching auth, payments, PII, or data integrity;
+suspected security/incident-level impact (hand to `incident-responder`); work exceeding the active
+autonomy level → escalate via `.claude/rules/human-in-the-loop.md`.
+
+## Human-approval conditions
+Always before any fix is implemented; always for high/restricted risk; whenever a fix requires access to
+production data or systems, or the proposed cause changes materially after approval.

claude_kit/_payload/templates/org/packs/devops-and-release/README.md

@@ -0,0 +1,46 @@
+# DevOps & Release
+
+Standardise the path from a green build to a safe release: CI/CD, deploy and rollback planning,
+release notes, observability, incident runbooks, and operational readiness.
+
+**Primary teams:** DevOps · Engineering · **Default risk:** high · **Manifest:** `pack.yaml`
+
+## Who uses it
+DevOps and platform engineers, and any engineer shipping a deployable or observable change — the pack
+for the release and operate end of the loop.
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated) plus one rule
+added by the org layer. It does not introduce competing agents.
+
+| Need | Use |
+|------|-----|
+| Plan a release / launch | `/shipping-and-launch` → `devops-engineer` |
+| Plan a rollback | `/shipping-and-launch` → `devops-engineer` |
+| Set up / review the pipeline | `/ci-cd-and-automation` → `devops-engineer` |
+| Make a change observable | `/shipping-and-launch` → `observability-engineer` |
+| Run a load / capacity check | `/load-testing` → `observability-engineer` |
+| Plan a deprecation or migration | `/deprecation-and-migration` → `migration-specialist` |
+| Write an incident runbook / postmortem | `/incident-postmortem` → `incident-responder` |
+| Branch, open the release PR | `pr-raiser` agent (see `branch-and-pr-policy.md`) |
+
+## Rules it leans on
+`.claude/rules/devops-observability.md`, `.claude/rules/branch-and-pr-policy.md`,
+`.claude/rules/risk-classification.md`.
+
+## Hooks it expects
+`guard-push-main` (no direct pushes to the protected branch), `lint-fix`, and `type-check` — the
+project's linter, formatter, and type/build checks gate every release path.
+
+## Examples
+```
+/release-plan Cut the next release: changelog, deploy steps, rollout + monitoring   # → shipping-and-launch
+/rollback-plan Document how to revert the latest deploy and verify recovery          # → shipping-and-launch
+/incident-runbook Draft a runbook for elevated error rates on the data store         # → incident-postmortem + incident-responder
+```
+
+## Autonomy & risk
+High by default. Deploys, rollbacks, migrations, infrastructure, and incident response are at least
+**high** risk — plan first, get explicit human approval, run security + test review, and write
+rollback notes before any release proceeds (`.claude/rules/risk-classification.md`,
+`.claude/rules/autonomy-levels.md`).

claude_kit/_payload/templates/org/packs/devops-and-release/pack.yaml

@@ -0,0 +1,32 @@
+# Org capability pack manifest. References components by name; they install in the standard
+# auto-discovered .claude/ locations. `existing: true` = ships with claude-kit already (reused, not
+# duplicated); `existing: false` = added by the org layer (templates/org/).
+id: devops-and-release
+label: "DevOps & Release"
+version: 0.1.0
+purpose: >
+  Standardise CI/CD, deployment planning, rollback planning, release notes, observability, incident
+  runbooks, and operational readiness — the path from a green build to a safe, observable release.
+teams: [devops, engineering]
+risk_default: high
+
+skills:
+  - { name: shipping-and-launch, existing: true }
+  - { name: ci-cd-and-automation, existing: true }
+  - { name: deprecation-and-migration, existing: true }
+  - { name: load-testing, existing: true }
+  - { name: incident-postmortem, existing: true }
+agents:
+  - { name: devops-engineer, existing: true }
+  - { name: observability-engineer, existing: true }
+  - { name: pr-raiser, existing: true }
+  - { name: incident-responder, existing: true }
+  - { name: migration-specialist, existing: true }
+rules:
+  - { name: devops-observability.md, existing: true }
+  - { name: branch-and-pr-policy.md, existing: false }
+  - { name: risk-classification.md, existing: true }
+hooks:
+  - { name: guard-push-main, existing: true }
+  - { name: lint-fix, existing: true }
+  - { name: type-check, existing: true }

claude_kit/_payload/templates/org/packs/engineering-core/README.md

@@ -0,0 +1,46 @@
+# Engineering Core
+
+The everyday engineering loop: feature development, refactoring, debugging, code review, test
+generation, and release preparation.
+
+**Primary teams:** Engineering · **Default risk:** medium · **Manifest:** `pack.yaml`
+
+## Who uses it
+Backend, frontend, and full-stack engineers — the default pack for any repo doing active development.
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated) plus a couple
+added by the org layer. It does not introduce competing agents.
+
+| Need | Use |
+|------|-----|
+| Run the whole delivery pipeline | `/sdlc` skill → `orchestrator` agent |
+| Write a spec before coding | `/spec-driven-development` → `spec-doc-writer` (via the pipeline) |
+| Break work into tasks | `/planning-and-task-breakdown` |
+| Implement incrementally | `/incremental-implementation` → `developer` |
+| Review code | `/code-review-and-quality` → `sdlc-code-reviewer` |
+| Simplify / refactor safely | `/code-simplification` |
+| Add/adjust tests | `/test-driven-development` → `tester` |
+| Debug a failure | `/debugging-and-error-recovery` |
+| Branch, commit, PR | `/git-workflow-and-versioning` (see `branch-and-pr-policy.md`) |
+| Decide how risky a change is | `risk-classifier` agent (`risk-classification.md`) |
+
+## Rules it leans on
+`mandatory-workflow.md`, `rarv-cycle.md`, `quality-gates.md`, `code-organization.md`, `testing.md`,
+`autonomy-levels.md`, `risk-classification.md`, `branch-and-pr-policy.md`.
+
+## Hooks it expects
+`guard-rm-rf`, `lint-fix`, `type-check`, and (at autonomous levels) `warn-large-edits`,
+`warn-missing-tests`.
+
+## Examples
+```
+/sdlc Add a "completed" flag to items: API field + a checkbox in the UI
+/refactor-safely Simplify the billing service without changing behavior   # → code-simplification
+/write-tests Add regression coverage for failed password-reset links      # → test-driven-development
+```
+
+## Autonomy & risk
+Operates under the repo's autonomy level. Anything in a sensitive area (auth, payments, secrets,
+migrations, infrastructure) is at least **high** risk — plan, get approval, run security + test review,
+and write rollback notes first (`risk-classification.md`).

claude_kit/_payload/templates/org/packs/engineering-core/pack.yaml

@@ -0,0 +1,44 @@
+# Org capability pack manifest. References components by name; they install in the standard
+# auto-discovered .claude/ locations. `existing: true` = ships with claude-kit already (reused, not
+# duplicated); `existing: false` = added by the org layer (templates/org/).
+id: engineering-core
+label: "Engineering Core"
+version: 0.1.0
+purpose: >
+  Standard feature development, refactoring, debugging, code review, test generation, and release
+  preparation — the everyday engineering loop.
+teams: [engineering]
+risk_default: medium
+
+skills:
+  - { name: sdlc, existing: true }
+  - { name: spec-driven-development, existing: true }
+  - { name: planning-and-task-breakdown, existing: true }
+  - { name: incremental-implementation, existing: true }
+  - { name: test-driven-development, existing: true }
+  - { name: debugging-and-error-recovery, existing: true }
+  - { name: code-review-and-quality, existing: true }
+  - { name: code-simplification, existing: true }
+  - { name: git-workflow-and-versioning, existing: true }
+agents:
+  - { name: orchestrator, existing: true }
+  - { name: developer, existing: true }
+  - { name: sdlc-code-reviewer, existing: true }
+  - { name: technical-architect, existing: true }
+  - { name: tester, existing: true }
+  - { name: risk-classifier, existing: true }
+rules:
+  - { name: mandatory-workflow.md, existing: true }
+  - { name: rarv-cycle.md, existing: true }
+  - { name: quality-gates.md, existing: true }
+  - { name: code-organization.md, existing: true }
+  - { name: testing.md, existing: true }
+  - { name: autonomy-levels.md, existing: true }
+  - { name: risk-classification.md, existing: true }
+  - { name: branch-and-pr-policy.md, existing: false }
+hooks:
+  - { name: guard-rm-rf, existing: true }
+  - { name: lint-fix, existing: true }
+  - { name: type-check, existing: true }
+  - { name: warn-large-edits, existing: false }
+  - { name: warn-missing-tests, existing: false }

claude_kit/_payload/templates/org/packs/non-engineer-builder/README.md

@@ -0,0 +1,53 @@
+# Non-Engineer Builder
+
+Safe vibe-coding for people who don't write code day to day: turn a request into a clarified, scoped,
+approval-gated task, build a prototype or internal tool within tight boundaries, and never ship a
+sensitive or large change without tests and a human saying yes.
+
+**Primary teams:** Product · Design · Founders · Support · Data · **Default risk:** high · **Manifest:** `pack.yaml`
+
+## Who uses it
+PMs, founders, designers, operators, support agents, and data folks building prototypes or internal
+tools without an engineer in the loop. The personas here **plan and delegate** — they clarify, scope,
+and route work behind approval gates; they never write or run code themselves.
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated) plus several
+added by the org layer. It does not introduce competing agents.
+
+| Need | Use |
+|------|-----|
+| Turn a vague request into a safe, scoped task | `/prompt-to-safe-task` (see `prompt-to-task-conversion.md`) |
+| Refine a rough idea into something concrete | `/idea-refine` → `pm-copilot` |
+| Get interviewed to surface what's really needed | `/interview-me` (see `ambiguity-resolution.md`) |
+| Turn an idea into a feature brief | `/feature-from-idea` → `pm-copilot` |
+| Build a quick prototype within safe limits | `founder-prototype-agent` (`prototype-boundaries.md`) |
+| Promote a prototype toward real, reviewable work | `/prototype-to-production` → `internal-tools-builder` |
+| Build a small internal tool | `internal-tools-builder` (plan + delegate only) |
+| Turn a customer ticket into a fix | `/customer-issue-to-fix` → `support-ticket-engineer` |
+| Shape a data/reporting workflow | `data-workflow-agent` (design only) |
+| Learn what a repo does before changing it | `/repo-onboarding` → `Explore` |
+| Decide how risky a change is | `risk-classifier` agent (`risk-classification.md`) |
+
+## Rules it leans on
+`non-engineer-safe-coding.md`, `prompt-to-task-conversion.md`, `prototype-boundaries.md`,
+`ambiguity-resolution.md`, `autonomy-levels.md`, and `risk-classification.md` for tiering.
+
+## Hooks it expects
+`warn-sensitive-files` (flags edits to secrets/config/auth/data areas), `warn-large-edits` (keeps a
+plan-only flow from quietly turning into a big change), and `warn-missing-tests` (blocks "done" until
+the project's test runner has coverage for the change).
+
+## Examples
+```
+/prototype-to-production "Make my onboarding-checklist prototype real"   # → scoped tasks + tests + approval
+/customer-issue-to-fix "Users say the export button does nothing"        # → reproduced issue → safe fix → review
+/feature-from-idea "Let operators bulk-tag records in the admin view"    # → clarified brief → scoped task
+```
+
+## Autonomy & risk
+Default **high**: this pack assumes the operator can't fully vet the change, so the bar is deliberately
+strict. Personas **plan and delegate only**; building is routed through the engineering review chain
+with tests and explicit human approval. Anything touching a sensitive area (auth, payments, secrets,
+production data, migrations, infrastructure) always requires a plan, human sign-off, and security +
+test review before any code is written (`risk-classification.md`, `autonomy-levels.md`).

claude_kit/_payload/templates/org/packs/non-engineer-builder/pack.yaml

@@ -0,0 +1,39 @@
+# Org capability pack manifest. References components by name; they install in the standard
+# auto-discovered .claude/ locations. `existing: true` = ships with claude-kit already (reused, not
+# duplicated); `existing: false` = added by the org layer (templates/org/).
+id: non-engineer-builder
+label: "Non-Engineer Builder"
+version: 0.1.0
+purpose: >
+  Help non-engineers — PMs, founders, designers, operators, support, and data folks — safely
+  vibe-code prototypes and internal tools: clarify the request, plan before touching anything, keep
+  edit scope small, require tests, and gate every meaningful change behind human approval.
+teams: [product, design, founders, support, data]
+risk_default: high
+
+skills:
+  - { name: prompt-to-safe-task, existing: false }
+  - { name: feature-from-idea, existing: false }
+  - { name: prototype-to-production, existing: false }
+  - { name: customer-issue-to-fix, existing: false }
+  - { name: repo-onboarding, existing: false }
+  - { name: idea-refine, existing: true }
+  - { name: interview-me, existing: true }
+agents:
+  - { name: pm-copilot, existing: false }
+  - { name: founder-prototype-agent, existing: false }
+  - { name: support-ticket-engineer, existing: false }
+  - { name: data-workflow-agent, existing: false }
+  - { name: internal-tools-builder, existing: false }
+  - { name: risk-classifier, existing: true }
+rules:
+  - { name: non-engineer-safe-coding.md, existing: false }
+  - { name: prompt-to-task-conversion.md, existing: false }
+  - { name: prototype-boundaries.md, existing: false }
+  - { name: ambiguity-resolution.md, existing: false }
+  - { name: autonomy-levels.md, existing: true }
+  - { name: risk-classification.md, existing: true }
+hooks:
+  - { name: warn-sensitive-files, existing: false }
+  - { name: warn-large-edits, existing: false }
+  - { name: warn-missing-tests, existing: false }

claude_kit/_payload/templates/org/packs/onboarding-and-docs/README.md

@@ -0,0 +1,49 @@
+# Onboarding & Docs
+
+Understand a repo fast and keep its documentation honest: explain modules, generate architecture docs,
+build onboarding paths, and keep docs synchronised with the code as it changes.
+
+**Primary teams:** Engineering · Support · **Default risk:** low · **Manifest:** `pack.yaml`
+
+## Who uses it
+New engineers ramping on an unfamiliar codebase, support staff who need to understand how a module
+behaves, and anyone keeping documentation in step with the code. The personas here **read and explain**;
+they never write or run code.
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated) plus one skill
+added by the org layer. It does not introduce competing agents — codebase discovery uses the built-in
+**Explore** research agent.
+
+| Need | Use |
+|------|-----|
+| Get a guided tour of an unfamiliar repo | `/repo-onboarding` → `Explore` (discovery) → `technical-architect` |
+| Discover where things live | `Explore` agent (read-only codebase search) |
+| Explain how a module works / fits together | `technical-architect` (analysis only, see `code-organization.md`) |
+| Generate or update architecture docs / ADRs | `/documentation-and-adrs` |
+| Bring docs back in sync with the code | `/refresh-docs` (the `/docs-update` flow) |
+| Ground answers in the actual source | `/source-driven-development` |
+| Curate the right context for a task | `/context-engineering` |
+| Find / understand which skills apply | `/using-agent-skills` |
+| Coordinate a multi-step onboarding | `orchestrator` agent |
+
+## Rules it leans on
+`documentation.md` (the documentation standard every change must maintain or improve) and
+`code-organization.md` (so explanations and onboarding paths describe structure accurately).
+
+## Hooks it expects
+None special — this pack is read-and-explain only, so the standard repo hooks suffice.
+
+## Examples
+```
+/repo-onboarding   # → Explore maps the repo, technical-architect explains the architecture + an onboarding path
+/docs-update Sync the docs after the checkout refactor   # → refresh-docs + documentation-and-adrs
+/repo-onboarding the data-store layer   # → focused tour of one module
+```
+
+## Autonomy & risk
+Default **low** risk: discovery, explanation, and documentation are read-mostly. These personas
+**plan and explain only** — any actual code change (including a doc fix that touches source) is handed to
+engineering and runs under the repo's autonomy level. Anything touching a sensitive area (auth, payments,
+secrets, production data, migrations, infrastructure) is at least **high** risk and goes through the
+engineering review chain with human approval (`risk-classification.md`).

claude_kit/_payload/templates/org/packs/onboarding-and-docs/pack.yaml

@@ -0,0 +1,26 @@
+# Org capability pack manifest. References components by name; they install in the standard
+# auto-discovered .claude/ locations. `existing: true` = ships with claude-kit already (reused, not
+# duplicated); `existing: false` = added by the org layer (templates/org/).
+id: onboarding-and-docs
+label: "Onboarding & Docs"
+version: 0.1.0
+purpose: >
+  Help newcomers understand the repo, generate architecture docs, explain modules, build onboarding
+  paths, and keep documentation synchronised with the code as it changes.
+teams: [engineering, support]
+risk_default: low
+
+skills:
+  - { name: repo-onboarding, existing: false }
+  - { name: documentation-and-adrs, existing: true }
+  - { name: refresh-docs, existing: true }
+  - { name: source-driven-development, existing: true }
+  - { name: context-engineering, existing: true }
+  - { name: using-agent-skills, existing: true }
+agents:
+  - { name: orchestrator, existing: true }
+  - { name: technical-architect, existing: true }
+rules:
+  - { name: documentation.md, existing: true }
+  - { name: code-organization.md, existing: true }
+hooks: []

claude_kit/_payload/templates/org/packs/product-to-code/README.md

@@ -0,0 +1,50 @@
+# Product to Code
+
+The path from intent to buildable work: turn ideas, tickets, PRDs, and customer feedback into specs,
+user stories, acceptance criteria, implementation plans, and reviewable tasks.
+
+**Primary teams:** Product · Founders · **Default risk:** medium · **Manifest:** `pack.yaml`
+
+## Who uses it
+Product managers, founders, and anyone shaping work before it reaches engineering — clarifying a fuzzy
+idea, splitting a PRD into stories, or converting a raw prompt into a scoped, safe task. The personas
+here **plan and delegate**; they never write or run code.
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated) plus a few added
+by the org layer. It does not introduce competing agents.
+
+| Need | Use |
+|------|-----|
+| Refine a rough idea into something concrete | `/idea-refine` → `pm-copilot` |
+| Get interviewed to surface requirements | `/interview-me` (see `ambiguity-resolution.md`) |
+| Turn an idea into a feature brief | `/feature-from-idea` → `pm-copilot` → `spec-doc-writer` |
+| Write a spec from a PRD | `/spec-driven-development` → `spec-doc-writer` |
+| Split a PRD into user stories | `/spec-driven-development` + `story-planner` (the `/prd-to-stories` flow) |
+| Break stories into tasks | `/planning-and-task-breakdown` → `story-planner` |
+| Bound what's in / out of scope | `/scope` |
+| Sketch UI behavior for a story | `ui-designer` (design spec only) |
+| Convert a raw prompt into a safe, scoped task | `/prompt-to-safe-task` (see `prompt-to-task-conversion.md`) |
+| Coordinate the hand-off to engineering | `orchestrator` agent |
+| Decide how risky a change is | `risk-classifier` agent (`risk-classification.md`) |
+
+## Rules it leans on
+`ambiguity-resolution.md`, `prompt-to-task-conversion.md`, `non-engineer-safe-coding.md`,
+`goal-setting-and-monitoring.md` (plus `risk-classification.md` for tiering).
+
+## Hooks it expects
+`warn-large-edits` — flags oversized changes so a plan-only flow never silently balloons into a big edit.
+
+## Examples
+```
+/feature-from-idea "Let users export their report as a shareable link"   # → spec + stories + tasks
+/prd-to-stories Onboarding checklist PRD   # → spec-driven-development + story-planner (stories + acceptance criteria)
+/prompt-to-safe-task "tidy up the settings copy"   # → scoped, approval-gated task
+```
+
+## Autonomy & risk
+Operates under the repo's autonomy level. These personas **plan and delegate only** — actual building is
+handed to engineering with explicit acceptance criteria. Anything touching a sensitive area (auth,
+payments, secrets, production data, migrations, infrastructure) is at least **high** risk: get human
+approval and route it through the engineering review chain before any code is written
+(`risk-classification.md`).