| 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
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.
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.
