spec-driven-development
GitHubのSpecKitを基盤に、AIが憲法から実装まで7段階で開発を支援し、多段階・多エージェントで統治された開発を可能にするSkill。
📜 元の英語説明(参考)
Spec-Driven Development (SDD) methodology based on GitHub's SpecKit. Use for structured AI-assisted development with constitutional governance, phased workflows, and multi-agent coordination. Implements 7-phase process from constitution to implementation.
🇯🇵 日本人クリエイター向け解説
GitHubのSpecKitを基盤に、AIが憲法から実装まで7段階で開発を支援し、多段階・多エージェントで統治された開発を可能にするSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[スキル名] spec-driven-development
Spec-Driven Development (SDD)
このスキルは、構造化されたAI支援ソフトウェア開発のためのGitHubのSpecKit手法を実装しています。SpecKitは、組み込みの品質ゲートとマルチエージェント連携を備えた体系的なフェーズベースのアプローチを通じて、仕様を実行可能な成果物に変換します。
コア哲学
「仕様は実行可能になり、単にガイドするだけでなく、動作する実装を直接生成します。」
このスキルを使用するタイミング
- 構造化された開発を必要とする新規プロジェクトを開始する際
- 複雑な機能で複数のAIエージェントまたは開発者を連携させる際
- 憲法によるガバナンスを通じて一貫した品質を確保する際
- 複雑な機能を管理可能な並行作業に分解する際
- 明確な仕様が作成される前の時期尚早な実装を防ぐ際
- 厳格なガバナンス要件を持つエンタープライズプロジェクト
- 複数の機能にわたるリアルタイムの可視性を必要とするチーム
7フェーズのワークフロー
フェーズ0: プロジェクト初期化
目的: プロジェクト構造を作成し、開発環境を構成する
成果物:
.specify/ディレクトリ構造- Gitリポジトリ
- 自動化スクリプト
- テンプレート
主なアクション:
- ディレクトリ構造を設定する
- バージョン管理を初期化する
- AIエージェントのプリファレンスを構成する
- スクリプトバリアント(bash/powershell)を生成する
フェーズ1: 憲法
目的: プロジェクトのガバナンスと開発原則を確立する
成果物: memory/constitution.md
コア原則:
- ライブラリファースト原則: すべての機能はスタンドアロンライブラリとして開始する
- CLIインターフェース義務: すべてのライブラリはテキストベースのインターフェースを持つ必要がある
- テストファーストの必須事項: テストは実装に先行する必要がある
- シンプルさと反抽象化: 複雑さを最小限に抑える
- 統合ファーストテスト: 現実的なテスト環境を優先する
バージョン管理: セマンティックバージョニング(MAJOR.MINOR.PATCH)
- MAJOR: 後方互換性のないガバナンス変更
- MINOR: 新しい原則または実質的な拡張
- PATCH: 軽微な明確化または改善
オーケストレーション: すべての成果物に対する検証を伴うインタラクティブな原則定義
フェーズ2: 仕様
目的: HOWではなくWHATとWHYに焦点を当てた詳細な機能仕様を作成する
成果物: specs/[feature]/spec.md
必須セクション:
- 機能ブランチ名(2〜4単語)
- ユーザーシナリオ(P1、P2、P3の優先順位付け)
- 受け入れシナリオ(Given/When/Then形式)
- エッジケース
- 機能要件(FR-XXX)
- 主要エンティティ
- 成功基準(測定可能、技術に依存しない)
主な制約:
- 実装ではなくビジネス価値に焦点を当てる
- 開発者ではなくステークホルダー向けに記述する
- 重要な不明点に対する明確化マーカーは最大3つ
- 各ユーザーストーリーは独立してテスト可能である必要がある
品質ゲート:
- コンテンツ品質検証
- 要件の完全性チェック
- 機能準備状況評価
- 成功基準の測定可能性
フェーズ3: 明確化
目的: 仕様の曖昧さを体系的に特定し、解決する
成果物: specs/[feature]/spec.mdを更新
明確化の側面:
- 機能スコープ
- データモデル
- ユーザーエクスペリエンス(UX)
- 非機能属性(パフォーマンス、セキュリティなど)
- 統合ポイント
主な制約:
- セッションあたりの質問は最大5つ
- 複数選択または短答形式
- 影響が大きく、実装に不可欠な不確実性に焦点を当てる
- 反復的な改善のために一度に1つの質問
オーケストレーション: 各回答後の仕様の増分更新を伴うインタラクティブな質問ワークフロー
フェーズ4: 計画
目的: 技術的な実装戦略を作成し、技術的な不明点を解決する
サブフェーズ:
フェーズ0 - 調査:
- 技術的な不明点を特定し、調査する
- 出力: すべての不確実性が解決された
research.md - ゲート: 未解決の明確化がある場合はERROR
フェーズ1 - 設計:
- データモデルとAPIコントラクトを作成する
- 出力:
data-model.md、コントラクトスキーマ、エージェント固有のコンテキスト
成果物:
specs/[feature]/plan.mdspecs/[feature]/research.mdspecs/[feature]/data-model.mdspecs/[feature]/contracts/
計画セクション:
- 機能概要
- 技術的コンテキスト(言語、依存関係、プラットフォーム)
- プロジェクト構造
- リポジトリレイアウト
- 非標準アプローチの複雑性追跡
フェーズ5: 分析
目的: 実装前に成果物間の整合性を検証する
分析される成果物:
specs/[feature]/spec.mdspecs/[feature]/plan.mdspecs/[feature]/tasks.md
検出パス:
- 重複
- 曖昧さ
- 仕様不足の項目
- 憲法との競合
出力: 重大度別にランク付けされた所見(高シグナルな問題は最大50件)を含む分析レポート
主な制約:
- 読み取り専用操作(ファイルを変更できない)
- タスク分解後に実行する必要がある
- 憲法の原則を優先する
フェーズ6: タスク分解
目的: 計画から実行可能で依存関係が順序付けられたタスクリストを生成する
成果物: specs/[feature]/tasks.md
タスク構造:
- 完了追跡用のチェックボックス
- 連続するタスクID
- オプションの並列化マーカー(
||) - ストーリーラベル(該当する場合はP1、P2、P3)
- 正確なファイルパス
- 明確な説明
フェーズ構造:
- フェーズ1: プロジェクトセットアップ
- フェーズ2: 基盤となる前提条件(BLOCKING - ユーザーストーリーの前に完了する必要がある)
- フェーズ3+: ユーザーストーリーの実装(優先順位: P1 → P2 → P3)
- 最終フェーズ: 磨き上げと横断的関心事
主な原則:
- タスクは独立した実装のためにユーザーストーリーごとにグループ化される
- 各ストーリーは独立してテスト可能で、提供可能である
- 明確な依存関係追跡
- 明示的な並列化マーカー
- 基盤フェーズが完了するまでユーザーストーリー作業は行わない
フェーズ7: 実装
目的: 組み込みの検証を伴い、フェーズごとに実装を実行する
8段階のプロセス:
- 前提条件チェック: プロジェクトの準備状況を検証する
- チェックリスト検証: 完了/未完了の項目を数え、未完了の場合は確認を要求する
- コンテキスト分析: 必要な成果物を読み込む
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Spec-Driven Development (SDD)
This skill implements GitHub's SpecKit methodology for structured, AI-assisted software development. SpecKit transforms specifications into executable artifacts through a systematic, phase-based approach with built-in quality gates and multi-agent coordination.
Core Philosophy
"Specifications become executable, directly generating working implementations rather than just guiding them."
When to Use This Skill
- Starting new projects that require structured development
- Coordinating multiple AI agents or developers on complex features
- Ensuring consistent quality through constitutional governance
- Breaking down complex features into manageable, parallel work
- Preventing premature implementation before clear specifications
- Enterprise projects with strict governance requirements
- Teams needing real-time visibility across multiple features
The 7-Phase Workflow
Phase 0: Project Initialization
Purpose: Create project structure and configure development environment
Artifacts:
.specify/directory structure- Git repository
- Automation scripts
- Templates
Key Actions:
- Set up directory structure
- Initialize version control
- Configure AI agent preferences
- Generate script variants (bash/powershell)
Phase 1: Constitution
Purpose: Establish project governance and development principles
Artifact: memory/constitution.md
Core Principles:
- Library-First Principle: Every feature starts as a standalone library
- CLI Interface Mandate: All libraries must have text-based interfaces
- Test-First Imperative: Tests must precede implementation
- Simplicity and Anti-Abstraction: Minimize complexity
- Integration-First Testing: Prioritize realistic testing environments
Versioning: Semantic versioning (MAJOR.MINOR.PATCH)
- MAJOR: Backward-incompatible governance changes
- MINOR: New principles or material expansions
- PATCH: Minor clarifications or refinements
Orchestration: Interactive principle definition with validation across all artifacts
Phase 2: Specification
Purpose: Create detailed feature specifications focused on WHAT and WHY, not HOW
Artifact: specs/[feature]/spec.md
Required Sections:
- Feature branch name (2-4 words)
- User scenarios (P1, P2, P3 prioritized)
- Acceptance scenarios (Given/When/Then format)
- Edge cases
- Functional requirements (FR-XXX)
- Key entities
- Success criteria (measurable, technology-agnostic)
Key Constraints:
- Focus on business value, not implementation
- Write for stakeholders, not developers
- Maximum 3 clarification markers for critical unknowns
- Each user story must be independently testable
Quality Gates:
- Content quality validation
- Requirement completeness check
- Feature readiness assessment
- Success criteria measurability
Phase 3: Clarification
Purpose: Systematically identify and resolve ambiguities in specifications
Artifact: Updates specs/[feature]/spec.md
Clarification Dimensions:
- Functional scope
- Data model
- User experience (UX)
- Non-functional attributes (performance, security, etc.)
- Integration points
Key Constraints:
- Maximum 5 questions per session
- Multiple-choice or short-answer format
- Focus on high-impact, implementation-critical uncertainties
- One question at a time for iterative refinement
Orchestration: Interactive questioning workflow with incremental spec updates after each answer
Phase 4: Planning
Purpose: Create technical implementation strategy and resolve technical unknowns
Sub-Phases:
Phase 0 - Research:
- Identify and research technical unknowns
- Output:
research.mdwith all uncertainties resolved - Gate: ERROR on unresolved clarifications
Phase 1 - Design:
- Create data models and API contracts
- Outputs:
data-model.md, contract schemas, agent-specific context
Artifacts:
specs/[feature]/plan.mdspecs/[feature]/research.mdspecs/[feature]/data-model.mdspecs/[feature]/contracts/
Plan Sections:
- Feature summary
- Technical context (language, dependencies, platform)
- Project structure
- Repository layout
- Complexity tracking for non-standard approaches
Phase 5: Analysis
Purpose: Validate cross-artifact consistency before implementation
Artifacts Analyzed:
specs/[feature]/spec.mdspecs/[feature]/plan.mdspecs/[feature]/tasks.md
Detection Passes:
- Duplications
- Ambiguities
- Underspecified items
- Constitution conflicts
Output: Analysis report with severity-ranked findings (max 50 high-signal issues)
Key Constraints:
- Read-only operation (cannot modify files)
- Must run after task breakdown
- Prioritizes constitution principles
Phase 6: Task Breakdown
Purpose: Generate actionable, dependency-ordered task list from plan
Artifact: specs/[feature]/tasks.md
Task Structure:
- Checkbox for completion tracking
- Sequential Task ID
- Optional parallelization marker (
||) - Story label (P1, P2, P3 when applicable)
- Precise file path
- Clear description
Phase Structure:
- Phase 1: Project Setup
- Phase 2: Foundational Prerequisites (BLOCKING - must complete before user stories)
- Phase 3+: User Story Implementation (priority order: P1 → P2 → P3)
- Final Phase: Polish & Cross-Cutting Concerns
Key Principles:
- Tasks grouped by user story for independent implementation
- Each story independently testable and deliverable
- Clear dependency tracking
- Explicit parallelization markers
- No user story work until foundational phase complete
Phase 7: Implementation
Purpose: Execute implementation phase-by-phase with built-in validation
8-Stage Process:
- Prerequisite Checking: Validate project readiness
- Checklist Validation: Count completed/incomplete items, require confirmation if incomplete
- Context Analysis: Read required artifacts (tasks.md, plan.md) and optional ones
- Project Setup: Create/verify ignore files for detected technologies
- Task Processing: Parse tasks, extract phases, dependencies, execution flow
- Phased Implementation: Execute tasks phase-by-phase following TDD
- Error Handling: Report progress, handle failures, provide debugging context
- Final Validation: Confirm completion, validate implementation, check test coverage
Orchestration: Systematic multi-stage execution with built-in checks and balances
Orchestration & Parallel Execution
Core Orchestration Philosophy
Sequential phase progression with parallel execution within phases where dependencies allow.
Coordination Mechanisms
1. Phase-Based Gates
- Each phase must complete and validate before next phase begins
- Gates block on errors or unresolved issues
- Implementation: Template validation, checklist requirements, constitution alignment checks
2. Dependency Tracking
- Tasks marked with dependencies that must be resolved before execution
- Foundational phase blocks all user story work
- Tasks reference prerequisites explicitly
3. Parallelization Markers
- Tasks explicitly marked for parallel execution when no dependencies exist
- Optional
||marker in task format - Indicates tasks can run concurrently
4. User Story Grouping
- Tasks grouped by user story for independent, parallel implementation
- Each user story is independently testable and deliverable
- Enables multiple agents/developers to work simultaneously
5. Constitutional Consistency
- All phases reference constitution to maintain consistent practices
- Constitution loaded and validated across all commands
- Ensures alignment across parallel work streams
Parallel Execution Patterns
Pattern 1: User Story Parallelization
After foundational phase completes, user stories (P1, P2, P3) can be implemented in parallel by different agents
Benefits:
- Independent testability
- Incremental delivery
- Reduced blocking
- Scalable team coordination
Example:
Foundation: ✓ Project setup, database schema, auth framework
Parallel Work:
├─ Agent 1: P1 Story - User registration flow
├─ Agent 2: P1 Story - User login flow
└─ Agent 3: P2 Story - Profile management
Pattern 2: Task-Level Parallelization
Within a phase, tasks without dependencies can execute concurrently
Example:
Phase 3: P1 User Registration
├─ [ ] T3.1 || Create user model (tests/models/test_user.py)
├─ [ ] T3.2 || Create registration endpoint (tests/api/test_register.py)
└─ [ ] T3.3 || Create validation service (tests/services/test_validation.py)
Pattern 3: Multi-Agent Coordination
Different AI agents can work on different aspects using shared artifact format
Example:
Feature "User Authentication":
├─ Claude: Generated spec.md and plan.md (reasoning strength)
├─ Copilot: Implemented auth endpoints (code generation)
└─ Gemini: Wrote integration tests (test coverage)
Synchronization Points
Critical points where parallel work must synchronize:
- After constitution: All subsequent work must align with principles
- After specification: Clarifications must be resolved before planning
- After planning research: All unknowns must be resolved before design
- After tasks: Analysis must validate before implementation
- After foundational tasks: User story work can begin
- Within implementation: Checklist validation blocks execution
Agent Coordination Patterns
Pattern 1: Template-Driven Handoffs
Structured markdown templates ensure consistent artifact format across different AI agents
Benefits: Agent interoperability, consistent documentation, reduced ambiguity
Pattern 2: Constitutional Alignment
Constitution acts as shared context across all agents and phases
Benefits: Consistent quality standards, predictable behavior, alignment across team/agents
Pattern 3: Phased Progression
Linear phase progression with clear handoff points between agents
Benefits: Clear responsibilities, reduced confusion, quality gates
Pattern 4: Incremental Refinement
Iterative improvement within phases before moving forward
Benefits: Higher quality artifacts, reduced rework, early error detection
Pattern 5: Artifact-Driven Context
Context passed through artifact references rather than conversation
Benefits: Stateless execution, context recovery, long-running projects
Directory Structure
.specify/
├── memory/
│ └── constitution.md # Project governance and principles
├── scripts/
│ ├── *.sh # Bash automation scripts
│ └── *.ps1 # PowerShell automation scripts
├── specs/
│ └── [feature-name]/
│ ├── spec.md # Feature specification
│ ├── plan.md # Technical implementation plan
│ ├── tasks.md # Actionable task breakdown
│ ├── research.md # Research findings (optional)
│ ├── data-model.md # Data structure design (optional)
│ ├── quickstart.md # Getting started (optional)
│ └── contracts/ # API/interface definitions (optional)
└── templates/ # Command and artifact templates
Best Practices
- Establish constitution early to guide all subsequent decisions
- Use clarify command to resolve ambiguities before planning
- Run analyze command before implementation to catch issues early
- Structure user stories for independent testability
- Mark parallelizable tasks explicitly with
|| - Complete foundational phase fully before user story work
- Maintain constitution alignment throughout all phases
- Use specific, measurable success criteria in specifications
- Avoid implementation details in specification phase
- Leverage multiple AI agents for different strengths
Pitfalls to Avoid
- Skipping clarification phase leads to ambiguous specifications
- Premature implementation details in specs reduce flexibility
- Ignoring constitution causes inconsistent practices
- Parallel work without proper dependency tracking causes conflicts
- Incomplete foundational phase blocks all user story work
- Not running analyze before implementation wastes effort on flawed plans
- Over-specification in early phases limits AI agent creativity
- Insufficient success criteria make validation subjective
- Not using user story grouping limits parallelization potential
Implementation Scenarios
Scenario 1: Starting a New Project
Use full 7-phase workflow with constitutional governance. Focus on establishing principles early.
Scenario 2: Team with Multiple Developers/Agents
Emphasize user story parallelization and worktree isolation. Use dashboard for real-time visibility.
Scenario 3: Enterprise with Governance Requirements
Comprehensive constitution with enterprise constraints. Mandate analysis phase before implementation.
Scenario 4: Rapid Prototyping
Detailed specifications to align on vision, but lighter planning. Small user stories for quick validation.
References
Based on GitHub SpecKit (spec-kit) methodology - an open-source toolkit for Spec-Driven Development supporting 15+ AI coding agents including Claude Code, GitHub Copilot, Gemini, and Cursor.