Leadkit — Git skill for Claude Code

leadkit

A portable operating model for running teams of Claude Code agents on real work: one Go binary, a per-project profile (`leadkit.yaml`), and a set of guard hooks that enforce policy at the tool boundary rather than in a prompt.

It is a CLI and a config file, not a library. Projects adopt it by writing a profile and running a few commands.

Why it exists

A single coding agent handles a long-running, multi-repository job badly, and it fails quietly. Context fills with whatever it touched last, so the twentieth change gets less care than the second, and decisions settled on Tuesday get re-litigated on Thursday. Every individual step reports success, because every step did succeed. Only the shape of the whole is wrong.

leadkit is the least structure I found that lets several agents work one codebase for months without the result going incoherent:

• Work lives on disk, not in a conversation. Each item is a markdown file with frontmatter; a queue of per-role directories is laid over it. An agent can die mid-task without losing anything, and ls answers "what is everyone doing" without asking an agent to describe itself.
• A lead decomposes and does not implement. The moment it edits code it acquires the same context-crowding problem as a single agent.
• Two reviewers with genuinely different questions gate a diff before a human sees it. One reads line by line for correctness; the other reads it against the stated goal. A pass is recorded against a commit SHA, so a new push does not inherit an old approval.
• Policy is enforced outside the model, at the point where intent becomes effect. A prompt instruction is a suggestion evaluated by the same process deciding what to do.

Install

The installer downloads a release binary via `gh`, verifies its checksum and installs it atomically to `~/.claude/leadkit-bin`:

sh install.sh            # latest release
sh install.sh v0.2.0     # a specific tag; LEADKIT_BIN=... overrides the target