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

claude_kit/_payload/templates/org/packs/product-to-code/pack.yaml

@@ -0,0 +1,34 @@
+# 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: product-to-code
+label: "Product to Code"
+version: 0.1.0
+purpose: >
+  Turn ideas, tickets, PRDs, and customer feedback into specs, user stories, acceptance criteria,
+  implementation plans, and reviewable tasks — the path from intent to ready-to-build work.
+teams: [product, founders]
+risk_default: medium
+
+skills:
+  - { name: idea-refine, existing: true }
+  - { name: interview-me, existing: true }
+  - { name: spec-driven-development, existing: true }
+  - { name: planning-and-task-breakdown, existing: true }
+  - { name: scope, existing: true }
+  - { name: feature-from-idea, existing: false }
+  - { name: prompt-to-safe-task, existing: false }
+agents:
+  - { name: pm-copilot, existing: false }
+  - { name: spec-doc-writer, existing: true }
+  - { name: story-planner, existing: true }
+  - { name: ui-designer, existing: true }
+  - { name: orchestrator, existing: true }
+  - { name: risk-classifier, existing: true }
+rules:
+  - { name: ambiguity-resolution.md, existing: false }
+  - { name: prompt-to-task-conversion.md, existing: false }
+  - { name: non-engineer-safe-coding.md, existing: false }
+  - { name: goal-setting-and-monitoring.md, existing: true }
+hooks:
+  - { name: warn-large-edits, existing: false }

claude_kit/_payload/templates/org/packs/quality-and-review/README.md

@@ -0,0 +1,53 @@
+# Quality & Review
+
+The verification loop: test planning, regression analysis, PR review, security review, performance
+review, accessibility review, and acceptance review — everything that gates a change before it ships.
+
+**Primary teams:** QA · Engineering · **Default risk:** medium · **Manifest:** `pack.yaml`
+
+## Who uses it
+QA engineers and any engineer wearing a reviewer or tester hat — the pack for verifying work, not
+producing it. Pairs with `engineering-core` (which builds) and `security-and-compliance` (deeper
+security gates).
+
+## Role → component mapping
+This pack bundles components that already ship with claude-kit (reused, not duplicated). It introduces
+no competing agents — every reviewer and tester role maps to an existing pipeline agent.
+
+| Need | Use |
+|------|-----|
+| Review a PR / change for correctness and quality | `/code-review-and-quality` → `sdlc-code-reviewer` |
+| Plan and write tests before/with the change | `/test-driven-development` → `tester` |
+| Add or strengthen unit coverage | `/unit-test` → `unit-tester` |
+| Verify end-to-end / acceptance flows | `e2e-tester` (then `acceptance-reviewer`) |
+| Independently re-verify coverage and findings | `senior-tester` |
+| Security review of the change | `/security-verification` (`threat-model` for design risk) |
+| Performance review / regression check | `/performance-optimization` |
+| Accessibility review | `/accessibility-review` |
+| Stress-test a unanimous PASS (anti-sycophancy) | `devils-advocate` |
+| Probe assumptions before approving | `/doubt-driven-development` |
+| Manual / smoke check before sign-off | `/manual-test`, `/smoke-test` |
+| Confirm cross-stream coverage has no gaps | `merge-reviewer` |
+
+## Rules it leans on
+`quality-gates.md` (severity model + blind review + Devil's Advocate), `testing.md` (coverage
+expectations and lanes), `rarv-cycle.md` (every reviewer shows a green Verify before handoff).
+
+## Hooks it expects
+`warn-missing-tests` (flags changes that touch behavior without test coverage), plus `lint-fix` and
+`type-check` so review starts from a clean baseline.
+
+## Examples
+```
+/review-pr Check the latest change to the items service                # → code-review-and-quality
+/write-tests Add regression coverage for the failed-login path         # → test-driven-development
+/security-verification Review the new file-upload handler              # → security-verification
+/accessibility-review Audit the new settings screen                    # → accessibility-review
+```
+
+## Autonomy & risk
+Reviewers and testers **plan and delegate only** — they do not write or run application code; they
+verify, classify findings (Critical/High/Medium/Low/Cosmetic), and gate. A gate passes only with zero
+Critical/High/Medium open (`quality-gates.md`). Anything in a sensitive area (auth, payments, secrets,
+migrations, infrastructure) is at least **high** risk and requires security + test review plus explicit
+human approval before the gate counts (`.claude/rules/risk-classification.md`).

claude_kit/_payload/templates/org/packs/quality-and-review/pack.yaml

@@ -0,0 +1,40 @@
+# 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: quality-and-review
+label: "Quality & Review"
+version: 0.1.0
+purpose: >
+  Standardise test planning, regression analysis, PR review, security review, performance review,
+  accessibility review, and acceptance review — the verification loop that gates every change.
+teams: [qa, engineering]
+risk_default: medium
+
+skills:
+  - { name: code-review-and-quality, existing: true }
+  - { name: test-driven-development, existing: true }
+  - { name: unit-test, existing: true }
+  - { name: security-verification, existing: true }
+  - { name: performance-optimization, existing: true }
+  - { name: accessibility-review, existing: true }
+  - { name: threat-model, existing: true }
+  - { name: doubt-driven-development, existing: true }
+  - { name: manual-test, existing: true }
+  - { name: smoke-test, existing: true }
+agents:
+  - { name: sdlc-code-reviewer, existing: true }
+  - { name: senior-tester, existing: true }
+  - { name: unit-tester, existing: true }
+  - { name: e2e-tester, existing: true }
+  - { name: tester, existing: true }
+  - { name: devils-advocate, existing: true }
+  - { name: acceptance-reviewer, existing: true }
+  - { name: merge-reviewer, existing: true }
+rules:
+  - { name: quality-gates.md, existing: true }
+  - { name: testing.md, existing: true }
+  - { name: rarv-cycle.md, existing: true }
+hooks:
+  - { name: warn-missing-tests, existing: false }
+  - { name: lint-fix, existing: true }
+  - { name: type-check, existing: true }

claude_kit/_payload/templates/org/packs/security-and-compliance/README.md

@@ -0,0 +1,50 @@
+# Security & Compliance
+
+The guardrail layer: prevent secrets exposure, insecure code, unsafe commands, dependency risks, auth
+flaws, data leakage, and unreviewed sensitive changes.
+
+**Primary teams:** Security · DevOps · **Default risk:** high · **Manifest:** `pack.yaml`
+
+## Who uses it
+Security engineers and DevOps owners who review changes, set policy, and gate sensitive work — plus any
+engineer touching a restricted surface (auth, secrets, production data, infrastructure). It runs
+alongside the everyday loop, not instead of it.
+
+## Role → component mapping
+This pack reuses the security components that already ship with claude-kit (no competing agents) and
+adds four policy rules plus three hooks at the org layer.
+
+| Need | Use |
+|------|-----|
+| Harden code / fix an insecure pattern | `/security-and-hardening` → `security-reviewer` |
+| Verify a change is safe before merge | `/security-verification` → `security-reviewer` |
+| Model threats for a feature | `/threat-model` → `security-reviewer` |
+| Audit dependencies for known risk | `/security-verification` → `dependency-scanner` |
+| Find leaked secrets / credentials | `secret-scanner` agent (`secrets-policy.md`) |
+| Check OWASP-class flaws (auth, injection, access control) | `owasp-reviewer` agent |
+| Confirm a change meets policy | `policy-validator` agent (`compliance-policy.md`) |
+| Decide how risky / restricted a change is | `risk-classifier` agent (`risk-classification.md`) |
+
+These agents **plan and delegate** — they review, classify, and flag; they do not write or run code.
+
+## Rules it leans on
+`secrets-policy.md`, `pii-policy.md`, `production-data-policy.md`, `compliance-policy.md`,
+`agent-guardrails.md`, `risk-classification.md`.
+
+## Hooks it expects
+`protect-secrets`, `guard-commit-secrets`, and (added by the org layer) `warn-sensitive-files`,
+`validate-settings`, `audit-log`. Security-relevant hooks change only through review by the owning team.
+
+## Examples
+```
+/security-review Harden the session-handling path before launch       # → security-and-hardening
+/threat-model Map the abuse cases for the new public upload endpoint   # → threat-model
+/dependency-audit Flag risky/outdated packages in the data store layer # → security-verification + dependency-scanner
+```
+
+## Autonomy & risk
+Default risk is **high** — this is the pack that enforces the line. Any work in a sensitive area (auth,
+secrets, production data, PII, migrations, infrastructure) requires a plan, explicit human approval,
+security + test review, and rollback notes before it proceeds, regardless of autonomy level
+(`risk-classification.md`, `agent-guardrails.md`). Secrets and production data never enter the
+repo, logs, or prompts (`secrets-policy.md`, `production-data-policy.md`, `pii-policy.md`).

claude_kit/_payload/templates/org/packs/security-and-compliance/pack.yaml

@@ -0,0 +1,36 @@
+# 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: security-and-compliance
+label: "Security & Compliance"
+version: 0.1.0
+purpose: >
+  Prevent secrets exposure, insecure code, unsafe shell commands, dependency risks, auth flaws, data
+  leakage, and unreviewed sensitive changes — the guardrails that keep delivery safe and compliant.
+teams: [security, devops]
+risk_default: high
+
+skills:
+  - { name: security-and-hardening, existing: true }
+  - { name: security-verification, existing: true }
+  - { name: threat-model, existing: true }
+agents:
+  - { name: security-reviewer, existing: true }
+  - { name: secret-scanner, existing: true }
+  - { name: dependency-scanner, existing: true }
+  - { name: owasp-reviewer, existing: true }
+  - { name: policy-validator, existing: true }
+  - { name: risk-classifier, existing: true }
+rules:
+  - { name: secrets-policy.md, existing: false }
+  - { name: pii-policy.md, existing: false }
+  - { name: production-data-policy.md, existing: false }
+  - { name: compliance-policy.md, existing: false }
+  - { name: agent-guardrails.md, existing: true }
+  - { name: risk-classification.md, existing: true }
+hooks:
+  - { name: protect-secrets, existing: true }
+  - { name: guard-commit-secrets, existing: true }
+  - { name: warn-sensitive-files, existing: false }
+  - { name: validate-settings, existing: false }
+  - { name: audit-log, existing: false }

claude_kit/_payload/templates/org/rules/ai-working-agreement.md

@@ -0,0 +1,45 @@
+# AI Working Agreement
+
+This is the charter for how humans and Claude work together in this project. It is the umbrella over
+the organization capability layer: a short summary of the contract, with each clause pointing at the
+rule that defines it in full. When the rules below conflict, the stricter one wins.
+
+## The agreement
+
+1. **Plan before large edits.** State the goal, scope, and steps before changing anything beyond a
+   trivial fix; turn a raw prompt into a scoped, verifiable task first.
+   See `.claude/rules/prompt-to-task-conversion.md` and `.claude/rules/mandatory-workflow.md`.
+2. **Stay within the granted autonomy level.** Act only as far as you're authorized; if the task needs
+   more autonomy than granted, stop and ask. See `.claude/rules/autonomy-levels.md`.
+3. **Classify the risk of every change** as low / medium / high / restricted, and apply the matching
+   protocol. See `.claude/rules/risk-classification.md`.
+4. **Ask when unsure.** Resolve ambiguity instead of guessing; never invent a missing requirement.
+   See `.claude/rules/human-in-the-loop.md`.
+5. **Make it safe for non-engineers.** Explain in plain language, keep changes reversible, and use the
+   guardrails for vibe-coding. See `.claude/rules/non-engineer-safe-coding.md`.
+6. **Never touch secrets, production data, or PII without approval.** No reading, writing, copying, or
+   exposing them outside the sanctioned path. See `.claude/rules/secrets-policy.md`,
+   `.claude/rules/production-data-policy.md`, and `.claude/rules/pii-policy.md`.
+7. **Always test and review.** Every change meets the project's linter / test runner / build and passes
+   review before it ships. See `.claude/rules/quality-gates.md`.
+8. **Use branches and PRs; never push to the protected branch directly.**
+   See `.claude/rules/branch-and-pr-policy.md`.
+9. **Get human approval for high- and restricted-risk work**, and respect any regulatory obligations.
+   See `.claude/rules/human-in-the-loop.md` and `.claude/rules/compliance-policy.md`.
+
+## Rules
+
+- **This charter only summarizes.** The linked rule is always the source of truth for its clause;
+  read it before acting in that area.
+- **The strictest applicable rule applies.** A higher risk tier or a stricter policy overrides a more
+  permissive default.
+- **The workflow is non-negotiable.** No clause here lets you skip the pipeline or its gates
+  (`.claude/rules/mandatory-workflow.md`, `.claude/rules/quality-gates.md`).
+
+> Part of claude-kit's organization capability layer (vibe-coding). It points at, and is bound by,
+> `.claude/rules/autonomy-levels.md`, `.claude/rules/risk-classification.md`,
+> `.claude/rules/human-in-the-loop.md`, `.claude/rules/prompt-to-task-conversion.md`,
+> `.claude/rules/non-engineer-safe-coding.md`, `.claude/rules/secrets-policy.md`,
+> `.claude/rules/production-data-policy.md`, `.claude/rules/pii-policy.md`,
+> `.claude/rules/branch-and-pr-policy.md`, `.claude/rules/compliance-policy.md`,
+> `.claude/rules/mandatory-workflow.md`, and `.claude/rules/quality-gates.md`.

claude_kit/_payload/templates/org/rules/ambiguity-resolution.md

@@ -0,0 +1,36 @@
+# Ambiguity Resolution
+
+When a request is unclear, the choice is **ask or assume** — and the wrong call is expensive either way:
+a needless question stalls flow; a silent guess ships the wrong thing. This rule sets the line so agents
+ask when it matters and proceed when it doesn't.
+
+## Ask when
+
+1. **The goal is unclear** — you can't state in one sentence what "done" means.
+2. **The scope is unclear** — you don't know which areas it should (and should not) touch.
+3. **Success is unmeasurable** — there's no test, check, or observable behavior that proves it works.
+4. **Interpretations compete** — two or more readings would lead to materially different work.
+5. **It's high-risk** — auth, payments, secrets, production data, migrations, or infrastructure are
+   involved. Default to **asking** here even if you have a plausible default (`.claude/rules/risk-classification.md`).
+
+## Assume when
+
+- A sensible default exists, the cost of being wrong is low, and the work is easy to reverse. **State the
+  assumption out loud and proceed** — don't manufacture a question for a choice you can safely make.
+
+## Rules
+
+- **Present competing interpretations; never silently pick one.** When readings diverge, lay out each
+  option with its trade-off and your recommendation — let the human choose.
+- **Record assumptions explicitly.** Surface every inference so a human can correct it before it hardens
+  into shipped work. Never fabricate a missing requirement — reasoning cannot supply a fact you were
+  never given.
+- **Keep questions few and high-leverage.** Batch the smallest set that unblocks the most work; ask the
+  question whose answer changes what you build, not trivia. One question at a time when extracting intent.
+- **Bias to asking as risk rises.** A cheap question now beats an expensive wrong-direction unwind later;
+  the higher the risk tier, the lower the bar for stopping.
+
+> Part of claude-kit's organization capability layer (vibe-coding). Cross-refs
+> `.claude/rules/prompt-to-task-conversion.md`, `.claude/rules/human-in-the-loop.md`,
+> `.claude/rules/risk-classification.md`. The `interview-me` and `idea-refine` skills extract true intent
+> one question at a time when a request is underspecified.

claude_kit/_payload/templates/org/rules/branch-and-pr-policy.md

@@ -0,0 +1,41 @@
+# Branch & PR Policy
+
+Code reaches the main line through one path only: a feature branch, a small reviewed pull request, and
+a merge after approval. Never commit straight to `main`/`master`, and never push to it directly — the
+`guard-push-main` hook blocks it, but the policy holds even where no hook runs.
+
+## Always work on a branch
+
+1. **Branch from the main line** for every change — features, fixes, docs, config. One branch per task.
+2. **Name it for the work** — a short, descriptive slug (e.g. `feat/<thing>`, `fix/<thing>`); avoid
+   long-lived shared branches that drift.
+3. **Keep `main` releasable.** It builds, passes the project's test runner and linter, and is never the
+   target of a direct commit or push.
+
+## Keep PRs small and single-purpose
+
+- **One concern per PR.** A PR does one thing — don't bundle a refactor, a feature, and a config change.
+  If it grows, split it.
+- **Smallest reviewable diff** that delivers the change; large PRs hide defects and slow review.
+- **No drive-by edits.** Touch only what the task needs (see the surgical-changes rule of conduct).
+
+## Write a clear PR
+
+Every PR description states, in plain language:
+
+1. **What & why** — the change and the reason for it, not just the mechanism.
+2. **Scope** — what it touches, and what it deliberately leaves out.
+3. **How it was verified** — tests, checks, or observable behavior proving it works.
+4. **Checklist** — gates passed, docs updated, no secrets, breaking changes called out.
+
+## Review before merge
+
+- **Human review is required** before merge — at least one approval. Code review is a quality gate, not
+  a formality (`.claude/rules/quality-gates.md`).
+- **Quality gates pass first.** Build, linter, tests, and security checks are green before review counts.
+- **Merging is an outward-facing, hard-to-reverse action** — it stays within the granted autonomy level
+  (`.claude/rules/autonomy-levels.md`); opening or merging to a protected branch needs human approval.
+
+> Part of claude-kit's organization capability layer. Enforced by the `guard-push-main` hook. The
+> `/git-workflow-and-versioning` skill drives branching and PRs interactively, and the `pr-raiser` agent
+> opens the PR. Cross-refs `.claude/rules/quality-gates.md`, `.claude/rules/autonomy-levels.md`.

claude_kit/_payload/templates/org/rules/compliance-policy.md

@@ -0,0 +1,50 @@
+# Compliance Policy
+
+When review strictness is set to **regulated**, ordinary delivery is not enough: the work must be
+**auditable, signed-off, and change-controlled**. This rule adds the extra obligations that apply to
+regulated work, on top of the normal pipeline. It is standard-neutral — it names *what* evidence and
+control to keep, not which framework demands it.
+
+## When this applies
+
+Regulated mode is on when the org config sets review strictness to `regulated`, or when a task touches a
+compliance-sensitive area (audited flows, financial records, regulated data, anything classified at least
+**high** per `.claude/rules/risk-classification.md`). When in doubt, treat it as regulated.
+
+## What regulated work requires
+
+1. **Audit trail** — keep a local, append-only record of who/what/when for every gated action. The
+   **audit-log** hook writes it; never disable or edit it. The trail must let a reviewer reconstruct the
+   change after the fact.
+2. **Human sign-offs at gates** — a named human must approve at each gate; an agent PASS is not a
+   sign-off. Record the approver and time alongside the gate result.
+3. **Evidence of passes** — retain proof that the review, security, and test gates passed: reviewer
+   notes, the **security-clear** result (secret/dependency/OWASP/policy scans), and test/coverage
+   reports. Link each to the change it covers.
+4. **Change control** — no change reaches a protected branch without a tracked request: spec, approvals,
+   evidence, and rollback notes attached. Follow `.claude/rules/branch-and-pr-policy.md`.
+
+## Extra gates (beyond the normal pipeline)
+
+| Gate | Owner | Passes when |
+|------|-------|-------------|
+| **security-clear** | `security-reviewer` (+ sub-scanners) | zero Critical/High/Medium open; secrets, dependency, and policy scans clean |
+| **acceptance** | `acceptance-reviewer` | every acceptance criterion is met **and** signed off by a named human |
+
+Both gates are mandatory in regulated mode and run before the PR. A failed gate blocks delivery and is
+recorded in the audit trail — never waive a gate silently.
+
+## Rules
+
+- **Evidence before assertion.** Do not claim a gate passed without the artifact that proves it.
+- **Sign-offs are scoped.** Approval covers one change in one context; re-confirm for each gated step
+  (`.claude/rules/quality-gates.md`).
+- **Secrets and PII stay protected.** Apply `.claude/rules/secrets-policy.md` and
+  `.claude/rules/pii-policy.md`; a violation is an auto-Critical that blocks every gate.
+- **Tamper-evidence.** Any attempt to disable the audit-log hook or remove evidence is a restricted
+  action — stop and escalate to a human.
+
+> Part of claude-kit's organization capability layer. Cross-refs
+> `.claude/rules/risk-classification.md`, `.claude/rules/quality-gates.md`,
+> `.claude/rules/secrets-policy.md`, `.claude/rules/pii-policy.md`. Enforced by the **audit-log** hook
+> and the **security-clear** / **acceptance** gates.

claude_kit/_payload/templates/org/rules/non-engineer-safe-coding.md

@@ -0,0 +1,37 @@
+# Non-Engineer-Safe Coding
+
+When a non-engineer drives the work — a founder, PM, support agent, or operator describing what they
+want — the agent supplies the engineering judgment they cannot. The driver owns the *intent*; the agent
+owns *how it's built safely*. These guardrails keep "just make it do X" from quietly becoming a risky
+change nobody reviewed.
+
+## Guardrails
+
+1. **Clarify intent before acting.** Turn the request into a goal, scope, and success criteria first;
+   if any is unclear, ask in plain language — don't guess. See
+   `.claude/rules/prompt-to-task-conversion.md` and `.claude/rules/ambiguity-resolution.md`.
+2. **Smallest safe scope.** Make the minimal change that meets the goal. State an explicit out-of-scope
+   line and never silently expand it.
+3. **Never touch sensitive areas without an engineer.** Auth, payments, secrets, production data,
+   migrations, and infrastructure are off-limits to a non-engineer-driven change — stop and bring in an
+   engineer (these are at least **high** risk per `.claude/rules/risk-classification.md`).
+4. **Always require tests + review.** No change ships without the project's test runner passing and a
+   human review. Don't lower the quality bar because the driver isn't technical.
+5. **Human approval before implementation.** Present the plan and get an explicit yes before editing —
+   stay within `.claude/rules/autonomy-levels.md`; if the task needs more autonomy than granted, ask.
+6. **Plain-language summaries.** Before and after, say in non-technical terms *what will change and why*,
+   and *what to verify*. The driver must be able to confirm it's right without reading code.
+
+## When to STOP and escalate
+
+- The request reaches a sensitive area (rule 3), or risk classifies as high/restricted.
+- Intent, scope, or "done" can't be made concrete after asking once.
+- The safe change is larger than the driver expects, or needs a dependency, config, or data change.
+
+When you stop, follow the escalation protocol in `.claude/rules/human-in-the-loop.md`: state the
+decision, why it's a stop, the options with a recommendation, and what's safe to do meanwhile.
+
+> Part of claude-kit's organization capability layer (vibe-coding). Cross-refs
+> `.claude/rules/prompt-to-task-conversion.md`, `.claude/rules/ambiguity-resolution.md`,
+> `.claude/rules/autonomy-levels.md`, `.claude/rules/risk-classification.md`,
+> `.claude/rules/human-in-the-loop.md`. The `prompt-to-safe-task` skill applies this rule interactively.

claude_kit/_payload/templates/org/rules/pii-policy.md

@@ -0,0 +1,46 @@
+# PII Policy
+
+Personally identifiable information (PII) is any data that identifies a person — names, emails,
+phone numbers, addresses, government IDs, location, device IDs, health or financial details. Treat
+it as a liability, not an asset: the safest PII is the data you never collected. Identify it early
+and handle it under this policy for the whole task.
+
+## Identify PII first
+
+1. **Spot it at intake.** When a prompt or spec involves user data, name which fields are PII before
+   designing anything. If unsure whether a field is PII, treat it as PII (see
+   `.claude/rules/ambiguity-resolution.md`).
+2. **Minimise collection.** Capture only the fields the goal actually needs; drop or aggregate the
+   rest. Prefer a non-identifying token over the raw value where one will do.
+3. **Mark the boundary.** Note where PII enters, where it is stored, and where it leaves — so every
+   later step knows what it is handling.
+
+## Handling rules
+
+- **Never log PII.** No PII in application logs, console output, traces, metrics, analytics events,
+  or error reports — redact or hash before anything is written out. Same bar as secrets
+  (`.claude/rules/secrets-policy.md`).
+- **Encrypt in transit and at rest.** PII moves only over encrypted transport and is stored only in
+  the project's encrypted data store; no plaintext PII in flat files, tickets, or chat.
+- **Enforce access controls.** Least privilege — only the components and roles that need a field may
+  read it. No broad "read everything" access to PII stores.
+- **Limit retention.** Keep PII only as long as the goal requires, then delete or anonymise it;
+  never retain "just in case." Honour any deletion request.
+- **Scrub fixtures and test data.** Use synthetic or anonymised data in tests, seeds, and demos —
+  never real PII (`.claude/rules/production-data-policy.md`).
+- **Scrub error reports.** Strip PII from stack traces, crash dumps, and bug reports before they
+  leave the system or reach a third party.
+
+## Rules
+
+1. **When in doubt, redact.** Withholding a field is cheap; leaking one is not reversible — it may be
+   cached, indexed, or shipped before anyone notices.
+2. **Escalate exposure.** Any PII in a log, fixture, or external payload is at least **high** risk
+   (`.claude/rules/risk-classification.md`) — stop, report it, and get a human decision
+   (`.claude/rules/human-in-the-loop.md`).
+3. **Don't move PII across boundaries** (new store, external service, lower environment) without
+   explicit approval.
+
+> Part of claude-kit's organization capability layer. Cross-refs `.claude/rules/secrets-policy.md`,
+> `.claude/rules/production-data-policy.md`, `.claude/rules/compliance-policy.md`. The
+> `security-reviewer` and `policy-validator` agents enforce this at the gate.

claude_kit/_payload/templates/org/rules/production-data-policy.md

@@ -0,0 +1,35 @@
+# Production Data Policy
+
+Never operate on production data without explicit, recorded human approval. Production data is the
+highest-trust surface in the project — getting it wrong is rarely reversible. Default to synthetic,
+sample, or anonymised data for every build, test, and demo; touch the real data store only when there
+is no safe alternative and a human has said yes in writing.
+
+## Default posture
+
+1. **Prefer fake data.** Use synthetic, sample, or anonymised fixtures for development, tests, and
+   prototypes. If you need realistic data, generate or anonymise it — never copy production records.
+2. **No destructive operations against production.** No deletes, overwrites, bulk updates, truncation,
+   or schema drops on the live data store. These are at least **high** risk per
+   `.claude/rules/risk-classification.md`.
+3. **Least-privilege read only.** Read access to production is granted only when justified, scoped to
+   what the task needs, and time-boxed. Never request write access by default.
+4. **No exfiltration.** Don't copy production data into logs, prompts, fixtures, screenshots, or
+   external services. Personal data is additionally governed by `.claude/rules/pii-policy.md`.
+
+## Rules
+
+- **Explicit, recorded approval.** Any operation on production data stops and asks a human; record who
+  approved, what was approved, and when. See `.claude/rules/human-in-the-loop.md`.
+- **Approval is scoped and single-use.** Permission for one read/operation does not extend to the next
+  or to a wider dataset — re-confirm each time.
+- **Migrations follow the high-risk protocol.** A migration that runs against production is high risk:
+  write a plan, capture rollback notes (how to undo, and the point of no return), get approval before
+  running, and report the outcome faithfully — including failures.
+- **State the blast radius.** Before any approved operation, say what it touches, how many records, and
+  whether it can be undone, so the human can weigh the cost of getting it wrong.
+
+> Part of claude-kit's organization capability layer. Cross-refs
+> `.claude/rules/risk-classification.md`, `.claude/rules/pii-policy.md`, and
+> `.claude/rules/human-in-the-loop.md`. Sensitive-area escalation is also wired into
+> `.claude/rules/prompt-to-task-conversion.md`.

claude_kit/_payload/templates/org/rules/prompt-to-task-conversion.md

@@ -0,0 +1,30 @@
+# Prompt → Task Conversion
+
+A natural-language prompt is not yet a safe task. Before acting on any free-form request — especially
+from a non-engineer — convert it into a scoped, risk-classified, verifiable task. This is the front door
+for vibe-coding; it makes "just build X" safe.
+
+## Convert every prompt into
+
+1. **Goal** — the outcome in one sentence (what "done" means), not the mechanism.
+2. **Scope** — the files/areas it should touch, and an explicit **out-of-scope** line.
+3. **Risk tier** — low / medium / high / restricted per `.claude/rules/risk-classification.md`.
+4. **Success criteria** — how the result will be verified (tests, a check, an observable behavior).
+5. **Plan** — the ordered steps; for anything above low risk, write it down before editing.
+6. **Approval point** — who must say yes, and before which step (see below).
+
+## Rules
+
+- **Resolve ambiguity first.** If the goal, scope, or success is unclear, ask — do not guess. See
+  `.claude/rules/ambiguity-resolution.md`.
+- **Smallest safe scope.** Prefer the minimal change that meets the goal; never silently expand scope.
+- **Match the autonomy level.** Stay within `.claude/rules/autonomy-levels.md`; if the task needs more
+  autonomy than granted, stop and ask.
+- **Sensitive areas escalate automatically.** Auth, payments, secrets, production data, migrations, and
+  infrastructure are at least **high** risk — apply the high-risk protocol and get explicit approval.
+- **State assumptions.** Surface what you inferred so a human can correct it before work proceeds.
+
+> Part of claude-kit's organization capability layer (vibe-coding). Cross-refs
+> `.claude/rules/non-engineer-safe-coding.md`, `.claude/rules/ambiguity-resolution.md`,
+> `.claude/rules/risk-classification.md`, `.claude/rules/autonomy-levels.md`. The `prompt-to-safe-task`
+> skill applies this rule interactively.

claude_kit/_payload/templates/org/rules/prototype-boundaries.md

@@ -0,0 +1,40 @@
+# Prototype Boundaries
+
+A prototype exists to learn — to answer a question, prove a flow, or show an idea — not to serve real
+users. It runs under relaxed process so it can move fast, which is only safe while its blast radius stays
+tiny. The moment a prototype is meant to handle real traffic, data, or money, it stops being a prototype
+and must be hardened first.
+
+## A prototype MAY
+
+- Use fake, synthetic, or seeded sample data; placeholder copy; and throwaway accounts.
+- Skip the full review chain and run under the lighter non-engineer flow (`.claude/rules/non-engineer-safe-coding.md`).
+- Cut corners on edge cases, polish, and breadth — enough to demonstrate the idea, no more.
+- Live in a clearly disposable place (a scratch branch, a sandbox, a demo space) labeled **PROTOTYPE**.
+
+## A prototype MUST NOT
+
+- **Use real secrets** — no live API keys, tokens, or credentials (`.claude/rules/secrets-policy.md`).
+- **Touch production data** — no real customer or user records, read or write (`.claude/rules/production-data-policy.md`).
+- **Reach real users or external systems** — no production endpoints, no money movement, no outbound
+  messages to real people.
+- **Be silently promoted.** Shipping a prototype as-is is forbidden; promotion goes through the checklist.
+
+## Hardening checklist — required BEFORE promotion to production
+
+A prototype is **medium or higher** risk once promotion is proposed (`.claude/rules/risk-classification.md`).
+Every item below must pass before it serves real traffic or data:
+
+- [ ] **Input validation** — all external input is validated and rejected when malformed.
+- [ ] **Authn / authz** — real authentication and authorization replace any bypass or stub.
+- [ ] **Error handling** — failures are caught and handled; no crashes or leaked internals on bad input.
+- [ ] **Structured logging** — observable events are logged (no secrets/PII), per `.claude/rules/devops-observability.md`.
+- [ ] **Tests** — meaningful tests exist and pass via the project's test runner (`.claude/rules/testing.md`).
+- [ ] **Rate limiting / quotas** — abuse and runaway cost are bounded.
+- [ ] **Real data & secrets swapped in** — synthetic data and placeholder keys replaced by managed ones.
+- [ ] **Review** — the change goes through the full review chain (`.claude/rules/mandatory-workflow.md`).
+
+> Part of claude-kit's organization capability layer (vibe-coding). Cross-refs
+> `.claude/rules/risk-classification.md`, `.claude/rules/non-engineer-safe-coding.md`,
+> `.claude/rules/production-data-policy.md`, `.claude/rules/secrets-policy.md`. The
+> `prototype-to-production` skill applies this rule and walks the hardening checklist.

claude_kit/_payload/templates/org/rules/secrets-policy.md

@@ -0,0 +1,34 @@
+# Secrets Policy
+
+Secrets are never code. API keys, passwords, tokens, private keys, connection strings, and signing
+material must never be read into context, printed, logged, committed, or pasted into a chat. This rule
+makes "just make it work with my key" safe — credentials stay out of the repo and out of the model.
+
+## Never do
+
+1. **Read or open** a secret-bearing file (`.env`, key files, credential dumps) to "see what's there".
+2. **Print or log** a secret value — not in output, not in a debug line, not in an error message.
+3. **Commit or push** a secret — config files, fixtures, and history all count.
+4. **Hardcode** a credential inline instead of referencing an environment variable or secret manager.
+5. **Echo a secret back** to the user or any external service.
+
+## Do instead
+
+- **Reference, don't embed.** Read secrets from environment variables or the project's secret manager
+  at runtime; the code names the variable, never the value.
+- **Keep a `.env.example`** with placeholder keys (no real values) so others know what to provide.
+- **Gitignore real secret files** (`.env` and friends); only the example is tracked.
+- **Rotate immediately on exposure.** If a secret is ever printed, logged, or committed, treat it as
+  compromised: rotate it, then purge it from history — do not just delete the line.
+- **Ask before touching** anything that looks secret-bearing; stop and escalate rather than guess.
+
+## Enforcement
+
+- The **protect-secrets** hook blocks reads of secret-bearing paths; the **guard-commit-secrets** hook
+  blocks commits that contain credential patterns. Do not work around either — if one trips, stop.
+- The **secret-scanner** agent audits a change for leaked credentials before delivery; a finding is at
+  least **high** risk and blocks the security gate.
+
+> Part of claude-kit's organization capability layer. Cross-refs `.claude/rules/agent-guardrails.md`
+> (privilege/guardrail trips), `.claude/rules/pii-policy.md` (personal data handling), and
+> `.claude/rules/compliance-policy.md` (regulatory obligations on exposure).