Menu
小〜中規模の機能実装向けの軽量な仕様駆動開発ワークフロー。 specファイルから即実装に入る簡易版。 トリガー: /sdd-lite, 軽いspec, 小さい機能の実装、またはsddから「この規模ならliteで十分」と案内された場合。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
| name | sdd-lite |
| description | 小〜中規模の機能実装向けの軽量な仕様駆動開発ワークフロー。 specファイルから即実装に入る簡易版。 トリガー: /sdd-lite, 軽いspec, 小さい機能の実装、またはsddから「この規模ならliteで十分」と案内された場合。 |
ドキュメントファーストの開発を通じて機能を実装するための構造化されたワークフロー。 小〜中規模のタスクに最適。1セッションで完結することを想定。
タスク用の仕様ディレクトリを作成します:
mkdir -p ./.specs/{task-name}
タスクに基づいて{task-name}を日本語で命名します（例: 記事コンポーネント作成, ユーザー認証追加）。
1. Context Analysis → 1-context.md
2. Prototyping (opt) → 2-prototyping-learnings.md
3. Requirements → 3-requirements.md
4. Design → 4-design.md
5. Implementation Plan → 5-implementation-plan-{N}.md
6. Implementation → (PR loop)
各フェーズ: ドキュメント作成 → ユーザーに提示 → 承認を得る → 次のフェーズへ
既存のコードベースを分析し、パターンと制約を理解します。
.specs/{task-name}/1-context.md を作成します。フォーマットは references/templates.md を参照してください。
内容:
ユーザーに提示し、次に進む前に承認を得てください。
要件定義の前に、使い捨てのプロトタイプを素早く構築してユーザー体験を理解します。
次に進む前に、プロトタイピングを行うかどうかユーザーに確認してください。
実行: /prototype を使用
学びを .specs/{task-name}/2-prototyping-learnings.md に記録します。
学びをユーザーに提示し、次に進む前に承認を得てください。
タスクが達成すべきことを定義します（方法ではなく何を）。
.specs/{task-name}/3-requirements.md を作成します。フォーマットは references/templates.md を参照してください。
プロトタイピングを実施した場合: 2-prototyping-learnings.md を参照して、発見された知見を取り入れます。
ガイドライン:
[NEEDS CLARIFICATION] マークを付ける（例: User can authenticate [NEEDS CLARIFICATION: OAuth? Password?]）すべての [NEEDS CLARIFICATION] マーカーは承認前に解決する必要があります。
ユーザーに提示し、次に進む前に承認を得てください。
アーキテクチャレベルでの実装方針を定義します。実装の詳細ではありません。
.specs/{task-name}/4-design.md を作成します。フォーマットは references/templates.md を参照してください。
内容:
validateInput: FormInput → ValidatedInput）フレームワークやインフラストラクチャに依存しないコアロジックを最初に書きます。コアはReact、CLI、サーバーなど、どこで使用されるかを知るべきではありません。
すべてのプロジェクトにはレイヤー階層があります（内側 = より純粋、外側 = より副作用的）。常にロジックをできるだけ内側に寄せます。
例（Reactプロジェクト）:
Core (pure functions) → State (jotai) → Hooks → Components
例（バックエンドプロジェクト）:
Domain Logic → Application Service → Controller → HTTP Handler
プロジェクトのレイヤーを特定し、各ロジックがどこに属するかを文書化します。メリット: テストが容易、再利用性が向上、境界が明確。
ユーザーに提示し、次に進む前に承認を得てください。
設計をTracer Bullets方式の垂直スライスで分割します。各スライスはすべてのレイヤーをエンドツーエンドで貫通する薄い単位です。
各スライスごとに .specs/{task-name}/5-implementation-plan-{N}.md を作成します。フォーマットは references/templates.md を参照してください。
すべての計画をユーザーに提示し、次に進む前に承認を得てください。
実装計画をPRごとに実行します。
各 5-implementation-plan-{N}.md に対して:
1. タスクを実行する（進行に応じてチェックボックスをチェック）
2. コミットメッセージを提案する（gitコマンドは実行しない）
3. 検証を実行: tsc, lint, test
4. 確認: 学びにより 3-requirements.md または 4-design.md の更新が必要か？
- はい → ドキュメントを更新し、残りの計画への影響を確認
- いいえ → 続行
5. ユーザーに提示して承認を得る
6. ユーザーOK → 次のPRへ
ユーザーNG → フィードバックに対応し、ステップ3から繰り返す
tsc/lint/test を実行する