Skills & Commands

AI Kit generates 48 skills across two formats — skills for auto-discovery, and legacy commands for backward compatibility.

Skills vs Commands

What Are Skills?

Skills are the same structured workflow prompts as commands, but packaged in a way that lets the AI auto-discover and apply them without you typing a slash command. Each skill file contains a description the AI reads to understand what the skill covers and when to use it.

When you ask the AI to “review my PR changes” or “scaffold a new component”, it reads the skill descriptions, identifies the right one, and applies it — even if you’ve never heard of /review or /new-component.

Auto-Discovery

Skills are automatically discovered by the AI at the start of each conversation. The AI reads each skill’s description and builds an internal map of what workflows are available. When your request matches a skill’s purpose, the AI applies it without prompting.

This means:

• Zero learning curve — developers don’t need to memorize command names
• Higher utilization — skills get applied even when developers don’t think to invoke them
• Cursor support — Cursor users get the full workflow library, not just Claude Code users

Legacy Commands Still Work

If you already use slash commands like /review or /pre-pr, they continue to work in Claude Code exactly as before. AI Kit generates both formats in every project — skills for auto-discovery and cross-platform support, commands for existing workflows.

Quick Reference

Getting Started

These two commands are the best entry points when you’re new to the project or unsure how to phrase a request.

/prompt-help

The most important command. If you’re not sure how to ask the AI for something, start here. It runs an interactive prompt builder that walks you through what you’re trying to do, which files are involved, what constraints exist, and what success looks like — then generates a ready-to-paste prompt for you.

Usage

/prompt-help

When to use: Any time you’re stuck on how to phrase a request, or you want to make sure you’re giving the AI enough context before a complex task.

What it asks you

• What type of task is this? (new feature, bug fix, refactor, etc.)
• Which files or areas of the codebase are involved?
• What constraints or conventions apply?
• What does “done” look like?

/understand

Explains any piece of code in plain language. Point it at a file, function, or module and it returns a structured breakdown that covers purpose, architecture fit, data flow, dependencies, edge cases, and related files worth reading.

Usage

/understand src/lib/auth.ts
/understand src/components/Header.tsx
/understand src/app/api/products/route.ts

When to use: When onboarding to a new project, inheriting unfamiliar code, or before refactoring something you didn’t write.

What it covers

• The single responsibility of the file or function
• How it fits into the broader architecture
• Inputs, outputs, and data flow
• Known edge cases or gotchas
• Related files that provide full context

Building

Commands for creating new code that follows project conventions from the start.

/new-component

Scaffolds a complete new component by asking a series of structured questions. The output follows your project’s naming conventions and generates everything the component needs to be production-ready.

Usage

/new-component
/new-component ProductCard
/new-component NavigationMenu

When to use: Every time you create a new component. This ensures consistency — it’s far easier to start with the right structure than to retrofit it later.

What it generates

• Component file with typed props interface
• Barrel export
• JSDoc documentation
• Test file with RTL happy-path and edge case tests
• Optional Storybook story
• Optional doc file in docs/components/
• Sitecore component manifest (if XM Cloud project)

/new-page

Scaffolds a new route with all the supporting files your router needs. Detects whether you’re using App Router or Pages Router and generates the appropriate file structure.

Usage

/new-page
/new-page products/[id]
/new-page checkout/confirmation

When to use: Whenever you add a new URL to the application. Handles the boilerplate so you can focus on the page logic.

What it generates

• page.tsx (App Router) or the page file (Pages Router)
• layout.tsx if a new layout scope is needed
• loading.tsx for streaming and Suspense boundaries
• error.tsx for route-level error handling
• getServerSideProps or getStaticProps stubs for Pages Router

/api-route

Creates a fully typed API route handler with input validation, error handling, and response shaping. Follows Next.js conventions and adds the structure needed for a maintainable endpoint.

Usage

/api-route
/api-route POST /api/orders
/api-route GET /api/users/[id]

When to use: When adding a new API endpoint. Prevents the common pattern of writing route handlers without validation or consistent error responses.

What it generates

• Typed request/response interfaces
• Input validation with Zod
• Structured error handling with appropriate HTTP status codes
• JSDoc for the handler
• A basic test file for the route

/error-boundary

Adds a React error boundary to a component tree. Generates the boundary component itself along with a fallback UI, and wraps the target component so errors are caught and displayed gracefully rather than crashing the page.

Usage

/error-boundary
/error-boundary src/components/ProductList.tsx

When to use: When a component relies on external data or has failure modes that should be contained — especially before shipping to production.

What it generates

• ErrorBoundary class component
• Fallback UI component with reset affordance
• Wrapping of the target component
• Optional logging hook for error reporting

/extract-hook

Pulls logic out of a component and into a reusable custom hook. Identifies state, effects, and derived values that belong outside the render function and moves them cleanly while keeping the component readable.

Usage

/extract-hook src/components/ProductFilter.tsx
/extract-hook src/components/SearchBar.tsx useSearch

When to use: When a component is getting long, when the same logic appears in multiple components, or when you want to test logic independently from the UI.

What it generates

• Named custom hook file in hooks/
• Updated component importing the hook
• JSDoc for the hook’s parameters and return values
• Test file for the hook in isolation

/figma-to-code

Structured workflow for translating a Figma design into code. Uses the Figma MCP (if configured) to extract design context, maps visual properties to existing project tokens, identifies reusable components, and implements with correct responsive breakpoints.

Usage

/figma-to-code
/figma-to-code https://figma.com/file/...

When to use: Any time you’re implementing a Figma design. Prevents the habit of hardcoding values that should reference design tokens.

What it checks

• Figma frame dimensions and spacing
• Token mapping (colors, typography, spacing)
• Reuse opportunities against existing components
• Responsive behavior at each breakpoint
• Visual fidelity verification steps

/design-tokens

Audits and manages the design token system for your project. Maps Figma token names to Tailwind config values or CSS custom properties, surfaces any hardcoded values that should be using tokens, and generates token documentation.

Usage

/design-tokens
/design-tokens audit
/design-tokens src/components/Button.tsx

When to use: When setting up a new project’s token system, after a design update introduces new tokens, or when auditing for consistency before a design review.

What it covers

• Current token inventory (colors, spacing, typography, radius)
• Hardcoded values that should reference tokens
• Mismatches between Figma tokens and Tailwind config
• Generated token reference documentation

/schema-gen

Generates TypeScript interfaces and Zod validation schemas from API responses, JSON samples, or GraphQL schemas.

Usage

/schema-gen
/schema-gen src/api/response.json
/schema-gen https://api.example.com/products

When to use: When integrating a new API, when API responses change, or when you need runtime validation alongside types.

What it generates

• TypeScript interfaces with proper optionality
• Zod schemas for runtime validation
• Type guards for narrowing
• API response wrapper types

/storybook-gen

Generates comprehensive Storybook stories for a component with typed controls, play functions for interaction testing, and visual state coverage.

Usage

/storybook-gen src/components/Button.tsx
/storybook-gen src/components/Modal.tsx

When to use: After creating a new component, when adding Storybook to a project, or when expanding story coverage.

What it generates

• CSF3 stories with satisfies Meta typing
• Stories for every meaningful prop combination and visual state
• Play functions for interactive components
• Accessibility test integration

/scaffold-spec

Generates a feature specification document before writing any code. Captures the problem, proposed solution, acceptance criteria, edge cases, and open questions — giving you and the AI a shared written contract before implementation starts.

Usage

/scaffold-spec
/scaffold-spec dark mode support
/scaffold-spec user notification preferences

When to use: Before starting a significant new feature, when requirements are fuzzy, or when you want to align with a reviewer before committing to an implementation approach.

What it generates

• Problem statement and motivation
• Proposed solution with key design decisions
• Acceptance criteria (testable, specific)
• Out-of-scope items (explicit non-goals)
• Edge cases and error states to handle
• Open questions requiring answers before implementation

Saves to docs/specs/[feature-name].md.

Quality & Review

Commands for catching problems before they reach production or a reviewer.

/review

Deep code review following project standards. Goes beyond linting — it evaluates structure, intent, and maintainability.

Usage

/review
/review src/components/CheckoutForm.tsx
/review src/lib/api.ts

When to use: Before creating a PR, or when reviewing someone else’s code with AI assistance.

What it checks

• Naming convention violations
• Component structure and separation of concerns
• Missing error handling
• Accessibility gaps (missing ARIA, keyboard nav)
• Performance anti-patterns (unnecessary re-renders, N+1)
• Security issues (XSS, unvalidated inputs, exposed secrets)
• Import order and barrel export consistency
• Missing or outdated JSDoc

/pre-pr

Runs a full pre-PR checklist before you open a pull request. Combines review, test coverage check, accessibility audit, and documentation check into a single workflow that produces a clear go/no-go summary.

Usage

/pre-pr
/pre-pr src/features/checkout/

When to use: As the last step before pushing a branch and opening a PR. Catches issues that reviewers would otherwise flag.

What it checks

• Code review against project standards
• Test file presence and coverage for changed files
• JSDoc on exported functions and components
• Accessibility compliance for any UI changes
• No console logs, debug code, or TODO comments left in
• Branch name and commit message format

/test

Generates a test file for any component, hook, or utility function. Produces behavior-driven tests using React Testing Library, covering the happy path, error states, and edge cases.

Usage

/test src/components/Header.tsx
/test src/hooks/useCart.ts
/test src/lib/formatPrice.ts

When to use: After writing a new component or utility, or when increasing test coverage on existing code.

What it generates

• Happy path tests for primary use cases
• Error state and boundary condition tests
• Edge case tests (empty data, max values, etc.)
• Accessibility tests for interactive components (role, label, keyboard)
• Tests colocated next to the source file following project conventions

/accessibility-audit

Audits a component or page for WCAG 2.1 AA compliance issues. Covers semantic HTML, keyboard navigation, ARIA usage, color contrast guidance, and screen reader behavior.

Usage

/accessibility-audit src/components/Modal.tsx
/accessibility-audit src/app/checkout/page.tsx

When to use: Before shipping any interactive UI, when a component receives focus-related feedback, or as part of an accessibility sprint.

What it checks

• Semantic HTML element usage
• Focus management and visible focus indicators
• ARIA roles, labels, and descriptions
• Keyboard navigability (Tab, Enter, Escape, arrow keys)
• Alt text on images
• Form label associations
• Color contrast recommendations

/security-check

Scans code for common security vulnerabilities relevant to Next.js and React applications. Produces a prioritized list of issues with remediation guidance.

Usage

/security-check src/app/api/
/security-check src/components/RichTextEditor.tsx

When to use: Before shipping new API routes, when handling user-generated content, or during a security review sprint.

What it checks

• XSS vectors (dangerouslySetInnerHTML, unsanitized input rendering)
• Unvalidated or unsanitized API inputs
• Exposed environment variables or secrets
• Insecure direct object references in route params
• Missing authentication/authorization guards
• CSRF exposure in mutation endpoints
• Dependency versions with known CVEs

/responsive-check

Verifies that a component or page handles all required responsive breakpoints correctly. Maps your Tailwind breakpoint config to the design system and identifies gaps or inconsistencies.

Usage

/responsive-check src/components/NavigationBar.tsx
/responsive-check src/app/products/page.tsx

When to use: Before shipping any layout change, when a component looks off on mobile, or during a responsive QA pass.

What it checks

• Breakpoint coverage (mobile, tablet, desktop, wide)
• Missing responsive variants on layout-affecting classes
• Hardcoded widths or heights that break at small viewports
• Touch target sizes (minimum 44x44px)
• Overflow and scrolling behavior at each size
• Image scaling and aspect ratio handling

/type-fix

Resolves TypeScript errors in a file and tightens loose typing. Explains the root cause of each error, applies the fix, and avoids the anti-pattern of silencing errors with any or // @ts-ignore.

Usage

/type-fix src/components/DataTable.tsx
/type-fix src/lib/api-client.ts

When to use: When TypeScript is reporting errors you’re not sure how to fix, or after upgrading a dependency that changed its type signatures.

What it covers

• Root cause explanation for each type error
• Correct fix using proper TypeScript patterns
• Tightening of overly broad any or unknown usages
• Generic type improvements where applicable
• Import of missing type dependencies

/perf-audit

Lighthouse-style performance audit covering Core Web Vitals, resource loading, render-blocking resources, and caching strategies.

Usage

/perf-audit
/perf-audit src/app/page.tsx

When to use: Before a performance review, when Lighthouse scores are low, or after shipping a large feature.

What it checks

• Core Web Vitals (LCP, CLS, INP)
• Resource loading and render-blocking assets
• Font loading strategies
• Third-party script impact
• Caching headers and strategies

/bundle-check

Analyzes bundle size, identifies heavy imports, suggests tree-shaking opportunities, and recommends code splitting points.

Usage

/bundle-check
/bundle-check src/components/Dashboard.tsx

When to use: Before a release, when bundle size has grown, or when page load times have increased.

What it checks

• Heavy dependencies and lighter alternatives
• Tree-shaking opportunities (named vs default imports)
• Dynamic import candidates for code splitting
• Duplicate packages in the bundle
• Import cost analysis

/i18n-check

Finds hardcoded user-facing strings, missing translation keys, and internationalization gaps including RTL support and locale formatting.

Usage

/i18n-check
/i18n-check src/components/

When to use: Before launching in a new locale, during an i18n sprint, or when auditing for localization readiness.

What it checks

• Hardcoded user-facing strings that should be translated
• Missing translation keys across locale files
• String concatenation that should use interpolation
• Date, number, and currency formatting
• RTL layout support

/test-gaps

Analyzes a file or directory and identifies code paths that are not covered by existing tests. Produces a prioritized list of missing test cases rather than a generic coverage report.

Usage

/test-gaps src/components/CheckoutForm.tsx
/test-gaps src/lib/pricing.ts
/test-gaps src/hooks/useCart.ts

When to use: When increasing test coverage on existing code, before a release, or when a bug was caught in production and you want to identify similar gaps.

What it produces

• List of untested branches, conditions, and error states
• Suggested test case descriptions for each gap
• Priority ranking (high/medium/low) based on code criticality
• Estimated test count to reach meaningful coverage

Maintenance

Commands for improving, fixing, and managing existing code.

/fix-bug

Guided systematic debugging workflow. Forces a structured approach — describe the bug, identify reproduction steps, locate the root cause, implement the fix, verify with tests — instead of jumping straight to guessing a solution.

Usage

/fix-bug
/fix-bug src/components/CartSummary.tsx

When to use: When you encounter a bug and want to avoid the trial-and-error spiral. Especially useful for bugs where the cause isn’t immediately obvious.

What it produces

• Structured bug description (expected vs. actual)
• Hypothesis for root cause with supporting evidence
• Targeted fix with explanation
• Regression test to prevent recurrence
• Notes on any related areas that may be affected

/refactor

Refactors a file or function to improve readability, reduce duplication, or align with current conventions — while preserving the existing behavior. Proposes the approach before making changes.

Usage

/refactor src/components/ProductList.tsx
/refactor src/lib/utils.ts

When to use: When a file has grown too large, when you spot repeated logic, or when code conventions have evolved and an older file hasn’t kept up.

What it covers

• Extraction of reusable logic into hooks or utilities
• Reduction of prop drilling
• Simplification of complex conditionals
• Alignment with current naming conventions
• No behavior changes — refactor only

/optimize

Performance analysis and optimization for a component or page. Identifies specific, actionable improvements rather than generic advice.

Usage

/optimize src/components/ProductGrid.tsx
/optimize src/app/dashboard/page.tsx

When to use: When a page feels slow, before a performance audit, or when reviewing a component that handles large data sets.

What it analyzes

• Unnecessary re-renders and missing memoization (useMemo, useCallback, memo)
• Heavy computations running in the render path
• Bundle size impact and code splitting opportunities
• Image optimization (format, size, lazy loading)
• Data fetching patterns (N+1 queries, request waterfalls)
• Server vs. Client Component boundary placement

/migrate

Migrates code from one API, pattern, library version, or convention to another. Documents what changed and why, so the diff is reviewable and reversible.

Usage

/migrate src/components/ --from pages-router --to app-router
/migrate src/lib/api.ts --from axios --to fetch
/migrate src/components/Form.tsx --from react-hook-form-v6 --to react-hook-form-v7

When to use: During a library upgrade, when adopting a new pattern project-wide, or when migrating from one router to another.

What it covers

• Inventory of files that need changes
• Mapping of old API to new API
• Automated changes where safe
• Manual review flags for ambiguous cases
• Migration notes in the relevant doc file

/dep-check

Audits project dependencies for outdated versions, known vulnerabilities, duplicates, and unused packages. Produces a prioritized action list rather than a raw dump of every package.

Usage

/dep-check
/dep-check --security-only

When to use: Before a release, after a security advisory, or when the lockfile hasn’t been reviewed in a while.

What it checks

• Packages with known CVEs (cross-referenced against advisories)
• Significantly outdated minor/major versions
• Duplicate packages at different versions
• Packages present in dependencies that should be devDependencies
• Unused packages that can be removed
• Peer dependency conflicts

/sitecore-debug

Debugs Sitecore XM Cloud-specific problems. Covers the common failure points in the Sitecore + Next.js integration — component registration, field mapping, rendering host config, and personalization rules.

Usage

/sitecore-debug
/sitecore-debug src/components/HeroBanner.tsx

When to use: When a Sitecore component isn’t rendering, fields aren’t mapping correctly, or the rendering host is failing to connect.

What it checks

• Component registration in ComponentBuilder / componentFactory
• Field type alignment between Sitecore template and component props
• withDatasourceCheck and withPlaceholderProps usage
• Layout service response structure
• Rendering host environment variables and proxy config
• Personalization and variant rendering issues
• Edge Config and preview mode setup

/upgrade

Guides a major dependency upgrade from start to finish. Reads the package’s migration guide, identifies breaking changes in your codebase, and produces a step-by-step plan before touching any code.

Usage

/upgrade react 18 → 19
/upgrade next.js 14 → 15
/upgrade tailwindcss 3 → 4

When to use: Before any major version bump where breaking changes are expected.

What it covers

• Official migration guide summary for your version range
• Files in your project affected by breaking changes
• Codemods available to automate safe changes
• Manual changes required with file and line references
• Test strategy to verify the upgrade

Workflow

Commands that support day-to-day development process rather than specific code tasks.

/document

Generates JSDoc for exported functions and components, creates or updates README files, and produces component documentation in docs/components/. Targets a file or directory.

Usage

/document src/components/Button.tsx
/document src/hooks/
/document src/lib/api-client.ts

When to use: After writing a new module, before a PR that touches public API surface, or when running a documentation sprint.

What it generates

• JSDoc on all exported functions, components, and interfaces
• @param, @returns, and @example tags
• Props table in the component’s doc file
• README update if the module is a significant feature
• Coverage report showing documented vs. undocumented exports

/commit-msg

Writes a conventional commit message for your currently staged changes. Reads the diff, infers the type and scope, and produces a message that follows the type(scope): description format with an optional body.

Usage

/commit-msg
/commit-msg --with-body

When to use: When you’ve staged your changes and want a well-formed commit message without writing it from scratch.

What it produces

• Conventional commit type (feat, fix, refactor, chore, docs, etc.)
• Scope derived from the files changed
• Concise imperative description under 72 characters
• Optional body with bullet points summarizing key changes
• Co-Authored-By trailer if applicable

/env-setup

Sets up local environment variables and configuration for a new developer joining the project. Reads existing .env.example files, explains what each variable does, and generates a populated .env.local with safe defaults.

Usage

/env-setup
/env-setup --service sitecore
/env-setup --service vercel

When to use: When onboarding to a project for the first time, after cloning the repo, or when a new service integration requires new environment variables.

What it covers

• Parsing .env.example with explanations for each variable
• Required vs. optional variable identification
• Safe local defaults where applicable
• Service-specific setup steps (Sitecore rendering host, Vercel env, etc.)
• Links to where secrets can be retrieved (without logging the secrets themselves)

/changelog

Generates a formatted changelog entry from git history since the last release tag, categorized by change type following the Keep a Changelog format.

Usage

/changelog
/changelog --since v1.0.0

When to use: Before a release, when preparing release notes, or when catching up on what changed.

What it produces

• Categorized changes (Added, Fixed, Changed, Breaking)
• Scope grouping from conventional commits
• User-facing descriptions (not raw commit messages)
• Semantic version bump recommendation

/release

Guided release workflow that walks through version decision, changelog generation, package.json update, git tag creation, and release notes preparation.

Usage

/release
/release --type minor

When to use: When cutting a new release. Ensures nothing is missed in the release process.

What it produces

• Pre-release state check (clean tree, tests passing)
• Version bump recommendation with reasoning
• Complete changelog entry
• Copy-pasteable release commands
• Post-release verification checklist

/pr-description

Generates a structured pull request description from your staged changes and branch diff. Reads the diff, infers the type of change, and produces a description ready to paste into GitHub, GitLab, or Bitbucket.

Usage

/pr-description
/pr-description --base main

When to use: When opening a PR and you want a clear, reviewer-friendly description without writing it from scratch.

What it produces

• Summary of what changed and why
• Type of change (feature, fix, refactor, chore)
• List of files modified with brief descriptions
• Testing instructions for the reviewer
• Screenshots or demo instructions placeholder (if UI changes detected)
• Breaking changes flag (if applicable)

/standup

Summarizes your AI session activity from the previous day into a standup-ready update.

Usage

/standup
/standup --date yesterday

When to use: At the start of your day to prepare your standup contribution based on what the AI helped you accomplish.

What it produces

• What was completed (based on session files and git log)
• What’s in progress
• Any blockers encountered
• Formatted for pasting into Slack or a standup tool

/learn-from-pr

Extracts lessons, patterns, and decisions from a merged pull request and logs them to docs/decisions-log.md.

Usage

/learn-from-pr
/learn-from-pr https://github.com/org/repo/pull/123
/learn-from-pr --branch feature/checkout-redesign

When to use: After merging a significant PR to capture what was decided, why, and what the team should do differently next time.

What it extracts

• Key architectural or implementation decisions made in the PR
• Patterns introduced that should be followed project-wide
• Mistakes or rework that happened — and how to avoid them
• Anything that should be added to the CLAUDE.md rules

Appends a dated entry to docs/decisions-log.md.

/release-notes

Generates user-facing release notes from a git range or version tag. Unlike /changelog (which is developer-focused), release notes are written for end users or stakeholders.

Usage

/release-notes
/release-notes --since v1.3.0
/release-notes --tag v1.4.0

When to use: When publishing a release to users, writing GitHub Release notes, or preparing a product update announcement.

What it produces

• User-facing summary of what’s new (not raw commit messages)
• New features with brief descriptions
• Bug fixes that users would notice
• Breaking changes or migration steps (if any)
• Formatted for GitHub Releases, Notion, or a changelog page

Using Skills and Commands

Auto-Discovery (Recommended)

Just describe what you want. The AI reads skill descriptions and applies the right one automatically:

Review my CheckoutForm before I open a PR
Scaffold a new ProductCard component
Fix the TypeScript errors in DataTable.tsx

This works in both Claude Code and Cursor.

Explicit Slash Commands (Claude Code)

In Claude Code, you can also invoke any workflow by name:

/prompt-help

Most commands work best with a target file or argument:

/new-component ProductCard
/understand src/lib/auth.ts
/test src/components/Header.tsx
/review src/features/checkout/
/accessibility-audit src/components/Modal.tsx

Tips

Skills and commands work best when you provide context. The more specific you are about the file, behavior, and constraints, the more useful the output.

If you’re ever unsure what to reach for, run /prompt-help first — it will guide you to the right workflow.

Session Skills (v1.2.0)

/save-session

Category: Session

Save the current session state so it can be resumed later.

When to use: When you need to stop working but want to pick up exactly where you left off.

What it captures:

• Session summary (goal, progress, completion state)
• Files modified with descriptions
• Architectural and design decisions made
• Pending work checklist
• Current state (uncommitted changes, build status, blockers)

Saves to ai-kit/sessions/[date]-[time]-[topic].md.

/resume-session

Category: Session

Restore context from a saved session and continue where you left off.

When to use: When starting a new conversation and want to continue previous work.

What it does:

1. Lists available sessions from ai-kit/sessions/ (most recent first)
2. Presents a summary: what was done, what’s pending, key decisions
3. Verifies current file state matches expectations
4. Picks up from the first unchecked pending item

/checkpoint

Category: Session

Run all quality checks and record a verification snapshot.

When to use: Before committing, after a major change, or to track project health over time.

Checks performed:

• TypeScript (tsc --noEmit)
• Lint (ESLint)
• Format (Prettier or Biome)
• Tests (npm test)
• Build (npm run build)
• Security (npm audit)

Saves results to ai-kit/checkpoints/[date]-[time].md and compares against the previous checkpoint to flag regressions.

Orchestration Skills (v1.2.0)

/orchestrate

Category: Orchestration

Coordinate multiple specialized agents to tackle complex tasks.

When to use: Tasks spanning multiple concerns (feature + tests + docs + review), large changes requiring parallel analysis, or comprehensive audits.

What it does:

1. Breaks the task into independent subtasks
2. Maps each subtask to the right agent (planner, code-reviewer, security-reviewer, etc.)
3. Launches agents in parallel where possible
4. Collects results, identifies conflicts, and creates a unified action plan

/quality-gate

Category: Orchestration

Run all quality checks and present a pass/fail summary.

When to use: Before merging a PR or cutting a release. More comprehensive than /checkpoint — includes accessibility and bundle size checks.

Checks performed:

• TypeScript type check (zero errors)
• ESLint (zero warnings)
• Format (all files formatted)
• Unit tests (all passing)
• Build (succeeds)
• Bundle size (no significant increase)
• Accessibility (no critical violations)
• Security (no high/critical vulnerabilities)
• Console.log audit (none in production code)

Gate policy: All PASS = safe to merge. Any WARN = merge with acknowledgment. Any FAIL = fix before merge.

/harness-audit

Category: Orchestration

Audit the AI agent configuration for completeness and correctness.

When to use: After initial setup, after updating AI Kit, or when something feels off with AI behavior.

What it checks:

• CLAUDE.md exists with AI-KIT markers, no stale info, no secrets
• Hooks are syntactically correct and reference installed tools
• Agent frontmatter is valid, no duplicates or conflicts
• Context modes are present and actionable
• Skills directories are populated and valid
• MCP servers are relevant with no hardcoded credentials
• Config version matches installed AI Kit version

Outputs an overall health grade (A-F) with specific recommendations.

Requirements Skills (v1.7.0)

/deep-interview

Category: Requirements

Socratic requirements gathering — a structured interview that transforms vague ideas into detailed specifications before any code is written.

When to use: Before starting a significant new feature, when requirements are unclear, or when you want to avoid building the wrong thing.

What it does:

1. Asks problem-space questions (what problem, who experiences it, cost of inaction)
2. Establishes scope boundaries (MVP, explicit out-of-scope items)
3. Identifies users and stakeholders
4. Systematically explores edge cases (empty states, errors, accessibility, performance, security)
5. Validates understanding with the developer
6. Generates a complete feature specification document

Output can be saved to docs/specs/[feature-name].md.

/clarify-requirements

Category: Requirements

Quick task clarification — identifies gaps and ambiguities in a task description in under 5 minutes.

When to use: Before starting any task where the requirements feel slightly vague or incomplete. Much faster than /deep-interview — asks a maximum of 5 targeted questions.

What it does:

1. Analyzes the task for ambiguity across 6 dimensions (what, where, who, when, edge cases, scope)
2. Asks only the highest-impact questions (max 5, multiple choice when possible)
3. Provides best guesses with each question for quick confirmation
4. Produces a concise task brief with acceptance criteria

If the task is already clear, it skips questions and produces the brief immediately.