Skills
74 skills your agent can read.
A skill is workflow instructions an agent loads when the task calls for it: how to drive test-first development, how to review a diff, how to instrument a service. These are 5 authors’ work, carried at a pinned commit with the licence each one ships under. Turn one on and your agent reads it over the endpoint it already has.
Using this gateway
- finding-and-calling-toolsOmniioFind and correctly call a tool on an Omniio MCP gateway. Use whenever a request could be served by an external system — live data, a lookup, or an action in a connected product — rather than answered from memory, and whenever a run_tool call has failed with an argument or validation error. Covers the search_tools, describe_tool, run_tool loop and the argument mistakes that cause most failed calls.
- handling-held-and-refused-callsOmniioRespond correctly when an Omniio tool call is held for human approval, denied by policy, or refused for a spent approval. Use when run_tool returns a message about approval, a link to approve or deny, a policy denial, or an input_required result rather than a normal tool result. A held call is not a failure and must not be reported as one.
- connecting-a-serverOmniioDiagnose and explain why a tool the user expected is missing from an Omniio gateway, and tell them exactly how to connect the server that provides it. Use when search_tools returns nothing for a product the user clearly uses, when a tool call fails because a server is not authorized, or when the user asks how to add a service to their gateway.
- limits-and-retriesOmniioDecide whether a failed Omniio call should be retried, and how long to wait. Use when a tool call or REST request returns a rate limit, a quota message, a 4xx or a 5xx, so that retryable failures are retried correctly and permanent ones are not retried at all.
Writing code
- test-driven-developmentJesse VincentUse when implementing any feature or bugfix, before writing implementation code
- api-and-interface-designAddy OsmaniGuides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.
- code-simplificationAddy OsmaniSimplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
- frontend-ui-engineeringAddy OsmaniBuilds production-quality, accessible, responsive user-facing UIs. Use when building or modifying interfaces and pages, creating components, implementing layouts, meeting WCAG accessibility requirements, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
- incremental-implementationAddy OsmaniDelivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
- performance-optimizationAddy OsmaniOptimizes application performance across frontend, backend, queries, and databases. Use when performance requirements exist, when you suspect performance regressions, when Core Web Vitals or load times need improvement, when N+1 query patterns need fixing, or when profiling reveals bottlenecks.
- security-and-hardeningAddy OsmaniHardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services. Use when personal data or privacy compliance (GDPR, CCPA) is involved.
- source-driven-developmentAddy OsmaniGrounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.
- test-driven-developmentAddy OsmaniDrives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.
- codebase-designMatt PocockShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
- domain-modelingMatt PocockBuild and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
- implementMatt PocockImplement a piece of work based on a spec or set of tickets.
- prototypeMatt PocockBuild a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
- tddMatt PocockTest-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Review & debugging
- systematic-debuggingJesse VincentUse when encountering any bug, test failure, or unexpected behavior, before proposing fixes
- requesting-code-reviewJesse VincentUse when completing tasks, implementing major features, or before merging to verify work meets requirements
- receiving-code-reviewJesse VincentUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
- verification-before-completionJesse VincentUse when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
- code-review-and-qualityAddy OsmaniConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.
- debugging-and-error-recoveryAddy OsmaniGuides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.
- doubt-driven-developmentAddy OsmaniSubjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.
- browser-testing-with-devtoolsAddy OsmaniTests in real browsers via Chrome DevTools MCP. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data. Requires the chrome-devtools MCP server to be configured.
- code-reviewMatt PocockReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes: Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/spec asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
- diagnosing-bugsMatt PocockDiagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
- improve-codebase-architectureMatt PocockScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
- webapp-testingAnthropicToolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Planning & specs
- brainstormingJesse VincentYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
- writing-plansJesse VincentUse when you have a spec or requirements for a multi-step task, before touching code
- executing-plansJesse VincentUse when you have a written implementation plan to execute in a separate session with review checkpoints
- idea-refineAddy OsmaniRefines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. Triggers on "ideate", "refine this idea", or "stress-test my plan".
- interview-meAddy OsmaniExtracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
- planning-and-task-breakdownAddy OsmaniBreaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.
- spec-driven-developmentAddy OsmaniCreates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Use when a single requirement spans several independently testable capabilities and needs decomposing into a capability map of modules before specifying.
- researchMatt PocockInvestigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.
- to-specMatt PocockTurn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.
- to-ticketsMatt PocockBreak a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker (edges as text in one file per ticket locally, or native blocking links on a real tracker).
- triageMatt PocockMove issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.
- wayfinderMatt PocockPlan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
- grillingMatt PocockGrill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
- to-questionnaireMatt PocockTurn a decision you can't fully answer into a questionnaire for someone else to fill in.
Shipping & operations
- using-git-worktreesJesse VincentUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
- finishing-a-development-branchJesse VincentUse when implementation is complete, all tests pass, and you need to decide how to integrate the work
- ci-cd-and-automationAddy OsmaniAutomates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.
- deprecation-and-migrationAddy OsmaniManages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
- git-workflow-and-versioningAddy OsmaniStructures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, or when you need to organize work across multiple parallel streams. Use when cutting a release, choosing a semantic version bump, tagging, or writing a changelog.
- observability-and-instrumentationAddy OsmaniInstruments code so production behavior is visible and diagnosable. Use when adding logging, metrics, tracing, or alerting. Use when shipping any feature that runs in production and you need evidence it works. Use when production issues are reported but you can't tell what happened from the available data.
- shipping-and-launchAddy OsmaniPrepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.
- resolving-merge-conflictsMatt PocockUse when you need to resolve an in-progress git merge/rebase conflict.
- wizardMatt PocockGenerate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
- git-guardrails-claude-codeMatt PocockSet up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.
- setup-pre-commitMatt PocockSet up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
Agents & skills
- dispatching-parallel-agentsJesse VincentUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
- subagent-driven-developmentJesse VincentUse when executing implementation plans with independent tasks in the current session
- writing-skillsJesse VincentUse when creating new skills, editing existing skills, or verifying skills work before deployment
- context-engineeringAddy OsmaniOptimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.
- handoffMatt PocockCompact the current conversation into a handoff document for another agent to pick up.
- claude-handoffMatt PocockHand the current conversation off to a fresh background agent that picks up the work immediately.
- writing-for-agentsMatt PocockWriting documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
- mcp-builderAnthropicGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
- skill-creatorAnthropicCreate 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.
Writing & docs
- documentation-and-adrsAddy OsmaniRecords decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
- teachMatt PocockTeach the user a new skill or concept, within this workspace.
- writing-fragmentsMatt PocockWriting, explore: mine raw fragments, no structure yet.
- writing-shapeMatt PocockWriting, exploit: shape raw material into an article, paragraph by paragraph.
- writing-beatsMatt PocockWriting, exploit; assemble raw material into a journey of beats, grounding each term before a beat leans on it.
Design & artifacts
- frontend-designAnthropicGuidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.
- theme-factoryAnthropicToolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.
- web-artifacts-builderAnthropicSuite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
- algorithmic-artAnthropicCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
- slack-gif-creatorAnthropicKnowledge and utilities for creating animated GIFs optimized for Slack. Provides constraints, validation tools, and animation concepts. Use when users request animated GIFs for Slack like "make me a GIF of X doing Y for Slack."
14 of these ship scripts
A skill that bundles executables needs its files on your disk, because that is where they run. Each of those pages carries a one-line install that puts them where your client already looks; the instructions themselves your agent reads straight from the endpoint.
Same endpoint. Nothing new to install.
Skills arrive over the connection your client already has, and only the ones you turned on are sent.