Write a precise, implementation-ready spec before any code is written. Use when a feature request is vague, ambiguous, or complex — turn fuzzy requirements into an unambiguous spec with acceptance criteria, edge cases, API contracts, and data shapes. Run before /orchestrate or /commit. Produces a written spec document — downstream of any brainstorming/planning skill, not a replacement for one.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Turn a vague request into an unambiguous, implementation-ready specification. Do not write any code until the spec is approved.
/spec <feature request> — clarify, read codebase, produce spec, get approvalAsk targeted questions to eliminate ambiguity:
Only ask questions that materially change the spec. Infer what you can from the codebase.
PROJECT_ROOT=$(git rev-parse --show-toplevel)
cd "$PROJECT_ROOT"
git log --oneline -10
Read relevant existing code: find related files with Grep/Glob, understand existing data shapes, API contracts, naming conventions. Note anything constraining the implementation.
## Feature: [name]
### Summary
One paragraph: what this does and why.
### Inputs
- [param]: [type] — [description, valid values, required/optional]
### Outputs / Side Effects
- [what changes, what is returned, what events are fired]
### Acceptance Criteria
- [ ] [specific, testable condition]
- [ ] [specific, testable condition]
### Edge Cases & Error Handling
- [condition] → [expected behavior]
### Out of Scope
- [explicitly list what this does NOT do]
### Open Questions
- [anything unresolved — flag for user to decide]
Present the spec. Do not proceed to implementation until the user says "approved", "lgtm", "ship it", or similar.
If the user requests changes: update the spec and re-present it.
Once approved: run /commit or hand off to implementation.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Act as a Senior Accessibility Engineer to audit a page, component, or design against WCAG 2.2 AA. Produces a triaged finding list (critical/serious/moderate), focus-order map, contrast report, ARIA decision tree, and a screen-reader test plan. Use when shipping new UI, hardening an existing flow, or preparing for VPAT/accessibility conformance.
The English summary is being prepared. Showing the original description.
When the user wants to plan, design, or implement an A/B test or experiment — "split test," "variant copy," "multivariate test," "hypothesis," "statistical significance," "how long should I run this test," or comparing two versions. For tracking implementation, see analytics-tracking. For page-level conversion optimization, see page-cro.
The English summary is being prepared. Showing the original description.
When the user wants to generate, iterate, or scale ad creative — headlines, descriptions, primary text, full variations — for any paid platform; 'ad copy variations,' 'RSA headlines,' 'bulk ad copy,' 'creative testing,' 'write me some ads.' For campaign strategy and targeting, see paid-ads. For landing page copy, see copywriting.
The English summary is being prepared. Showing the original description.
When the user wants content cited by LLMs or surfaced in AI-generated answers — 'AI SEO,' 'AEO,' 'GEO,' 'LLMO,' 'answer engine optimization,' 'AI Overviews,' 'optimize for ChatGPT/Perplexity/Claude,' 'AI citations,' 'zero-click search.' For traditional technical/on-page audits, see seo-audit. For structured data, see schema-markup.
The English summary is being prepared. Showing the original description.
When the user wants to set up, improve, or audit analytics tracking and measurement — "GA4," "conversion tracking," "event tracking," "UTM parameters," "tag manager," "GTM," "tracking plan," "attribution," "Mixpanel," "Segment," "are my events firing," or how to measure marketing results. For A/B test measurement, see ab-test-setup.
The English summary is being prepared. Showing the original description.
Architectural decision advisor for cloud, data, and SaaS distributed systems. Use when the user asks "should we use X or Y", weighs a tradeoff, or needs a decision matrix, scaling analysis, cost-at-scale review, data-tier design, multi-tenancy model, or API/resilience guidance. For full technical blueprints, use enterprise-design.
The English summary is being prepared. Showing the original description.