design-doc について
システムの動作、実装方針、受け入れ基準を記述する技術設計書向けスキルです。参照テンプレートを使い、背景整理から起草、確認、レビューまでを導きます。
主な機能
- 01構造化された設計書作成手順
- 02テンプレートに沿った章立て
- 03テスト可能な受け入れ基準
- 04実装とテストの概要
- 05スコープと対象外の定義
活用シーン
- 01新機能の設計を文書化
- 02システム要件を実装概要に整理
- 03受け入れ基準の検証可能性を確認
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/design-docを入力して読み込まれたか確認します。
同梱ファイルreferences/template.mdREADME.md
詳細
テクニカルデザインドキュメントスキル
システムの動作、実装アプローチ、受け入れ基準を伝える構造化されたテクニカルデザインドキュメントを作成します。
ワークフロー
- コンテキストの収集: 機能・システムのスコープ、制約、目標を理解します
- 構造の下書き:
references/template.mdのテンプレートを使用します - セクションの記入: 各セクションを順に埋め、必要に応じて明確化のための質問をします
- レビュー: 受け入れ基準が検証可能で、実装概要が実行可能であることを確認します
テンプレート
テンプレートの完全な構造とセクションのガイドラインについては references/template.md を参照してください。
主要なセクション:
- コンテキストと動機: 問題の記述、目標、非目標
- 実装上の考慮事項: 制約と設計原則
- 高レベルの動作: エンドツーエンドのシステム動作
- ドメイン固有のセクション: 機能の種類（ディスカバリー、バリデーション、API、状態、レンダリング）に適応させます
- エラーハンドリングと UX: エラーの提示と復旧
- 将来への備え: 拡張性を考慮した設計
- 実装概要: ステップバイステップのアプローチ
- テストアプローチ: ユニットテスト、統合テスト、手動テスト
- 受け入れ基準: 「完了」のための検証可能な条件
執筆ガイドライン
- セクション見出しには
---による下線（Setext スタイル）を使用します - 動作は現在形で記述します（「読み込む」「検証する」「返す」）
- 具体的に書きます:「妥当な長さ」ではなく「最大 100 文字」
- 動作が変わる箇所には具体的な例を含めます
- 非目標は目標と同じくらい重要です - スコープの肥大化を防ぎます
- 受け入れ基準は主観的ではなく検証可能でなければなりません
コメント
Markdown 対応