Development and Engineering Skills

Build, test, and debug

Skill	Pick it when	Important distinction
`$implement`	A spec, ticket, or agreed plan is ready to build.	It executes; it is not the discovery phase.
`$tdd`	Behavior can be tested through a stable public interface and you want red-green-refactor.	Do not force it onto exploratory work with no stable seam.
`$test-driven-development`	The same red-green-refactor loop, stated as a hard discipline: no production line without a failing test first, and the test must be watched to fail.	It competes with `$tdd` — pick one. This one is stricter and refuses to let an agent write the implementation first; `$tdd` reads as guidance and bends more easily on exploratory work.
`$subagent-driven-development`	A plan is already written and its phases can be handed to fresh subagents one at a time, each starting without the previous one's context.	It is an execution strategy, not a planner: it needs a written plan to consume. Do not pick it for a change one session can hold — the context resets cost more than they save.
`$verification-before-completion`	You are about to report something as done and want the claim checked against what was actually run.	It verifies your own claims at the end of a change; it does not review the code's design. Reach for `$code-review` for that.
`$systematic-debugging`	Something is broken and the root cause is unknown.	Start here before proposing fixes.
`$diagnosing-bugs`	A bug is especially hard, intermittent, or performance-related.	It overlaps with systematic debugging; choose one lead.
`$qa` (deprecated upstream)	A person wants to report several problems conversationally and create issues.	This is issue capture, not an automated test runner. Upstream no longer maintains it.
`$playwright-cli` (Claude Code only)	A change has to be checked in a real browser, or a Playwright test written from an observed flow: navigate, click, fill, screenshot, mock the network, record a trace.	It drives a browser; it does not review the code behind the page. Reach for `/screenshot` instead when the target is a native app or the whole desktop.
`$ponytail`	A change should stay as small as it can be: prefer the standard library, a native platform feature, or an existing helper over new code, and skip speculative abstraction.	It constrains how the code is written, so it stacks on top of `$implement` or `$tdd` rather than replacing them. Do not pick it when the requirement really is the full version — it argues for less, and it never trims validation, error handling, or security.
`$setup-pre-commit`	You want commit-time formatting, type checks, and tests.	It changes repository tooling.
`$migrate-to-shoehorn`	TypeScript tests need migration away from `as` assertions.	It is a narrow migration tool.

Architecture and domain

Skill	Best use
`$codebase-design`	Shape one module boundary or API using deep-module principles.
`$design-an-interface` (deprecated upstream)	Generate and compare multiple different module interfaces; unmaintained, so prefer `$codebase-design` unless you specifically want parallel variants.
`$improve-codebase-architecture`	Scan the broader repository for architectural opportunities.
`$domain-modeling`	Clarify domain concepts, boundaries, terminology, and decisions over time.
`$ubiquitous-language` (deprecated upstream)	Extract a focused DDD glossary from the current conversation; unmaintained, and `$domain-modeling` now covers the same ground.
`$request-refactor-plan` (deprecated upstream)	Produce a safe, incremental refactor plan; unmaintained, so consider `$wayfinder` then `$to-tickets` for large refactors.
`$graphify`	Build and query a persistent relationship map for a large or unfamiliar codebase.
`$setup-ts-deep-modules`	Enforce deep modules mechanically in a TypeScript repo: dependency-cruiser rules that hide implementation behind entry points. Use after `$codebase-design` has settled the boundaries — it installs tooling, it does not decide the design.

Reviews and repository operations

Skill	Use it for
`$code-review`	Default review: documented standards and requested behavior as separate axes, since a fixed point you name.
`$thermo-nuclear-code-quality-review`	An intentionally severe maintainability and abstraction audit.
`$ponytail-review`	One question about a diff: what can be deleted? Reinvented standard library, a dependency that earns nothing, an interface with one implementation.
`$ponytail-audit`	The same hunt across a whole repository rather than a diff, ranked by what to cut first.
`$ponytail-debt`	Collecting the `ponytail:` comments left behind by earlier shortcuts into one ledger of what was deferred.
`$vercel-react-best-practices`	React/Next.js performance implementation or review.
`$comment-audit`	The closing pass on a change: read every comment in the changed files and delete the ones that narrate the task or restate the code. Ask for a directory or the whole repository to sweep stale comments instead. Run it after lint, build, and tests, not instead of a review — it judges comments only and never touches behavior.
`$requesting-code-review`	Sending a change out for review: assembling the diff, the context a reviewer needs, and what to look at first.
`$receiving-code-review`	Working through review feedback you have been given, deciding what to accept, push back on, or defer. Pair it with `$requesting-code-review` at the other end; neither one performs the review itself.
`$using-git-worktrees`	Work that should happen off the current checkout — a parallel branch, an experiment, or an agent that needs its own working copy.
`$finishing-a-development-branch`	Closing a branch out: the merge-or-abandon decision, then cleaning up the branch and its worktree.
`$resolving-merge-conflicts`	An active merge or rebase conflict.
`$git-guardrails-claude-code`	Install hooks that block dangerous Git commands in Claude Code.

Vercel platform (Claude Code only)

Ships in the vercel plugin. Reach for these only when the work is actually on Vercel or Next.js — a generic React or deploy question is served better by the framework-neutral leads above. Within the cluster, match the skill to the surface you are touching.

Skill	Pick it when
`$nextjs`	Building, debugging, or architecting a Next.js App Router app — routing, Server Components/Actions, rendering, middleware.
`$next-cache-components`	Working specifically with Next.js 16 Cache Components: PPR, `use cache`, `cacheLife`/`cacheTag`, migrating off `unstable_cache`.
`$next-upgrade`	Upgrading Next.js versions with the official codemods and migration guides.
`$next-forge`	Working in or scaffolding a next-forge Turborepo SaaS monorepo.
`$turbopack`	Configuring the Next.js bundler — HMR, build issues, Turbopack vs Webpack tradeoffs.
`$shadcn`	Installing or composing shadcn/ui components, custom registries, theming with Tailwind.
`$ai-sdk`	Building AI features with the Vercel AI SDK — chat, generation, structured output, tool calling.
`$ai-gateway`	Routing across AI providers: failover, cost tracking, one unified endpoint.
`$build-agents`	Generic "build an AI agent/app" requests where the framework is not yet fixed.
`$chat-sdk`	Multi-platform chat bots — Slack, Telegram, Teams, Discord, Linear.
`$eve`	Creating, editing, or debugging an eve durable-agent project.
`$workflow`	Durable long-running tasks needing pause/resume, retries, steps.
`$deployments-cicd`	Deploying, promoting, rolling back, `--prebuilt` builds, CI/CD wiring.
`$vercel-cli`	CLI-driven deploys, env vars, project linking, logs, metrics, domains.
`$bootstrap`	Standing up a repo that depends on Vercel-linked resources (DB, auth, integrations).
`$env-vars`	`.env` files, `vercel env`, OIDC tokens, per-environment config.
`$vercel-storage`	Choosing/using Blob, Edge Config, or Marketplace storage (Neon, Upstash).
`$vercel-functions`	Serverless/Edge Functions, Fluid Compute, streaming, Cron.
`$runtime-cache`	The ephemeral per-region Runtime Cache API with tag invalidation.
`$cdn-caching`	Debugging CDN cache — hit rate, stale content, revalidation, `cacheReason`.
`$routing-middleware`	Framework-agnostic request interception: rewrites, redirects, personalization.
`$microfrontends`	Multi-zone microfrontends, splitting an app across deployments.
`$vercel-services`	Composing multiple frontends/backends (polyglot) in one project.
`$create-a-backend`	Choosing the backend shape up front — Functions vs Services vs containers, Workflow, Queues, a Marketplace database, a framework/runtime. Pick it when the question is what to build the API on; use `$vercel-functions` once that is settled and you are writing the function.
`$flags-sdk`	Feature flags with `flag()`, provider adapters (Statsig, LaunchDarkly, PostHog), the `vercel flags` CLI, precompute A/B tests. For flags specifically — not general env config, which is `$env-vars`.
`$marketplace`	Discovering and installing third-party integrations via `vercel integration`.
`$auth`	Adding Clerk, Descope, or Auth0 auth to a Next.js app.
`$access-protected-vercel-deployment`	Reaching a deployment behind Vercel Authentication/SSO/Deployment Protection from curl, Playwright, or an agent.
`$vercel-connect`	Obtaining scoped OAuth tokens for third-party services on a user's behalf.
`$vercel-firewall`	WAF rules, DDoS mitigation, IP blocking, rate limiting, Attack Mode.
`$vercel-sandbox`	Running untrusted code in ephemeral Firecracker microVMs.
`$vercel-agent`	Vercel's AI code review and incident investigation.
`$verification`	End-to-end flow verification: browser → API → data → response.
`$react-best-practices`	A condensed React/TSX quality checklist after editing components. Overlaps `$vercel-react-best-practices` above — this one is the plugin's lighter post-edit pass.

Codex Sites (Codex only)

Ships in the sites Codex plugin. Reach for these to build and publish a site inside Codex's Sites runtime specifically — a general Next.js or Vercel deploy question belongs in the Vercel cluster above.

Skill	Pick it when
`$sites-building`	Building a site with Sites — landing pages, portfolios, dashboards, portals, internal tools.
`$sites-hosting`	Publishing, deploying, or managing hosting for a Sites project. Always the step after `$sites-building`.

Apple platform (Claude Code only)

Ships in the apple-skills plugin. Pick these for Swift/SwiftUI and Apple-OS work; the visual side of Apple design lives in the design guide as /design, and the business-facing Apple skills (App Store, growth, legal) sit in the planning guide.

Skill	Pick it when
`$swiftui`	SwiftUI data flow, layout, containers, Observation, state ownership.
`$swiftdata`	SwiftData models — inheritance, type-based querying, polymorphic relationships.
`$swift-development`	Swift language-level review or guidance: concurrency, performance, modern idioms.
`$ios-development`	iOS app work — SwiftUI patterns, HIG review, app planning.
`$macos-development`	macOS work — Swift 6+, SwiftUI, SwiftData, AppKit bridging, Tahoe APIs.
`$visionos`	visionOS spatial design and widget patterns.
`$watchOS`	watchOS — SwiftUI for Watch, Watch Connectivity, complications.
`$foundation`	AttributedString / rich-text formatting integrated with SwiftUI.
`$mapkit`	MapKit and GeoToolbox — PlaceDescriptor, geocoding, place identifiers.
`$performance`	Instruments profiling and SwiftUI perf: hangs, memory, slow launch, energy.
`$testing`	TDD and testing for Apple apps — characterization, snapshot, test contracts.
`$security`	Apple-platform privacy manifests and secure-storage routing.
`$generators`	Generating production-ready Swift for common components (logging, analytics, onboarding).

Typical development flow: understand the domain, design the smallest stable interface, implement one slice, then review. Use fewer skills when the change is already clear.