What is this?

Claude Code is brilliant at single tasks — but a real change is never just one task. It's a spec, a
plan, code, review, tests, a security pass, a PR. claude-kit turns that whole lifecycle into a
pipeline of focused agents and installs it into Claude Code as configuration.

Your request flows through specialists — a spec writer, a developer, independent reviewers, testers,
security scanners, a PR raiser — coordinated by an Orchestrator that runs independent work in
parallel and refuses to advance until each phase's quality gate passes. Choose your stack, rigor,
and team scope at init; everything else adapts.

Use claude-kit if you drive real repository changes with Claude Code and want a repeatable
spec → review → test → security → PR workflow whose quality gates won't advance on an unproven verdict.

Skip it if you want a small prompt pack, don't want project config written into your repo, or need a
standalone runtime/daemon. claude-kit is configuration for Claude Code, not a separate runtime — and
its guard hooks are convenience guardrails (they need jq + a POSIX shell and no-op without them), not
a hardened security boundary. See Known limitations.

Quick start

The fastest path to a gated run — no CLI install, no init, no restart:

/plugin marketplace add ajyadav013/claude-kit
/plugin install claude-kit
/claude-kit:sdlc Add a /health endpoint that returns the build version

That's the whole loop in three lines: the standard pipeline runs immediately — spec → review →
build → test, gate by gate — with every verdict backed by real output.

Proof it works: examples/real-run/ is a genuine captured run where the
devils-advocate caught a Medium bug a unanimous review missed, and the gate refused to advance
until it was fixed.

When you want the pipeline tuned to your repo — your stack, commands, rigor profile, and the
safety hooks — run init:

/claude-kit:init        # Claude asks you the questions in chat, then runs the CLI non-interactively
# ↻ restart Claude Code so the project's agents, skills & hooks load
/sdlc Add a CSV export button to the reports page

/claude-kit:init needs the Python CLI on PATH (pipx install claude-code-kit) — it resolves
your stack/profile and records checksums for safe upgrade. Details: docs/install.md.

pip install claude-code-kit             # note: the pip name is claude-code-kit, not claude-kit

claude-kit init                 # interactive: prompts for stack, profile, MCP
claude-kit init --defaults      # non-interactive: React + Python/FastAPI + Postgres + standard

Prerequisites: Claude Code; Python ≥ 3.9 for the CLI;
jq for the shell hooks (they no-op without it). Windows users: run inside WSL or Git Bash for
the hooks. Every install question, the init.yaml format, what lands on disk, and plugin-update
steps: docs/install.md.

What you get

Profiles (lean · standard · enterprise), team scopes, autonomy levels, and org capability
packs decide how much of this actually installs — see
Profiles & what lands in your project.

How it works

Four ideas do the heavy lifting:

1. Evidence or it didn't happen. Every gate verdict — PASS or FAIL — must cite the command that
   ran and its captured output. A verdict that's invented, assumed, or read off still-running work
   is an auto-Critical finding — the same severity as a hardcoded secret
   (quality-gates.md §2.5).
2. Quality gates with a shared severity model. Every finding is classified
   Critical / High / Medium / Low / Cosmetic. A gate passes only with zero Critical/High/Medium
   open. No silent advancement.
3. RARV self-check. Every agent runs Reason → Act → Reflect → Verify and must show
   a green Verify (real commands run, not imagined) before handing off.
4. Blind review + Devil's Advocate. Parallel reviewers judge independently; a unanimous PASS
   triggers an adversarial devils-advocate pass before the gate may close — an explicit guard
   against agents rubber-stamping each other.

See docs/architecture.md for the full diagrams, including how one source
of truth ships as both a plugin and a pip package.

The pipeline

/sdlc reads the profile you chose and runs only that profile's gates:

flowchart TD
    REQ(["/sdlc request"]) --> CLS{"Classify"}
    CLS -->|"feature"| SPEC["Spec & Dev Docs"]
    SPEC --> EM{{"Gate: EM approved"}}
    EM -->|"pass"| STORY["Story breakdown + coverage gate<br/>story-planner"]
    STORY --> LANES["Parallel lanes:<br/>Senior Dev → Architect → Developer → Code Review"]
    LANES --> MR{{"Gate: Merge Reviewer"}}
    MR --> TEST["Unit · E2E · Integration + Senior verification"]
    TEST --> TCG{{"Gate: Test coverage<br/>+ Devil's Advocate"}}
    TCG --> SEC{{"Gate: Security Clear"}}
    SEC --> OPS{{"Gates: Pipeline Green ·<br/>Observability Ready · Acceptance"}}
    OPS --> PR["PR Raiser"] --> HUMAN(["Human review + deploy"])
    CLS -->|"fast-track (<5 files)"| FT["Developer → Review → Test → PR"] --> HUMAN

* contract-clear (API breaking-change diff) self-skips when the stack exposes no API surface.
A fast-track mode collapses small changes (< 5 files) to Developer → Code Reviewer → Tester → PR;
organization scope at regulated strictness adds accessibility-clear (WCAG-AA on changed UI).

See the real captured run in examples/real-run/ — a feature driven through
every gate on a Go project, with the verbatim state file, agent verdicts, diff, and an asciicast —
or the synthetic walkthrough of the default stack. To
capture your own publishable run: docs/capture-a-real-run.md.

Profiles & what lands in your project

The profile you pick decides how much lands in .claude/. Measured on a React + FastAPI +
PostgreSQL project, individual scope:

• Rules are profile-independent — every profile installs the same 25 core rules + the selected
  stack's overlays (11 for this stack = 36); rigor changes the agents and gates, not the rule set.
• Installs are stack-true — every lane offers none, and a lane you don't have installs
  nothing: a backend-only project gets no React rules, frontend skills, or npm commands.
• enterprise installs the whole skill collection — including stacks you didn't select. That's
  disk footprint, not always-resident context, but prefer standard for a tighter install. See
  docs/skill-audit.md.

Organization scope adds teams, 5 autonomy levels, review strictness, and capability packs — see
docs/org-capabilities.md.

How claude-kit compares

The closest alternative is just using Claude Code's own subagents — and that's the comparison
that matters most: native gives you the agents; claude-kit gives you the governance.

Choose claude-kit when you want a consistent, gate-enforced autonomous-SDLC setup that's the
same across every repo and stack, installs in seconds, and ships nothing you have to run. It is
not a runtime or a code library — it's the configuration that makes Claude Code's agents behave
like a disciplined team.

Use beyond Claude Code (export)

init already emits a repo-root AGENTS.md so teammates on Cursor, VS Code, or Copilot get the
kit's standards from day one. claude-kit export projects the full config into their native formats:

claude-kit export . -t cursor -t agents -t copilot

Fidelity is honest: rules, the project charter, and MCP servers port cleanly; the enforced
gates and reviewer subagents are Claude-Code-only and travel as a single-agent checklist instead —
every exported document says so. Full fidelity matrix: docs/cursor-export.md.

Influences & reuse-first

claude-kit evolves by reviewing excellent open-source projects and industry material, then adopting
only the genuinely-new ideas — each review fetches the real source, adversarially maps it against
the kit's existing files, and ships only the non-duplicative gaps (many reviews conclude with
"0 new agents/skills/rules" on purpose). The full adoption history — from Agentic Design Patterns
through the alibaba/microsoft/google/Meta/Netflix·aws·apple org reviews — lives in
docs/influences.md, with per-release detail in the CHANGELOG.

Security & trust model

claude-kit installs configuration only — no application code, no Docker, nothing that runs as a
service. Three honest caveats before you rely on it:

• The guard hooks are convenience, not a hardened boundary. They raise the cost of a mistake but
  don't sandbox the agent; they need a POSIX shell + jq and silently no-op without them. Seatbelts,
  not walls.
• Most quality gates are agent protocols, not mechanical enforcement. Only the hook scripts are
  deterministic, host-enforced checks; a capable model can still be wrong or skip a step — keep a
  human in the loop for anything that matters. Relatedly: the agents' permissionMode confinement
  (read-only reviewers) binds only in init-scaffolded projects — plugin-loaded agents ignore
  it, so run the pipeline from a scaffolded project when that confinement matters.
• MCP servers are third-party code. Each fragment runs an external package — pinned to an exact
  version, never @latest — that claude-kit references but does not vendor or audit. Review a
  server's source and license before enabling it.

Releases are published to PyPI via OIDC Trusted Publishing with PEP 740 build attestations.
Report vulnerabilities privately — see SECURITY.md.

Docs & deeper reference

Contributing

Issues and PRs welcome — see CONTRIBUTING.md. To dogfood a local checkout:

# As a plugin:  /plugin marketplace add .   then   /plugin install claude-kit
# As the CLI:   pip install -e '.[dev]'   then   claude-kit init /tmp/demo --defaults   &&   pytest

License

MIT © Arjunsingh Yadav