一键导入
software-designing
技術設計書を作成・編集する。アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマの文書化が必要な場合に使用する。設計フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理(sdd-documentationを使用すること)。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
技術設計書を作成・編集する。アーキテクチャ設計、コンポーネント定義、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 |