kit

Build a self-contained HTML page that argues one technical position from verified evidence — schema, queries, call sites — for a reviewer to read and act on. Use when a review, design comparison, or schema proposal needs more than terminal scrollback, or when another skill needs the evidence-page format.

Decide where behavior belongs — model, value object, or service — and whether the answer already exists. Use when designing new classes, reviewing a proposed service, refactoring, or when another skill needs the placement checks.

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

Pressure-test a plan, decision, or idea by asserting what is true about it and confirming agreement, raising a decision only where one genuinely exists. Use when the user wants a direction or a ticket's boundary checked before committing to it, or uses any 'grill' trigger phrases.

Scan a codebase for misshapen objects and present them as a visual HTML report in plans/, ranked strongest to weakest, then file the strongest as tickets under an epic.

Stop an unattended pass at a question only a person can answer — the comment, the kit-blocked label, the worktree left in place, and the report line. Use whenever a command running without a user reaches a decision it may not make.

The axis for judging object shape in a Rails codebase — what a well-formed class looks like, what to count when one isn't, and what is not a finding. Use when comparing design approaches, judging a proposed class or extraction, or when another skill needs the object-shape vocabulary.

The axis for judging whether one RSpec example is load-bearing — the positive definition, the three categories that convict a deletion candidate and the evidence each needs, and what is not a finding. Use when pruning a spec suite, when judging whether one example earns its place, or when another skill needs the load-bearing vocabulary.

Take a GitHub issue to a wired worktree with its plan verified — the clean-main check, the worktree off origin/main, the gitignored runtime files a fresh worktree lacks, and the qualification test that decides whether the approach is settled. Use when an orchestrator needs a ticket set up for implementation.

Decide which open tickets an agent may pick up unbidden — the candidate query, the five conditions, and the batched lookups that answer them. Use when sweeping a backlog for work to start, or listing what a sweep would take.

Where a plan, a design brief, or a walkthrough is stored and how it is found again — one marked comment on the issue as the store, a gitignored local mirror as the cache. Use whenever a command writes or looks for one of those artifacts.

Carry one named ticket from a wired worktree to an open PR — prepare, TDD, simplify, push — attended with gates you answer, or unattended with each gate replaced by a rule and a park where no rule decides. Use when a command has chosen a ticket and needs it implemented.

Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker.

Audit a project's auto-memory directory, bin every memory as stale, workflow, duplicate/conflicting, or unclassified, and clear it down with the user's per-bin approval. Use when memory has grown large, a memory turns out to be wrong, or the user asks to triage, prune, or audit memory.

Resolve where a project's git worktrees live and how they are created, provisioned, and removed — by delegating to the project's own command when it has one, and falling back to a built-in layout when it doesn't. Use whenever a command needs to make, find, or remove a worktree.

Reclaim git worktrees and delete their branches safely — one named target or a sweep, attended or unattended. Use when a ticket has merged, when worktrees have accumulated, or when another command needs a worktree torn down.

Draft lean GitHub issues that state the problem and the decision without freezing an implementation. Use when filing an issue or ticket, or when another skill needs the ticket format.