菜单
仕様駆動開発のナビゲーター。タスクの規模を判断し、小規模なら即座にsdd-liteルートへ、 大規模ならPRD→プロトタイピング→Issue分解→TDD→アーキテクチャ改善のフルパイプラインを案内する。 トリガー: /sdd, spec-driven, 仕様駆動, 機能を実装したい, 新しいプロダクトを作りたい。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | sdd |
| description | 仕様駆動開発のナビゲーター。タスクの規模を判断し、小規模なら即座にsdd-liteルートへ、 大規模ならPRD→プロトタイピング→Issue分解→TDD→アーキテクチャ改善のフルパイプラインを案内する。 トリガー: /sdd, spec-driven, 仕様駆動, 機能を実装したい, 新しいプロダクトを作りたい。 |
タスクの規模に応じて適切な開発ワークフローに案内するナビゲーター。
Phase 1: PRD作成 → /write-a-prd
Phase 2: プロトタイピング → /prototype
Phase 3: Issue分解 → /prd-to-issues
Phase 4: 実装(TDD) → /tdd
Phase 5: アーキテクチャ改善 → /improve-codebase-architecture
まず .specs/ ディレクトリを確認し、進行中のプロジェクトがあるか調べる。
.specs/{project}/progress.md が存在する → 途中から再開（ステップ3へ）ユーザーにタスクの概要を聞き、以下の基準で判断する：
sdd-liteルート（/sdd-lite を案内）:
フルルート（このスキルで続行）:
判断に迷う場合はユーザーに「フルプロセスで進めますか？それとも軽量版で十分ですか？」と確認する。
.specs/{project}/progress.md を確認し、次に実行すべきスキルを案内する。
progress.md が存在しない場合は新規作成し、Phase 1から開始する。
各フェーズの案内テンプレート：
現在のプロジェクト: {project-name}
完了済み: Phase 1 (PRD作成)
次のステップ: Phase 2 (プロトタイピング)
→ プロトタイピングを行いますか？
- はい → `/prototype` を実行してください。
- スキップ → Phase 3 (Issue分解) に進みます。`/prd-to-issues` を実行してください。
各フェーズ完了時に .specs/{project}/progress.md を更新する。
# {project-name} 進捗
## フェーズ状況
| Phase | 名前 | 状態 | 成果物 | 完了日 |
| ----- | ------------------ | ----------- | --------------------------- | ---------- |
| 1 | PRD作成 | done | 1-prd.md (GitHub Issue #42) | 2026-03-25 |
| 2 | プロトタイピング | skipped | - | - |
| 3 | Issue分解 | in_progress | - | - |
| 4 | 実装(TDD) | pending | - | - |
| 5 | アーキテクチャ改善 | pending | - | - |
## メモ
- Phase 2はスキップ。要件が明確なため。
状態の値: pending, in_progress, done, skipped
問題定義、解決策、ユーザーストーリー、技術的決定事項を文書化する。
実行: /write-a-prd を使用
完了条件: PRDがGitHub issueとして作成された
成果物: .specs/{project}/1-prd.md にPRDのローカルコピーを保存し、GitHub issue番号を記録
使い捨てのプロトタイプで体験を検証する。
スキップ条件: 要件が明確で、UIの「感触」の検証が不要な場合
実行: /prototype を使用
成果物: .specs/{project}/2-prototype-notes.md
PRDをトレーサーバレット方式の垂直スライスに分割し、GitHub issueとして作成する。
実行: /prd-to-issues を使用（Phase 1で作成したPRDのissue番号を渡す）
完了条件: すべてのissueがGitHub上に作成された
成果物: .specs/{project}/3-issues.md に作成されたissue一覧を記録
Phase 3で作成したissueをTDDで実装する。
実行: 各issueに対して /tdd を使用
完了条件: すべてのissueがクローズされた
実装後のコードベースを探索し、リファクタリングの機会を発見する。
スキップ条件: 小規模な変更で、アーキテクチャへの影響が軽微な場合
実行: /improve-codebase-architecture を使用
progress.md を更新するprogress.md を確認し、途中から再開できるようにするコード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。