adr-write
Record a single architecture decision as a numbered ADR. Use when the user says "record this as an ADR", "log this decision", "capture this as an ADR", or "create an ADR"; or when another skill has surfaced a decision at the end of a discussion and the user has approved turning it into an ADR; or when a significant architectural call has been made mid-implementation and the user wants it preserved.
babysit-pr
"Monitor and fix automated review comments (Copilot, SonarCloud) and CI failures
blueprint-adr-audit
Audit a blueprint (or other plan/design/spec/diff) against the repository's Accepted ADRs to find where it VIOLATES or CONTRADICTS a binding decision — using parallel sub-agents that each own a slice of the ADR corpus, then a synthesized verdict. This is a companion to blueprint-review, meant to run during blueprint work once the design is drafted and before the build starts. Use when the user says "check the blueprint against our ADRs", "does this violate any ADRs", "audit the plan for ADR compliance", "make sure the blueprint doesn't contradict an ADR", or "/blueprint-adr-audit". It is READ-ONLY: it reports findings and does not edit the plan, the ADRs, or any code. Do NOT use it to WRITE a new ADR (that is adr-write), to REVIEW the blueprint for gaps/correctness (that is blueprint-review), to review code for bugs (/code-review), or to check a spec's documentation quality (review-openapi).
blueprint-create
Run one continuous back-and-forth design discussion — product definition and technical design together — and write a single Blueprint to docs/features/{feature}/blueprint.md. Use when the user asks to "write a blueprint", "create a blueprint", "design this feature", "scope and design X", or otherwise wants to think through both what a feature must do and how it will be built before implementation. Replaces the older multi-document PRD + tech-spec + stories flow with one document and one conversation. Do NOT use for bug fixes or tweaks too small to warrant a design document, or when the user is brainstorming without committing to a document.
blueprint-review
Review an existing Blueprint (the single product + technical design document) for gaps, inconsistencies, unresolved questions, correctness holes, and ambiguities that would force decisions during the build, then produce an updated version. Use when the user asks to "review the blueprint", "check the blueprint", or "update the blueprint". Reviews both halves and the user-stories section in one pass. Do NOT use to start a new Blueprint from scratch (use blueprint-create) or to make minor wording edits that don't need a structured review.
bug-detector
Detects bugs, logic errors, and edge case handling issues in code. Use when reviewing code for runtime errors, null/undefined handling, type errors, and edge cases. Returns structured bug reports with file paths, line numbers, and suggested fixes.
captain-done
"Finish a Linear ticket from inside its worktree and hand it back to the captain: verify
captain
"Manage a Linear project across sessions as an orchestrator: each invocation it
decisions-capture
Capture decisions, rationale, and context from the current conversation into a referenceable document
deliberate
Spawn parallel advocate sub-agents to deliberate on a high-impact decision, then synthesize
goal-from-spec
Emit a /goal command pointed at a feature directory containing a blueprint.md (or the legacy prd.md + tech-spec.md). Use whenever the user wants to implement, build, ship, or run a feature whose design lives in a docs/features/<name>/ directory (or similar). Do NOT use for design discussions or one-shot edits.
grill-me
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
handoff
Write a brief capturing the current state of in-flight work so it can be resumed in a fresh context window. Use when the user says "write a handoff", "summarize this session", "I want to continue in a new context", or needs a continuation brief for PRs/investigations that aren't done yet.
html-explainer
>-
invariant-test
Derive surface tests from a service's stated invariants (Accepted ADRs, load-bearing doc comments, tech specs), targeting the assertions a codebase's defensive mechanisms (mutexes, transactions, atomic backend ops) cannot satisfy — then write each test and mutation-validate it red-then-green so it provably fails when the invariant is violated. Use when the user says "test the invariants", "what test would have caught this", "find correctness-test gaps", "harden the tests against invariant violations", "invariant-test", or after a concurrency/correctness bug that passed `-race` and every existing test (e.g. a single-writer or ownership violation) and you want a test that would have caught it. Do NOT use to check coverage against PRD acceptance criteria (use review-tests), to validate a list of already-identified bugs (use review-validate), or to fix the implementation (this skill writes the proving test and reports live violations loud; hand fixes to review-validate).
lazy
"Write the fewest words that carry the facts — terse, plain, human, not
linear-handoff
"Record the dated state of in-flight work in Linear — not a checked-in file — so the
linear-resume
"Resume in-flight work tracked in Linear by reading the latest handoff and surfacing
linear-start
"Pick up a Linear ticket and start working it. Fetch the ticket, verify the current
pr-github-review
Review GitHub pull request comments and address reviewer feedback. Use when the user says 'review PR comments', 'address PR feedback', or provides a GitHub PR URL.
review-behavior-change
Review code changes for undocumented behavioral/surface changes. Flags modifications to public interfaces, API contracts, or observable behavior that lack justification in an ADR, PRD, tech spec, or implementation plan. Use when the user asks to "check for breaking changes", "review surface changes", "audit behavioral changes", or "validate contract compliance".
review-comments
Address // REVIEW annotations left in source files. Use when the user says 'fix review comments', 'address review comments', or when a file contains // REVIEW markers.
review-for-reader
Review a PR/diff from the perspective of the next maintainer who never saw the change — catching comments, docstrings, and docs that only make sense to someone holding the diff ("diff-anchored writing"), stale comments referencing removed code, journal/history comments, what-not-why comments, and README/doc drift. Then rewrite the flagged prose to current-state phrasing in place. Use when the user says "review for the next reader", "review my comments", "check for diff-anchored comments", "review the PR as a maintainer", "does this make sense without the diff", or "review-for-reader". This is the prose/reader counterpart to review-behavior-change (which reviews the contract) and is NOT a bug finder (use code-review / the built-in /review) or a guideline linter (use review-guidelines).
review-guidelines
Review code changes for compliance with CLAUDE.md guidelines. Use when the user says 'review guidelines', 'check guidelines', or 'validate against guidelines'.
review-openapi
"Review an OpenAPI spec as the product it is — documentation for an external API
review-suite
"Run the full post-implementation review/hardening pass as one headless pipeline in an
review-tests
Review whether a feature's existing tests actually cover the acceptance criteria, scenarios, and correctness constraints documented in its Blueprint (blueprint.md) — then fill the gaps with surface tests, and finally sweep the implementation's code coverage to a soft 80% floor by surfacing still-uncovered code as candidate behaviors. Spawns gap-finding sub-agents plus a validator and a skeptic to eliminate false positives, then (when nothing is left for the user to decide) an implementer that writes the missing tests following the surface-testing skill. Use when the user says "review the tests", "check test coverage for this feature", "find test gaps", "review-tests", or wants to audit a feature's tests against its blueprint. Do NOT use to write tests from scratch for an unbuilt feature, or to validate a list of already-identified bugs (use review-validate for that).
review-validate
Validate reported bugs/issues via sub-agents, write surface tests proving each one, then present findings for review before fixing. Use when bugs have been identified (by bug-detector, code review, or discussion) and you want to confirm they're real, prove them with tests, and fix them safely. Trigger phrases include "validate these issues", "prove these bugs", "test and fix these", "validate and test", or "review-validate".
show-work
"Present investigation evidence as markdown directly in chat.
spec-to-comms
>
surface-testing
Write surface tests that exercise the system through its surface — the outermost layer consumers interact with (HTTP endpoints, CLI entry points, exported functions). Never test internal functions directly. Expose observability APIs when async behavior isn't visible at the surface.
writing-style
Write or edit writing in the user's practitioner blog voice — experience-backed, conversational, story-driven, opinionated but humble. Use for blog posts, tech specs, engineering communications, and any long-form writing the user asks for. Activated when the user asks to "write a post", "draft a blog", "write up X", "edit this for style", "review this for my style", or invokes /writing-style directly.