skills

Use before any creative/build work — adding features, building components, new functionality, or changing behavior. Turns a brief or vague idea into an approved design doc through one-question-at-a-time dialogue. Does NOT write code until the design is approved. Output is the design doc; the next step is owned by the caller.

Craft a clear /goal condition for Claude Code's autonomous mode from a rough task description.

Convene an independent cross-model judge — a model of a different family (e.g. Codex/GPT, Gemini, or a Cursor agent pinned to a non-Claude model), whichever CLI is installed — to cross-examine an artifact (a decision, a diff, a document, or a research answer) and adjudicate its findings disbelieve-it-back. This is the cross-model *mechanism*; the caller brings the artifact and its own in-family review. Use via `vet` (code), `research-council` (research), `plan` (a design decision), or directly when you want a second opinion from a model that doesn't share your blind spots. It reviews; it never edits.

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

Execute an approved implementation spec by delegating the coding to a cheaper/faster headless agent CLI (cursor-agent, codex, or a cheaper claude) while the main agent plans, verifies, and owns the merge. Use when you have a clear, self-contained task or plan and want another agent to write the code instead of doing it inline — for cross-family diversity, parallelism, or cost on large/repetitive work — e.g. 'have cursor do this', 'delegate this to cursor-agent', 'let codex implement this', 'let the cheap model write it', or any time the implementation is well-specified and mechanical enough to hand off. Also invoke explicitly as /delegate-coding. Does NOT write the plan; pair it with `plan` / `writing-plans` upstream.

A disciplined loop for hard bugs and performance regressions — reproduce, build a fast deterministic feedback loop, minimise, hypothesise, instrument, fix, and add a regression test. Use when facing a hard bug, an intermittent failure, or a performance regression.

Create/enter an isolated feature worktree and bootstrap-or-surface its environment (setup), and remove/prune it (teardown). Use when starting isolated agentic work (e.g. autonomous execute) or wrapping it up (finish).

Use when you have a spec or requirements for a multi-step task, before touching code. Produces a bite-sized, TDD-shaped implementation plan with exact files, code, and commands. Output is the plan; hardening and execution are separate steps owned by the caller.

Detect and remove characteristic AI-generated "slop" from code, scoped to a diff by default. Use when cleaning up AI-generated code, removing slop, or tidying a diff before review.

Execute an approved implementation plan (or a maintained task list) to verified code. Picks a mode: interactive-gated (main agent, one task at a time, surface blockers) or autonomous-subagent (fresh implementer subagent per task + two-stage controller review). Use when you have a plan or backlog and need to turn it into working code. Does NOT write the plan.

A grilling session that also builds the project's domain model as it goes — challenging terminology against the glossary and recording decisions as ADRs the moment they crystallise. Use when you want to stress-test a plan against your project's documented language and decisions (brownfield).

Deliberate cross-model review of a branch, diff, or PR, then a gated fix loop. Runs `scrutinize` (Claude's outsider pass) and `council` (a cross-model attack on the same diff, e.g. Codex), which adjudicates the two disagreement-first; then drives accepted fixes through the fixer skills and re-reviews until clean. Use when you want a finished change vetted before it ships — review plus follow-through, not just a report.

Scaffold a new skill in THIS repo — correct folder, valid frontmatter, README row, credits, and validation. (For the authoring craft, use the global skill-creator.)

Check this repo's skill invariants (name==folder==kebab-case, unique leaf names, every skill in its area README) and fix violations.

Compact the current conversation into a handoff document for another agent to pick up.

Audit a project's real recurring work (session history, persistent memory, existing skills) and recommend the highest-value skills to create or update.

Makes flaky or unreliable tests deterministic — replaces fixed sleeps with condition-based polling, removes timing races, and kills tests that pass for the wrong reason (mock theater, test-only production methods, incomplete mocks, assertions that can't fail when logic changes). Use when the user mentions flaky tests, intermittent failures, tests that pass locally but fail in CI, or test reliability.

Write the canonical engineering record of a fixed bug or resolved incident — root cause, mechanism, fix, validation, and how it slipped through — for other engineers and future-you. Refuses to draft until the bug is fixed and the fix is validated. Use after a debug/diagnose session lands a verified fix (pairs with diagnose), or when asked to write a post-mortem / postmortem / RCA / root-cause analysis, document a fix, or close out a bug with a writeup. For a customer-visible outage it switches to incident mode (timeline, 5 Whys, severity, action items). Blameless throughout.

Evaluate code-review feedback with technical rigor — verify each claim against the codebase, push back with reasons when the reviewer is wrong, then implement what is valid. Use when receiving code-review feedback, before acting on suggestions, especially when feedback seems unclear or technically questionable.

A practical playbook for cutting token and dollar cost in production LLM pipelines without wrecking quality. Use when reducing the token or dollar cost of an LLM pipeline — prompt caching, model tiering, context trimming, or batching.

Cross-examine a research answer — your own, a deep-research tool's, or any draft that carries sources — with an adversarial outside model (e.g. Codex) that re-checks every citation, attacks overclaims and staleness, names the missing angles, and adjudicates contradictions, before you trust it. Use after you've researched something that's too important to ship unchecked and want a *different* model to try to break it. It reviews research; it does not orchestrate it — bring your own (run a deep-research tool or the `research` skill first if you still need the material).

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan before building, get grilled on a design, or uses any 'grill' trigger phrase.

Research a question and answer it from sources fetched right now, with a citation behind every claim — never from memory, never a guess dressed as a fact. Use when the answer is version- or time-sensitive ("what's the current/latest X", "is this still true", "which version introduced Y", "what does the docs/spec say"), when a wrong answer is costly, or whenever you catch yourself about to state something you only "remember." When you've researched something important and want a *different* model to try to break it before you trust it, follow up with the `research-council` skill.

Cleanly wrap up a finished development branch — verify tests pass, detect repo/worktree state, present a merge / open-PR / keep / discard choice, then before any integration drive the whole branch through a comprehensive cross-model review until it is clean, execute the chosen path, and clean up. Use when implementation is complete, tests pass, and you need to integrate or retire the work.

End-to-end planning workflow — take a raw brief, feature request, or app idea and drive it to a hardened, execution-ready implementation plan. Use when you want the full pipeline (design → plan → stress-test), not just one step. Composes the brainstorming, writing-plans, grill, and council skills in order. Does NOT write production code.

Outsider-perspective end-to-end review that produces a written findings report. Questions intent and whether a simpler approach (including doing nothing) achieves the goal, traces the actual code path — not just the diff — to verify the change does what it claims, then reports severity-ordered findings with one verdict (ship / fix-then-ship / rework / reject). Read-only: it flags issues, it does not edit. Use on /scrutinize, or when asked to review, audit, sanity-check, or get a second opinion on a PR, diff, design doc, or completed code change. For interactive plan-hardening dialogue use grill-me; to apply simplifications use simplify; to strip AI slop use slop-cleanup.

Create clean, atomic, bisect-safe git commits — one logical change each, messages in the repo's commit convention (Conventional Commits by default), and a neutral Co-Authored-By trailer that credits the agent, not the model. Use whenever about to commit: staging changes, writing a commit message, or asked to "commit this".

Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, read before writing, make surgical changes, surface conflicts and assumptions, fail loud, and define verifiable success criteria.

Before claiming work is done, fixed, or passing, run the actual verification command and confirm its output. Use when about to claim completion, commit, or open a PR, or whenever tempted to say "should work / probably / seems fine."