/using-loopkit

name: using-loopkit
description: Use when starting any conversation in a loopkit-enabled project - establishes how to find and use loopkit's 49 skills, requiring skill invocation before ANY response including clarifying questions.

Using Loopkit

<EXTREMELY-IMPORTANT> If you think there is even a 1% chance a loopkit skill applies to what you are doing, INVOKE it.

IF A SKILL APPLIES, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This overrides "just answer quickly" instincts. Not negotiable. </EXTREMELY-IMPORTANT>

The Rule

**Invoke relevant skills BEFORE any response or action** — including clarifying questions, exploring the codebase, or reading files. If it turns out wrong for the situation, drop it.

Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has a checklist, create a todo per item.

Where the skills live

Skills are files at `.claude/skills/<name>/SKILL.md`. Each has YAML frontmatter with `name` and `description` (the description is a trigger phrase, not a summary). Load a skill by reading its SKILL.md when its trigger matches your task.

Skill routing (49 skills, 10 tracks)

| Task shape | First skill | |---|---| | "Fix this bug" / test failing / crash | `systematic-debugging`, then `read-the-trace` | | "It broke between two commits" | `bisect-regression` | | "Flaky test" | `flaky-hunter` | | "Add a feature" / write anything new | `spec-first`, then `write-failing-test-first` | | "Refactor" / dead code / deep nesting | `kill-dead-code`, `simplify`, `reduce-nesting` | | About to claim done / commit / open PR | `adversarial-verify` + `verification-before-completion` + `self-eval-bias` | | Review a diff | `adversarial-verify`, `pr-from-diff` | | Frontend / UI work | `design-system`, `a11y-pass`, `loading-empty-error-states` | | Security touch | `owasp-review`, `authz-check`, `input-validation`, `secret-scan`, `dependency-audit` | | Data / SQL / migrations | `sql-review`, `migration-writer`, `schema-diff` | | Docs / changelog / README | `changelog-from-diff`, `decision-record`, `readme-audit` | | Git ops | `clean-commits`, `pr-from-diff`, `rebase-safely`, `revert-surgical` | | Test suite gaps | `coverage-gaps`, `contract-test` | | Running out of context | `context-budget`, `tool-restraint` | | Parallel work | `subagent-fanout` | | Starting a fresh project / major feature | `planner-spec-expand`, then `feature-list-json`, then `init-script-contract` | | Bootstrapping into an existing multi-session project | `progress-reading-protocol` | | Entering an implementation sprint | `sprint-contract` | | Calibrating a reviewer / evaluator | `evaluator-calibration` | | New Claude/Sonnet/Opus model landed | `harness-stripping` |

Full list: `ls .claude/skills/`.

Red Flags — STOP and check for a skill

| Thought | Reality | |---|---| | "This is just a simple question" | Questions are tasks. Check first. | | "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. | | "I remember this skill" | Skills evolve. Read the current SKILL.md. | | "The skill is overkill" | Simple things become complex. Use it. | | "I'll just do this one thing first" | Check BEFORE doing anything. | | "Tests pass, we're good" | `verification-before-completion` says: run the exact command, read the output, then claim. | | "I'll do both features while I'm in here" | `single-feature-discipline` says: one per session. Never two. | | "The reviewer will let this slide" | `self-eval-bias` says: assume it will confidently praise. Calibrate first. |

Priority when multiple skills apply

Process skills first (spec-first, systematic-debugging, planner-spec-expand, sprint-contract), then implementation skills (design-system, sql-review, etc.), then finishers (adversarial-verify, verification-before-completion, self-eval-bias, clean-commits).

• "Let's build X" → `planner-spec-expand` → `feature-list-json` → `sprint-contract` → domain skills → `adversarial-verify`.
• "Fix bug Y" → `systematic-debugging` → `read-the-trace` → fix → `verification-before-completion`.
• "Session open in existing project" → `progress-reading-protocol` → `sprint-contract` → work.

Skill release convention

Every new skill in loopkit ships as a folder with four required files. No exceptions — a skill without these is a draft, not a release.

skills/<skill-name>/
  SKILL.md            # the skill itself (frontmatter + procedure)
  POST.md             # ~200-word X-thread-shaped explainer
  evidence/
    before.md         # verbatim transcript WITHOUT the skill loaded
    after.md          # same prompt WITH the skill loaded

• `SKILL.md` — routed on its frontmatter `description`. Body under ~150 lines.
• `POST.md` — the announcement thread. Copy from `template/POST.md`, fill in every placeholder before publishing.
• `evidence/before.md` + `evidence/after.md` — one real task, both transcripts. The before/after pair is the receipt that the skill actually changes behaviour. If you cannot produce it, the skill is not ready; land it as a draft and merge once the evidence is real.

Bootstrap a new skill by copying `template/` verbatim:

cp -r template skills/<skill-name>

Then edit SKILL.md, write POST.md, and capture the before/after pair.

User instructions win

CLAUDE.md, AGENTS.md, and direct user requests override loopkit skills. Only skip a skill workflow when the user has explicitly said to.