mcpField
S
sdd

sdd

github.com/meleantonio開発65955 回インストール9 週間前に更新
リポジトリ

sdd について

実装前に要件と設計の承認を得たいチーム向けの、仕様駆動開発スキルです。Markdown ファイルで作業を管理し、初期化、要件、設計、タスク、状態確認のコマンドを提供します。

主な機能

  1. 01spec と steering のファイル構成を作成
  2. 02意図から EARS 要件を生成
  3. 03設計と順序付きタスクを作成
  4. 04各段階で承認を依頼
  5. 05仕様の進捗を報告

活用シーン

  1. 01プロジェクトに仕様ワークフローを導入
  2. 02製品の意図を検証可能な要件に変換
  3. 03追跡可能な実装タスクを計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/meleantonio/awesome-econ-ai-stuff --skill sdd

インストール後、Claude Code で/sddを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

index.md
reference.md
templates/spec/
design.md
requirements.md
tasks.md
templates/steering/
coding-standards.md

詳細

仕様駆動開発（SDD）

基本理念

  1. コードより明確さを優先： 要件と設計が承認されるまで、コードを生成してはいけません。
  2. 反復的な改善： 要件 → 設計 → タスクの流れを、十分に固まるまで繰り返します。
  3. ドキュメントを通じたコーディング： 正しい情報はチャットではなく、Markdown ファイルにあります。

コマンド

プロジェクトのルート（spec/ と steering/ がある場所）で実行します。

init

SDD のフォルダー構造とテンプレートファイルを作成します。

  1. spec/ がすでに存在する場合は、上書きをスキップするか、確認します。
  2. spec/ と steering/ を作成します。
  3. spec/intent.md を作成します（空、または最小限のプレースホルダーを記載します）。
  4. このスキルの templates/ ディレクトリ（SKILL.md と同じフォルダー内、またはスキルをコピーした後のインストール先 ~/.cursor/skills/sdd/ 内）から、プロジェクトにテンプレートをコピーします。
    • templates/spec/requirements.md → spec/requirements.md
    • templates/spec/design.md → spec/design.md
    • templates/spec/tasks.md → spec/tasks.md
    • templates/steering/coding-standards.md → steering/coding-standards.md
reqs

意図から EARS 要件を生成します。

  1. spec/intent.md と steering/*.md を読み込みます。
  2. 意図を EARS 要件に変換します（以下の「EARS クイックリファレンス」を参照）。プロパティ（不変条件）セクションを追加します。
  3. spec/requirements.md に書き込みます。
  4. 次に進む前に、ユーザーの承認を求めます。
design

要件から技術設計を生成します。

  1. spec/requirements.md と steering/*.md を読み込みます。
  2. アーキテクチャ、データモデル、コンポーネントインターフェース、エラー処理、セキュリティを含む技術設計を作成します。以下の「設計チェックリスト」を適用します。
  3. spec/design.md に書き込みます。
  4. 次に進む前に、ユーザーの承認を求めます。
tasks

設計から実装タスクを生成します。

  1. spec/design.md と spec/requirements.md を読み込みます。
  2. 順序付きのタスクリストを作成します。階層は最大 2 段階（タスク > サブタスク）です。各タスクを要件 ID（例：REQ-001）に紐付けます。以下の「タスクのルール」に従います。
  3. spec/tasks.md に書き込みます。
  4. 次に進む前に、ユーザーの承認を求めます。
status

仕様の現在の状態を報告します。

  1. spec/（必要に応じて steering/ も）のファイルを一覧表示します。
  2. spec/tasks.md が存在する場合、未完了の [ ] と完了済みの [x] の数を数え、概要をまとめます。

EARS クイックリファレンス

  • 全般： <system> shall <response>
  • イベント駆動： WHEN <trigger> [precondition] the <system> shall <response>
  • 望ましくない条件： IF <unwanted condition> THEN the <system> shall <response>
  • 状態駆動： WHILE <system state>, the <system> shall <response>
  • オプション： WHERE <feature is included>, the <system> shall <response>

[REQ-001] のような ID を使用し、普遍的な正確性に関する記述を記載する「プロパティ（不変条件）」セクションを追加します。

設計チェックリスト

  • 過剰な設計を取り除き、徹底的に編集します。
  • 循環依存がないか確認し、インターフェースの抽出、レイヤー化、またはイベントによって解消します。
  • ステアリング文書との整合性を確保します。

タスクのルール

  • 階層は最大 2 段階（タスク > サブタスク）です。
  • 順序に従います（各タスクは前のタスクを踏まえて進めます）。
  • トレーサビリティ：各タスクまたはサブタスクを要件 ID に紐付けます（例：トレーサビリティ： REQ-001 を実装）。

その他のリソース

  • フレームワークの詳細（ワークフロー、改善、反復を開始する条件）については、reference.md を参照してください。

コメント

Markdown 対応