메뉴
Spec before plan for non-trivial work. Invoke when the user asks for a feature, refactor, workflow change, API change, or any multi-step task where the why, scope, or acceptance criteria could drift. Do not let implementation become the de facto spec.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Repository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
End-to-end release workflow for repositories using Conventional Commits. Use when preparing a new version, tagging a release, generating changelog/release notes, bumping version, or when the user asks "release", "new version", "bump version", "publish release", "chuẩn bị release", or "tạo tag release".
Repository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
Repository-as-system-of-record protocol for multi-step or decision-heavy work. Invoke when a task spans >=3 tracked tasks, changes architecture/module boundaries, introduces or reverses important technical decisions, affects release/governance docs, audits AGENTS.md/CLAUDE.md, sets up docs/, or asks where durable project context should live. Do not invoke for small single-task edits unless the user asks for doc hygiene.
Guide for using Brave Search MCP tools (`brave_web_search`, `brave_news_search`, `brave_image_search`, `brave_video_search`, `brave_local_search`, `brave_summarizer`). Invoke when the user asks to search the web, news, images, videos, or local results AND Brave Search MCP is available. Do NOT trigger for generic lookups when other search tools (Tavily, built-in WebSearch) are more appropriate. Requires `BRAVE_API_KEY`.
Terminal-driven browser automation via the Playwright CLI — invoke when the agent needs to open a page, interact with a form, click through a flow, or verify UI state. Use this (not the test framework, not screenshot-only scraping) for live browser work. Triggers on "open the browser", "click through", "fill the form", "reproduce the UI bug", "check what the page shows".
| name | spec-driven |
| description | Spec before plan for non-trivial work. Invoke when the user asks for a feature, refactor, workflow change, API change, or any multi-step task where the why, scope, or acceptance criteria could drift. Do not let implementation become the de facto spec. |
A plan tells you how to build. A spec tells you what you are building, why it exists, and what is out of scope. If the change is non-trivial and no spec exists, the agent is guessing.
Use this skill to make the spec the source of truth before planning and implementation.
Write or update a spec when any of these are true:
Skip the full spec only for mechanical, single-commit changes with obvious scope. If you skip it, say so explicitly.
Choose the smallest document that can hold the decision:
docs/product-specs/<feature>.md for user-facing scope, goals, non-goals, and success criteriadocs/design-docs/<topic>.md for technical shape, invariants, and rejected alternativesRule of thumb:
If the repo has no docs/ structure yet, create the minimum path you need rather than keeping the spec in chat.
The spec must answer the questions implementation will otherwise answer by accident.
Keep it lean. A good spec is decisive, not long.
A spec is usable only if an agent can turn it into a plan without guessing.
Check for:
Bad spec signals:
If a reviewer could interpret the spec in two materially different ways, it is not ready.
Do not write the execution plan first.
Sequence:
The plan should cite the spec path directly. The plan is allowed to decompose work; it is not allowed to redefine product scope or architecture silently.
If implementation reveals that the chosen shape is wrong:
Do not let code diverge and promise to "clean up docs later". That turns the spec into fiction.
planning-first - that bundle governs exploration, questions, options, and approval flowdocs-as-code - that bundle defines the broader documentation system and doc taxonomyquality-gates - a spec can be correct and the implementation can still be brokenThis bundle exists to prevent one specific failure mode: implementation becoming the first precise statement of scope.