【非推奨】設計書を永続化しない運用へ移行したため非推奨。設計は実装時にPR本文とGitHubコメントへ記載し、要求の管理は requirement-management を使用すること。既存の docs/sdd/design/ を保守・参照する場合にのみ使用する。
アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマのMarkdown文書を作成・編集する。Do NOT use for 新規プロジェクトの設計（設計はPR本文に記載すること）。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
⚠️ このスキルは非推奨です。
設計書を永続化しない運用へ移行しました。設計書は書いた瞬間から実装とずれ始め、ずれた設計書は整合性チェックの対象を増やすだけになるためです。
非推奨（本スキル） 移行先 設計の記録先 docs/sdd/design/（永続化）PR本文とGitHubコメント（永続化しない） 要求との紐付け ドキュメント間の相互リンク 要求の verificationとPRのURL（design_refs）要求の管理 requirements-defining requirement-management運用の詳細は
sdd/requirement-management/references/design_in_pr_ja.md、移行手順は同references/migration_from_sdd_ja.mdを参照してください。 既存のdocs/sdd/design/を保守・参照する場合にのみ、以下の手順を使用します。
技術アーキテクチャ、コンポーネント設計、API設計、データベーススキーマを文書化する設計書を作成します。
このスキルは、以下の成果物を作成・管理します：
docs/sdd/design/
├── index.md # 目次・アーキテクチャ概要
├── components/
│ ├── component-a.md # コンポーネント詳細
│ └── component-b.md
├── api/
│ ├── users.md # API設計詳細
│ └── items.md
├── database/
│ └── schema.md # データベーススキーマ
└── decisions/
├── DEC-001.md # 技術的決定事項
└── DEC-002.md
docs/sdd/requirements/が存在する場合：
docs/sdd/design/ 以下のサブディレクトリを作成docs/sdd/requirements/が存在する場合、以下を確認：
| チェック項目 | 確認内容 |
|---|---|
| 機能カバレッジ | すべての要件（REQ-XXX）に対応する設計要素があるか |
| 非機能要件対応 | NFR-XXXの要件が設計に反映されているか |
| 過剰設計チェック | requirements/にない機能が設計に含まれていないか |
技術スタックについて確認させてください：
A) Next.js + TypeScript
推奨理由：モダンで型安全、SSR/SSG対応
B) React + JavaScript
推奨理由：シンプルで導入が容易
どれを選択しますか？
docs/sdd/design/の作成完了後：
task-planningスキルで逆順レビュー（タスク → 要求）が行われます。設計は逆順レビューの対象外です（PR本文の設計ノートと実装を突き合わせます）。
assets/templates/design_index_template_ja.mdassets/templates/component_template_ja.mdassets/templates/api_template_ja.mdassets/templates/database_template_ja.mdassets/templates/decision_template_ja.mdreferences/design_patterns_ja.mdreferences/cicd_guide_ja.mdreferences/ears_notation_ja.md| ファイル種別 | 命名規則 | 例 |
|---|---|---|
| コンポーネント | ケバブケース | user-service.md, auth-handler.md |
| API | リソース名 | users.md, items.md |
| 技術的決定 | DEC-XXX.md | DEC-001.md, DEC-002.md |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
指定されたPRを6観点（セキュリティ、ドキュメント乖離、可読性、ライブラリ選定、PR説明、既知脆弱性）でレビューし、人間向け・AI向けの2形式でPRにコメントする。初回レビューおよび修正後の再レビューに使用する。Do NOT use for レビューコメントへの修正適用（pr-comment-fixerを使用すること）。
The English summary is being prepared. Showing the original description.
キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。
The English summary is being prepared. Showing the original description.
サービス開発のためのデプスインタビューを実施し、ユーザーの真のニーズ・課題・動機を引き出す。5 Whys、ラダリング法を用いてプロダクト開発に活かせるインサイトを発見する。ユーザーリサーチ、課題発見、ペルソナ構築、プロダクト仮説検証に使用する。Do NOT use for キャリア相談やキャリアカウンセリング（depth-interviewing-careerを使用すること）。
The English summary is being prepared. Showing the original description.
インフラメトリクスの定期調査を体系的に実施し、サービスの健全性を評価する。2層アプローチで11カテゴリのメトリクスを確認し、構造化レポートを作成する。定期的なサービス監視、障害予兆の検出、パフォーマンス評価に使用する。Do NOT use for 個別インシデントの根本原因分析（incident-rcaを使用すること）。
The English summary is being prepared. Showing the original description.
インシデント調査で根本原因を特定するためのなぜなぜ分析ファシリテーター。推測を避け、ユーザーの発言を記録し、マインドツリーで全体を可視化する。障害発生後の原因究明、ポストモーテム、再発防止策の策定に使用する。Do NOT use for 定期的なサービス健全性チェック（health-checkを使用すること）。
The English summary is being prepared. Showing the original description.
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirement-managementを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
The English summary is being prepared. Showing the original description.