القائمة
技術設計書を作成・編集する。アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマの文書化が必要な場合に使用する。設計フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Jules REST APIを使用してタスクを対話的に依頼・管理する。セッション作成・プラン承認・メッセージ送信・進捗監視をAPI経由で行い、Claudeと協調してタスクを完遂する。ベースブランチ指定とPR自動作成に対応。認証はJULES_API_KEY_OP_URI（1Passwordシークレット参照）またはJULES_API_KEYで行う。Do NOT use for 認証情報未設定の環境でのタスク実行（task-executingを使用すること）。
SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。
設計書から実装タスクへの分解を行う。デフォルトで各タスクをGitHub Issueとして起票し（1タスク＝1 Issue、詳細はIssue本文に集約、ラベルでフェーズ・ステータス管理）、ユーザーがファイル管理を明示した場合のみdocs/sdd/tasks/にファイル生成する。AIエージェント向けの具体的な実装指示やTDD手順を定義する。タスク計画フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。
SDDドキュメントの整合性チェック、実装同期確認、アーカイブ（CLAUDE.md同期含む）、ファイル最適化を行う。ドキュメント間の矛盾検出、実装との乖離確認、完了タスクの整理と仕様のCLAUDE.md転記、肥大化ファイルの分割が必要な場合に使用する。Do NOT use for ドキュメントの新規作成（requirements-defining、software-designing、task-planningを使用すること）。
エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。
IPA非機能要求グレード2018（可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境）の記入済み要件を入力として、運用設計書を生成する。非機能要件定義が完了しているプロジェクトの運用設計フェーズで使用する。Do NOT use for 非機能要件の定義自体（requirements-definingを使用すること）。Do NOT use for 業界調査やヒアリングから始める運用設計（operations-designを使用すること）。
استنادا إلى تصنيف SOC المهني
| name | software-designing |
| description | 技術設計書を作成・編集する。アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマの文書化が必要な場合に使用する。設計フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。 |
| metadata | {"version":"1.0.0"} |
技術アーキテクチャ、コンポーネント設計、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スキルで逆順レビュー（タスク → 設計 → 要件）が行われます。
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 |