26 variants across 6 phases. For guided decisions, go to the topic pages.
Refines ideas iteratively. Refine ideas through structured divergent and convergent thinking. Use "idea-refine" or "ideate" to trigger.
Reach for this when a raw idea needs sharpening before a spec can be written. Addy Osmani (engineering lead at Google Chrome) codifies the divergent-then-convergent loop into a repeatable skill, so you don't skip straight from vague intuition to implementation.
Breaks 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.
Reach for this when a spec is clear but the work still feels unbootable. Addy Osmani (engineering lead at Google Chrome) encodes the "decompose, order, parallelize" habit that turns blank-page anxiety into a task list your agent (or team) can actually start on.
Creates 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.
Reach for this when the temptation is to skip straight to code and you know the requirements aren't yet sharp. Addy Osmani (engineering lead at Google Chrome) treats the spec as the cheapest place to fix a design bug — this skill protects that step from being skipped.
Guides 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.
Reach for this when you're about to freeze a contract — REST, GraphQL, or inter-module types — and want a stability-first checklist. Addy Osmani (engineering lead at Google Chrome) has spent years cleaning up interfaces that escaped design review, and this skill encodes the "design twice, change once" habit.
Records 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.
Reach for this when a decision needs to outlive the Slack thread it was made in. Addy Osmani (engineering lead at Google Chrome) leans on ADRs as the engineering equivalent of commit messages for architecture — this skill makes writing them routine rather than heroic.
For teams who want AI-generated frontends to stop looking AI-generated. Pushes toward intentional typography, bold aesthetic direction, and production-grade code over generic defaults (Inter + purple gradient).
Reach for this when Claude is generating UI and you want it to commit to a distinct aesthetic rather than defaulting to safe, templated design. Authored and maintained by Anthropic as part of their public skills repo.
Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.
Reach for this when an agent-generated UI needs to stop looking agent-generated. Addy Osmani (engineering lead at Google Chrome) has shipped frontend tooling and patterns used across the web — this skill carries that taste into components, layout, and state choices.
For teams building on MongoDB. Covers anti-patterns, fundamentals, and 11 design patterns — the document-model guidance MongoDB's own team uses.
Reach for this when you're on MongoDB. It's maintained by MongoDB, kept current with Atlas's own Performance Advisor and Schema Suggestions, and covers the anti-patterns most teams don't learn until they hit them in production.
For teams building on Postgres or Supabase. Broader than schema alone — also covers query performance, RLS, connection pooling, and locking — but its Schema Design category is the canonical Postgres counterpart to MongoDB's guide.
Reach for this when you're on Postgres. Supabase maintains it with prioritized rules (query, connection, security, schema, concurrency, and more) that read as a single checklist for a Postgres codebase. Use it alongside Postgres's own docs for anything RLS- or pooling-related.
Conducts 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.
Reach for this when you want a disciplined five-axis review (correctness, readability, architecture, security, performance) from someone who has seen a lot of code ship. Addy Osmani (engineering lead at Google Chrome) keeps the bar high without turning reviews into a blocker — a useful baseline to drop into any team that's letting agents write more of the diff than humans read.
Simplifies 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.
Reach for this when working code feels heavier than it needs to be and you want a refactor that preserves behavior. Addy Osmani (engineering lead at Google Chrome) is a consistent voice for "readable code is the product" — this skill turns that stance into concrete moves.
Optimizes 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.
Reach for this when your agent's output quality has started to slip and you suspect the context window, not the model. Addy Osmani (engineering lead at Google Chrome) treats context engineering as a first-class discipline — this skill puts that instinct on rails.
Guides 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.
Reach for this when a bug turns into a guessing spiral and you want a checklist that forces triage before fixes. Addy Osmani (engineering lead at Google Chrome) encodes the "preserve evidence, find root cause, then fix" discipline that separates a clean postmortem from a flaky patch. Useful for test failures, runtime bugs, and production incidents alike.
Delivers 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.
Reach for this when a task is starting to sprawl and you want to land value in slices instead of one giant PR. Addy Osmani (engineering lead at Google Chrome) codifies the "small, reviewable, reversible" habit that keeps velocity honest under agentic code output.
For teams shipping React or Next.js. Use when writing, reviewing, or refactoring components, data fetching, or rendering paths — covers waterfall elimination, bundle size, server-side performance, and re-render optimization across 70 prioritized rules.
Reach for this when you're on React or Next.js and want a single, opinionated rulebook from the team that maintains the framework. Vercel's engineers organize it by impact (CRITICAL → LOW), so it doubles as a review checklist for performance-sensitive PRs.
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
Reach for this when you're shipping a React Native or Expo app and want a prioritized rulebook from the team behind the framework. Vercel organizes the guidelines by impact (CRITICAL → LOW) across list performance, animations, navigation, and native integration, so it works both as a build-time guide and a review checklist.
Grounds 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.
Reach for this when you want the agent to cite documentation rather than hallucinate outdated APIs. Addy Osmani (engineering lead at Google Chrome) has seen enough framework churn firsthand — this skill forces every decision back to the canonical source.
Drives 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.
Reach for this when you want the red-green-refactor loop as a default habit, not a Sunday-project thing. Addy Osmani (engineering lead at Google Chrome) has long pushed TDD as the cheapest way to keep agent output honest — this skill carries that into daily practice.
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Reach for this as the meta-skill that teaches your agent how to find and invoke the rest. Addy Osmani (engineering lead at Google Chrome) treats skill discovery as a first-class problem, not a lookup — this is the entry point for any agentic workflow that plans to grow.
Tests in real browsers. 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 via Chrome DevTools MCP.
Reach for this when "works locally" isn't enough and you want verification against real DOM, network, and runtime state. Addy Osmani (engineering lead at Google Chrome) leans on DevTools as the source of truth for frontend behavior — this skill wires that into an agent-friendly loop.
Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.
Reach for this when Core Web Vitals, load time, or runtime profiling point at a regression you can't just eyeball. Addy Osmani (engineering lead at Google Chrome) literally wrote large parts of the web-performance playbook — this skill distills that into a measure-first workflow.
Prepares 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.
Reach for this when a feature is "done" but not yet safe to go live. Addy Osmani (engineering lead at Google Chrome) treats launch hygiene — checklists, monitoring, staged rollout, rollback — as non-negotiable plumbing, and this skill makes sure none of it gets skipped in the rush.
Automates 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.
Reach for this when you want a thorough, opinionated CI/CD playbook from someone who has shipped at scale. Addy Osmani (engineering lead at Google Chrome) has long written about the craft of releasing web software, and his agent-skills repo distills that into a quality-gate pipeline you can drop into a new project on day one.
Deploy applications and websites to Vercel. Use when the user requests deployment actions like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment".
Reach for this when you're already on (or moving to) Vercel and want an agent that drives the CLI correctly — it defaults to preview deploys, handles team scoping, and nudges you toward the linked-project + git-push setup that makes every future deploy a one-liner. Maintained by Vercel's own team, so it tracks CLI changes closely.
Structures 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.
Reach for this when git habits are the thing holding velocity back: tangled branches, "fix" commits, conflict anxiety. Addy Osmani (engineering lead at Google Chrome) encodes a clean everyday workflow that keeps history useful rather than decorative.
Hardens 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.
Reach for this when a feature touches untrusted input, auth, or external services and you want the baseline checklist applied before review. Addy Osmani (engineering lead at Google Chrome) captures the common hardening moves that catch most preventable issues well before a pentest surfaces them.