Menu
Use when creating or reviewing feature specifications. Defines the structure and quality standards for specs.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when decomposing an implementation plan into executable tasks with dependencies and sizing.
Use before marking any task complete. Runs the project's validation suite (lint, typecheck, tests) and confirms the implementation is in a working state. Use this whenever you have finished implementing a task and need to verify it before calling task_complete.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Use when reviewing architecture decisions, implementation plans, or PRs against layering, boundaries, and system design expectations.
Use when implementing code changes to ensure quality, consistency, and maintainability.
Use when bootstrapping a repository for Spec-Driven Development. Scan the codebase, ask 2 targeted questions, then write specs/constitution.md and the first epic's product-requirements.md.
| name | spec-generation |
| description | Use when creating or reviewing feature specifications. Defines the structure and quality standards for specs. |
Defines the structure and quality standards for feature specifications. A spec is the source of truth that drives planning, implementation, and review.
Use this skill when generating a new feature specification or reviewing an existing one for completeness.
A spec defines what to build and why — never how. It is the source of truth that drives planning, implementation, and review. A well-written spec should be:
When a requirement is not specified by the user, do not guess. Mark it:
[NEEDS CLARIFICATION: What authentication method should be used — email/password, SSO, or OAuth?]
Each user story or requirement must have acceptance criteria that can be verified:
Check specs/constitution.md for project principles that constrain the specification (e.g., supported platforms, security requirements, performance targets).
[NEEDS CLARIFICATION] markers remain unresolved (or are explicitly deferred)The spec should be created as specs/[feature-name]/spec.md following the template at specs/templates/spec.md. The spec must align with the template structure — all template sections must be present.