メニュー
Create technology-free feature specification — WHAT and WHY, not HOW. Use when: writing a feature specification after the Explore phase, defining acceptance criteria and complexity scores, documenting goals and non-goals.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/willvelida/biotrackr --skill sdd-2-specifyコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | sdd-2-specify |
| description | Create technology-free feature specification — WHAT and WHY, not HOW. Use when: writing a feature specification after the Explore phase, defining acceptance criteria and complexity scores, documenting goals and non-goals. |
Focus on user value. Do NOT include stack, framework, or technology choices in the specification.
Before starting, resolve project conventions:
docs/project-rules/ (constitution.md, rules.md, idioms.md, architecture.md)copilot-instructions.md, AGENTS.md, CONTRIBUTING.md, README.md[TODO] markers — never assume silently.If a research dossier exists (at {dossier} or .copilot-tracking/plans/{date}/{slug}/research-dossier.md), read it and extract relevant findings. If no dossier is available, proceed with the information provided in the user's topic description.
Create {slug}-spec.md in .copilot-tracking/plans/{date}/{slug}/ with the following canonical sections in strict order:
One-paragraph description of the feature in terms of user value and business outcome.
Bulleted list of what this feature achieves. Each goal is outcome-oriented and measurable.
Explicitly scoped-out items. Prevents scope creep by naming what this feature does NOT do.
Numbered, testable scenarios that define "done." Each criterion follows the pattern: "Given [context], when [action], then [outcome]."
Assign CS-1 through CS-5 using the project's complexity rubric from doctrine. Apply the 6-factor scoring model (Surface Area, Integration, Data/State, Novelty, NFR, Testing) if the rubric is documented. If no rubric is found in doctrine, use this default mapping:
Known risks with likelihood and impact. Assumptions that underpin the specification. Mark uncertain items with [NEEDS CLARIFICATION].
Unresolved decisions or information gaps. Each question identifies who can answer it and the impact of leaving it unresolved.
List of modules, services, or components that this feature touches or depends on, based on research findings or codebase analysis.
Placeholder for Phase 3 (Clarify) to populate. The testing approach (Standard, Lightweight, or None) is decided during clarification.
[NEEDS CLARIFICATION: Testing approach not yet decided — run SDD Phase 3 (Clarify)]
Table of topics that would benefit from deeper design exploration before implementation:
| Topic | Type | Why It Matters | Priority |
|-------|------|----------------|----------|
Types include: Data Model, API Contract, State Machine, Integration Pattern, Storage Design, or other design-specific categories.
Scan the completed specification for [NEEDS CLARIFICATION] markers. If any exist, note them in the output summary. These do not block completion but signal that SDD Phase 3 (Clarify) should address them.