Skill Catalog

Start with the situation in front of you and choose the skill that fits. You rarely need more than one at a time. The site loads these names and descriptions directly from the repository’s skills/*/SKILL.md files when it builds.

34 skills, grouped by the work they help with. Search when you already know the situation or skill name.

Clarify & Collaborate

Make unclear work discussable, teachable, and transferable.

`explain-plainly`

Default to explaining technical work in plain language for a non-technical audience, using an existing project glossary only when a persistent document is already in scope. Use whenever an explanation is aimed at someone outside the technical team, or whenever jargon would otherwise go unexplained. Distinct from wait-what, which is a recovery move after an explanation already failed, not a default posture.

`grilling`

Interview the user relentlessly, in rounds, to close the gap between what's known and what's needed before acting on a plan, decision, or idea. Use when the user wants to stress-test their thinking, a plan has unstated assumptions, or a decision keeps getting acted on before it's actually been made.

`handoff`

Hand off in-progress work, an on-call shift, or an open incident to another person or agent using a fixed four-part structure, so nothing load-bearing is lost between one owner and the next. Use when work needs to change hands mid-flight, an on-call rotation is ending, or an open incident is passing to a new owner. Not for compacting a conversation so a fresh session can resume, which is a session-continuity concern.

`teach`

Teach a concept or skill by pitching it at the right cognitive level and fading from a fully worked example to independent practice. Use when the user wants something explained so it's actually understood and retained, not just told once, or asks to be taught rather than simply given an answer.

`to-questionnaire`

Turn a decision that can't be answered alone into a written questionnaire for the person who actually holds the missing knowledge. Use when a decision is blocked on facts or judgment only one specific person has, and that person needs to be asked async or in a structured meeting rather than interviewed live.

`triage`

Classify and prioritize an incoming bug report or feature request using Impact × Urgency, and route it to the right next step. Use when the user wants a backlog triaged, an issue prioritized, or asks whether something is worth working on now versus later.

`wait-what`

Recognize when the last explanation didn't land, and re-pitch it rather than repeating it. Use when the user's response signals confusion (a follow-up that shows they missed the point, silence, or a direct "wait, what?") right after an explanation was given.

`wayfinder`

Plan a piece of work too large or too foggy for one sitting as a staged sequence of written decisions, resolved one at a time until the path to done is clear. Use when a loose idea needs to become a plan before implementation starts, when several open questions block each other, or when work is too big to spec in a single pass.

`wizard`

Generate an interactive script that walks a human, step by step, through a manual procedure only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, navigating an unfamiliar third-party dashboard, or running a one-off migration or cutover that needs a human's hands or authority at each step.

Discover & Design

Turn uncertainty into decisions, specifications, and coherent designs.

`api-design-standards`

API design discipline grounded in the Microsoft/Google REST guidelines, resource and URL conventions, a chosen versioning strategy, what counts as a backward-compatible vs breaking change, and consumer-driven contract testing. Use when designing a new API endpoint, changing an existing API's request/response shape, deciding how to version an API, or asking whether a change to a public interface is breaking.

`architecture-diagram`

Produce a software architecture diagram at the right level of zoom, using diagram as code so it can be shown inline, saved, or committed as the user or active workflow authorizes. Use when the user wants to draw, extract, or visualize a project's architecture, a component or request flow, a data flow, or a decision path a design principle hinges on.

`capacity-estimation`

Turn a vague performance requirement into arithmetic before the architecture is chosen, size concurrency with Little's Law, and label every input as measured, derived, or assumed. Use when a design calls itself "scalable" or "fast" without a number, when choosing between one machine and a distributed system, when sizing a thread pool, connection pool, queue, or instance count, or when someone asks how much traffic, storage, or bandwidth a system will need.

`codebase-design`

Module design discipline from John Ousterhout's A Philosophy of Software Design, depth as the metric (a lot of functionality behind a simple interface), information hiding vs. leakage, the concrete red flags that mark a shallow module, and comparing at least two designs before committing. Use when designing a new module or class, deciding where an interface boundary (seam) should go, reviewing a design for unnecessary complexity, or asking whether something should be split or merged.

`domain-modeling`

Domain-Driven Design discipline, build a ubiquitous language shared by code and conversation, draw explicit bounded contexts where a term's meaning holds, and record significant decisions as one-page Architecture Decision Records. Use when project vocabulary is inconsistent or ambiguous, when the same word means different things in different parts of a codebase, when onboarding needs a shared glossary, or when a significant architectural decision needs to be captured for later.

`project-groundwork`

Check an existing draft specification or README against a fixed set of quality characteristics, batch only the genuinely blocking gaps into one round of questions, and write each resolved decision into the source document plus the repository's existing decision-recording artifact when one exists. Use when a draft spec or architecture doc has sections that disagree with each other, still carries TBDs, or needs its open points settled before implementation starts.

`prototype`

Build a throwaway spike solution to answer one design or technical question before committing to an approach. Use when the user wants to sanity-check whether a state model, logic, or UI direction feels right, is unsure an approach will work, or wants to explore options before writing production code.

`research`

Investigate a technical question against primary sources and capture the findings, with citations, as a file in the repo. Use when the user wants a topic researched, docs or API facts gathered, a claim verified before it's relied on, or reading legwork delegated to a background agent.

`spec-to-tickets`

Turns an already-discussed plan into a written spec and a set of tracer-bullet tickets, synthesizing rather than re-interviewing, slicing work end-to-end rather than by layer, and gating entry/exit with a written Definition of Ready and Definition of Done rather than by feel. Use when the user asks to turn a conversation or plan into a spec, break work into tickets, or size and sequence a set of tasks before implementation starts.

Build & Verify

Implement, test, diagnose, review, and improve code with evidence.

`code-review`

Code review discipline: the approval bar is "improves code health," not "perfect," Fowler's code-smell catalog gives design/complexity concerns a name instead of a vague feeling, and small PRs keep review depth from degrading. Use when reviewing a pull request or diff, requesting a review, deciding whether a change is blockable, or leaving review feedback.

`code-style-lint`

Discipline for code style and static analysis, adopt the ecosystem's established formatter as the non-negotiable source of truth, enforce it at pre-commit and CI rather than in review, and treat linting (real defects) as a separate concern from formatting (appearance). Use when setting up a new project's tooling, when a code review comment is about whitespace/naming/formatting instead of behavior, or when the user asks how to configure a linter or formatter.

`diagnosing-bugs`

Systematic debugging discipline based on David Agans' nine rules, understand the system, reproduce reliably, bisect the search space, change one variable at a time, keep an audit trail, and never declare a fix done until it's verified against the original failure. Use when the user reports something broken, throwing, failing, or slow, or says "diagnose" / "debug this".

`improve-codebase-architecture`

Scan a codebase (or a named area of one) for architectural friction, classify each finding by how it was incurred, and propose deepening opportunities in priority order. Use when the user wants an architecture review, asks where the design is causing pain, wants technical debt surfaced and prioritized, or asks what to refactor next.

`resolving-merge-conflicts`

Discipline for resolving an in-progress git merge or rebase conflict, a conflict marker names two divergent intents from a shared ancestor, resolved by tracing each side back to what it was trying to accomplish, never by blindly picking one side's raw text. Use when a merge or rebase has stopped with conflict markers, when deciding whether to resolve with --ours/--theirs, or when choosing between merge and rebase for integrating a branch.

`secure-coding`

Secure-coding discipline mapped to the OWASP Top 10, checked at the point of writing code, not after. Covers input validation and injection classes, broken access control, secrets handling, dependency/supply-chain risk, and safe error handling/logging. Use when writing code that crosses a trust boundary (handles user input, auth, payments, file paths, external commands, or third-party dependencies), when reviewing a diff for security issues, or when the user asks for a security review, threat check, or "is this safe."

`tdd`

Test-driven development discipline: the red-green-refactor cycle, the testing pyramid's proportion of unit/integration/e2e, Fowler's test-double taxonomy, and the FIRST properties of a test worth keeping. Use when building a feature or fixing a bug test-first, mentions "TDD" or "red-green-refactor", or when deciding what kind of test to write, whether to mock a dependency, or how a test suite should be shaped.

`test-strategy`

Suite-level testing decisions that sit above individual tests, where test data comes from (synthetic factories vs anonymized production snapshots), the flaky-test quarantine policy, and where the integration/e2e boundary actually belongs. Use when deciding how a test suite should source its data, what to do with a flaky test, or whether a given seam needs a full integration test, a contract test, or a unit test with a double is enough. Does not cover the red-green-refactor cycle or test-double taxonomy; see the tdd skill for those.

Ship & Operate

Release changes safely and keep running systems understandable.

`dependency-upgrade-management`

Discipline for keeping dependencies current and deprecating capabilities safely, an inventory (SBOM) of what's actually shipped, security patches on a fast lane separate from routine/major upgrades, and a stated deprecation window (Sunset/Deprecation headers, N-2 support) before removing anything consumers rely on. Use when upgrading a dependency, triaging a Dependabot/Renovate PR, deciding whether an upgrade is safe to automerge, or planning to deprecate or remove a capability others depend on.

`incident-response`

Discipline for the full incident lifecycle, declaring and sizing an incident by severity, separating the incident-commander/comms/ops roles, mitigating before root-causing, and writing a blameless postmortem that investigates the system rather than a person. Use when a production incident is happening or just resolved, when the user asks to declare an incident, run an incident response, write a postmortem, or asks who's in charge during an outage.

`observability`

Discipline for making a service's health answerable without reading its code, structured logging, the four golden signals (latency, errors, traffic, saturation), and an SLI/SLO/error-budget definition with alerts that link a runbook. Use when adding logging to a service, instrumenting metrics or tracing, defining what "healthy" means for a service, setting up alerts, or when the user asks how to monitor, debug in production, or know if something is broken.

`release-versioning`

Discipline for release classification, version bumps, and changelogs, Conventional Commits classify the release range, SemVer computes the version from those commits, Keep a Changelog renders the result. Use when the user asks to cut a release, bump a version, write a changelog, decide if a change is a major/minor/patch, or choose a branching model for versioned releases.

`repo-secure`

Audit and enable a GitHub repository's own recommended security settings, confirming with the maintainer which ones actually apply before turning anything on. Use when the user wants a repo hardened, asks to enable secret scanning or branch protection, wants a SECURITY.md written, or references GitHub's maintainer security checklist.

`repo-ship`

Split existing repository work into commits by intent as it happens, or give a new repository its name, visibility, description, and topics at creation. Use the matching path when work is about to be committed or pushed, before a push that would otherwise land as one large commit, or when a new repository is being created.

`safe-deployment`

Discipline for shipping changes reversibly, decouple deploy (code reaches production) from release (users see it) with feature flags, roll out progressively, and define the automated rollback trigger before shipping, not during the incident. Use when the user asks how to deploy a risky change, choose between canary/blue-green/rolling deployment, ship behind a feature flag, plan a rollback strategy, or asks "how do we ship this safely."

Extend Doctrine

Write agent-facing instructions that preserve Doctrine's boundaries.

`writing-for-agents`

Classify and structure content going into a document an agent reads (a skill, AGENTS.md, CLAUDE.md, a linked doc) so procedure, facts, and rationale don't get tangled together. Use when creating or editing a skill, or writing/editing AGENTS.md or CLAUDE.md.