Plugin

kit

Name: kit
Author: dwarvesf

By dwarvesf

Spec-driven Claude Code workflow with verification pipeline. Hooks, slash commands, and verification subagents.

What's Inside

Slash Commands31

Prerequisites

/dispatch

Fire several disjoint VALIDATED specs concurrently, each in its own worktree, then converge. Cross-goal fan-out behind a disjointness gate + drift guard; lead-owned merge, no DAG.

Process

/absorb

Maintainer-only: audit the kit's upstream sources (Credits drift + seed-rescan) and draft a dated, proposal-only absorption report. Does not execute, does not merge.

Run

/adopt

Adopt the current (or a target) repo into the dwarves-kit operate-contract: inject AGENTS.md + a CLAUDE.md loader + a WORKFLOW pointer + the proof marker, idempotently, and wire the lane/loop-type/proof classifiers so the ship-gate engages.

Process

/assign

Turn a backlog item (ID-NNN) into a scoped goal draft and route it into the right WORKFLOW lane. Writes .claude/goals/, never executes.

The Iron Law

/debug

Systematic debug loop: root cause before any fix. Four phases, an evidence ledger, the 3-fix architecture wall.

Agents25

acceptance-verifier

/acceptance-verifier

Dynamically executes the active spec's acceptance criteria via its `## Verification` section and reports whether the build actually satisfies them. Fills the agent-less Acceptance row of the V-model right arm. Read-only -- cannot modify the codebase.

advisor

/advisor

The single cross-cutting generic review lens (ADR-0028 SG-05/P5-P6). Runs in TWO modes at the final integration/UAT boundary -- critique (an extra uniform lens ON TOP of the specialized per-phase reviewers) and over-suggest (proposes additional ideas/sub-goals to improve the work, surfaced to the human just before the final review). Read-only, kit-default, additive (never replaces the tailored reviewers).

agent-effectiveness

/agent-effectiveness

Validates an agent definition's EFFECTIVENESS (not just its structure) across four lenses -- tools minimal-yet-sufficient, description triggers right, instructions produce a good result, model tier fits. Dispatched diff-keyed on new/changed agent defs at the agent-author phase. Read-only, advisory, fail-safe.

api-reviewer

/api-reviewer

Reviews a diff through the API-CONTRACT lens only (breaking changes, versioning, request/response schema, error codes, backward compat, idempotency). Read-only. Dispatched by /kit:review-team as the api domain lens when the diff touches a public interface.

brief-reviewer

/brief-reviewer

Statically reviews a design brief or requirement (DECISION-BRIEF.md, a spec's Problem/Context section, or an equivalent requirement doc) for clarity, completeness, and testability before it hardens into a spec. Read-only -- cannot edit the brief.

Skills4

get-api-docs

/get-api-docs

Fetch curated API documentation using Context Hub (chub) before coding against any external API. Use when the task involves calling a third-party API (Stripe, OpenAI, Airwallex, Notion, etc.) to prevent hallucinated parameters and deprecated endpoints.

memory-tidy

/memory-tidy

Use when auditing, consolidating, or cleaning a repo's .claude/memory store, "dọn memory", "memory tidy", the biweekly memory audit, duplicate or stale memory notes, MEMORY.md index drift (notes missing from the index, index entries with no file), or when a scheduled run asks for the memory-tidy audit of a repository. NOT for the built-in machine-local auto-memory under ~/.claude/projects (not git-tracked, no PR gate) and NOT for editing a single note (just edit it).

skill-review

/skill-review

Review and promote skill drafts that skill-curator staged from past sessions. Use when the user runs /skill-review, says "review my skill drafts", "promote a staged skill", or asks what skills the self-improvement loop proposed. Lists drafts under ~/.claude/skill-proposals/, runs the writing-skills quality bar on each, then promotes the approved ones into ~/.claude/skills/ or rejects them.

stats

/stats

Query or render the state of the scattered kit/tide/tg-cleanup/learned ledgers (the dwarves-kit gate/proof/telemetry corpus, tide file-move state, tg-cleanup snapshots, the learning ledger), and detect + propose backlog rows off anomalies in that state. Use when the operator asks to SEE ledger state -- "show me the ledger state", "my debt", "understanding debt", "telemetry", "token cost" / "how much am I spending on tokens", "kit runs" / "kit lane telemetry", "ledger status", "render the ledger", "ledger dashboard", "share this as an artifact" (mid-ledger-conversation) -- or to check/propose off it -- "any ledger anomalies", "is my debt over threshold", "propose a backlog row from the ledger state". Drives the read-only `stats` CLI (dwarves-kit/lib/stats) and renders the result as EITHER an in-terminal reply (bot-reply-formatting , tables + bar-fills) or a shareable web Artifact, both from the same one query; `stats anomalies` is the feedback-loop path, PROPOSE-only (stages a cc-backlog candidate, never files a board row). READ-ONLY by hard contract over every source ledger , the CLI never writes back to a source ledger; the one exception is `stats anomalies --propose`, whose ONLY write is the gitignored cc-backlog staging buffer. NOT for editing/mutating any ledger. NOT for ad-hoc SQL exploration (drive `stats query`/`stats show` directly for that; this skill is the rendered-answer path). NOT a persistent TUI/app -- there is no daemon here, only an on-demand agent-driven query + render + propose.

Hooks1

24 hooks across 10 events

Stats

Version2.0.0

ReleasedJun 11, 2026

LanguageShell

Stars7

Forks2

MaintenanceExcellent

LicenseMIT

Last CommitJul 22, 2026

AddedApr 21, 2026

Actions

View on GitHub View README Plugin Marketplace JSON

Available In

dwarves-marketplace7

Safety Signals

Critical

Matches all tools

Hooks run on every tool call, not just specific ones

Caution

Executes bash commands

Hook triggers when Bash tool is used

Tags

dwarves-kit

A closed-loop Claude Code workflow: you set the goal and the gates, agents loop until the verifier passes. Worker → verifier → fix-agent retry, by default.

Agent workflows are shifting from prompt -> output to goal -> loop -> evaluate -> improve -> result. dwarves-kit is the closed kind of that loop: you set the goal and the gates up front, and agents iterate inside them until a read-only verifier passes, never grading their own homework.

It ships as a toolbox, not an appliance. Every subsystem is a standalone shell command that already works on its own, bash lib/board/board.sh --help, and the same for gate/stats/classify/spec/goal/session, so there is no kit uber-binary and no install step to just poke at it (the same bash reads under pi, opencode, Claude Code, or a bare terminal). Wiring it into Claude Code (bash install.sh) adds an always-on safety spine and lets you --with exactly the modules you want and nothing else; Install has the layers.

The loop itself is one spec-driven lifecycle, think → spec → execute → review → ship → retro, with a gate at every phase boundary:

Two gate classes sit on those boundaries: blocking (the verification pipeline, the ship-gate, the push-to-main blocker , mechanical, they stop a bad outcome) and advisory (think, review , they surface findings, never block). The autonomous-loop hardening adds a fresh-context re-audit of every done-claim, a kit-default cross-cutting advisor lens on top of the specialized reviewers, and a deployable-done proof gate, so a closed loop can run long without drifting into self-graded slop.

Every build task runs a verification pipeline (worker → verifier → fix-agent retry), and hooks enforce safety automatically (rm -rf, push-to-main, force-push, and secret-file reads are blocked). The worker is also specialized per task: when a task needs a role no built-in agent covers (security, migration, a doc writer, ...), the kit synthesizes one on the fly and dispatches it, or /kit:draft-agent installs a reusable named agent (SPEC-089).

You drive it by intent, not by memorizing commands. Say what you want; the kit reads your intent, runs the right step, and stops only at the real decisions:

You: "add a --version flag to the CLI" Kit: scopes it -> writes the spec -> builds + verifies -> ships, pausing only where it needs your call.

The /kit:* commands below are those same actions named explicitly, for when you prefer to type them. You rarely need to.

It is bash-first (every hook readable in 30 seconds), and every component traces to a proven pattern, no novel inventions. The point of the kit is the handoff: a solo technical lead writes the spec, a contractor runs /kit:execute against the same spec.

New here? Install below, then run your first cycle. The full operator reference (every command, hook, and agent, plus troubleshooting) lives in MANUAL.md.

Why a closed loop

An open loop (the agent roams free and judges its own output) is a fast slop machine unless your standard is airtight and your budget is unlimited. The kit takes the closed shape instead: a human designs the path once, agents iterate inside it. What makes the loop trustworthy is that the gates that block are mechanical (bash hooks, tests, read-only verifiers), never the agent grading its own homework. The remaining phase gates advise and route rather than block: detect, don't dictate.

Open loop

dwarves-kit (closed)

agent plans its own route

the spec is the contract, written before any build (validated on the full lane)

agent grades its own work

hard gates are mechanical: bash hooks, tests, read-only verifiers

loops until the budget dies

bounded: fix-agent retries max 2, then escalates to a human

one loop size fits all

risk lanes: tiny work skips the ceremony entirely

The five stages

dwarves-kit

A closed-loop Claude Code workflow: you set the goal and the gates, agents loop until the verifier passes. Worker → verifier → fix-agent retry, by default.

The loop itself is one spec-driven lifecycle, think → spec → execute → review → ship → retro, with a gate at every phase boundary:

flowchart LR
  goal([goal + gates<br/>set up front]) --> T
  T[think<br/>forcing questions] -->|advisory| S[spec<br/>the contract]
  S -->|spec-drift guard| X[execute<br/>worker → verifier → fix-agent]
  X -->|BLOCKING: verification pipeline| R[review<br/>verdict recorded]
  R -->|advisory| SH[ship<br/>version + PR]
  SH -->|BLOCKING: ship-gate + push-to-main| RE[retro]
  RE -.->|feeds the next cycle| T

You drive it by intent, not by memorizing commands. Say what you want; the kit reads your intent, runs the right step, and stops only at the real decisions:

You: "add a --version flag to the CLI"
Kit: scopes it -> writes the spec -> builds + verifies -> ships,
     pausing only where it needs your call.

The /kit:* commands below are those same actions named explicitly, for when you prefer to type them. You rarely need to.

New here? Install below, then run your first cycle. The full operator reference (every command, hook, and agent, plus troubleshooting) lives in MANUAL.md.

Why a closed loop

Open loop	dwarves-kit (closed)
agent plans its own route	the spec is the contract, written before any build (validated on the full lane)
agent grades its own work	hard gates are mechanical: bash hooks, tests, read-only verifiers
loops until the budget dies	bounded: fix-agent retries max 2, then escalates to a human
one loop size fits all	risk lanes: tiny work skips the ceremony entirely

kit

What's Inside

kit

Popularity

What's Inside

Confidence

README

dwarves-kit

Why a closed loop

The five stages

Similar Plugins

ecc

octo

supergraph

claude-code-harness

planning-with-files

superpowers

dwarves-kit

Why a closed loop

The five stages

Popularity

Health & Quality

Similar Plugins

ecc

octo

supergraph

claude-code-harness

planning-with-files

superpowers