Agent skill

software-designing

技術設計書を作成・編集する。アーキテクチャ設計、コンポーネント定義、API設計、データベーススキーマの文書化が必要な場合に使用する。設計フェーズのみを単独で実行する際に使用する。Do NOT use for SDDワークフロー全体の管理（sdd-documentationを使用すること）。

View SKILL.md on GitHub Repository
Stars 4
Forks 2

Install this agent skill to your Project

npx add-skill https://github.com/windschord/claude_skils/tree/main/software-designing

Metadata

Additional technical details for this skill

version
1.0.0

SKILL.md

設計スキル

技術アーキテクチャ、コンポーネント設計、API設計、データベーススキーマを文書化する設計書を作成します。

概要

このスキルは、以下の成果物を作成・管理します：

  • docs/sdd/design/index.md: 設計概要（目次）
  • docs/sdd/design/components/*.md: コンポーネント詳細
  • docs/sdd/design/api/*.md: API設計詳細
  • docs/sdd/design/database/schema.md: データベーススキーマ
  • docs/sdd/design/decisions/DEC-XXX.md: 技術的決定事項

ドキュメント構成

text
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

このスキルを使用する場面

新規作成時

  • 技術アーキテクチャを文書化したい場合
  • コンポーネント設計を明確にしたい場合
  • API設計を定義したい場合
  • データベーススキーマを設計したい場合

既存ドキュメントの修正時

  • docs/sdd/design/の設計内容を更新・変更する場合
  • 新しいコンポーネントを追加する場合

前提条件

requirements/との連携

docs/sdd/requirements/が存在する場合：

  1. 要件を読み込み、設計との整合性を確認
  2. すべての要件（REQ-XXX）に対応する設計要素があるか確認
  3. 要件にない機能が設計に含まれていないか確認

設計原則

コンポーネント設計

  1. 単一責任の原則: 各コンポーネントは1つの明確な目的を持つ
  2. 疎結合: コンポーネント間の依存関係を最小限に
  3. 高凝集: 関連する機能を同じコンポーネントに
  4. インターフェース定義: 明確な入出力を定義

API設計

  • RESTful原則に従う
  • 適切なHTTPステータスコードを使用
  • バージョニング戦略を定義
  • エラーレスポンスの一貫性

データベース設計

  • 正規化と非正規化のバランス
  • インデックス戦略
  • トランザクション境界

実行効率に関する注意

  • テンプレートは使用直前に読み込む: 5つのテンプレートを一括読み込みしない。各ドキュメント作成時に対応するテンプレートのみ読み込む
  • リファレンスは必要時のみ参照: 設計パターンやCI/CDガイドは判断に迷う場合のみ読み込む
  • 作業完了後は速やかに結果を報告: 長時間無応答にならないよう、作成したドキュメントの概要をユーザーに提示する
  • 進捗をステップごとに出力する: 各処理ステップの開始時に進捗メッセージを出力する

進捗出力の例

text
[software-designing] ステップ 1/5: 要件定義を確認中...
[software-designing] ステップ 2/5: 情報を分類中（明示/不明）...
[software-designing] ステップ 3/5: アーキテクチャ概要を作成中...
[software-designing] ステップ 4/5: コンポーネント設計を作成中...
[software-designing] ステップ 5/5: index.mdを作成中...
[software-designing] 完了: Nファイル作成

ワークフロー

  1. 要件確認: docs/sdd/requirements/が存在すれば内容を確認
  2. 情報分類: 明示された情報と不明な情報を分類
  3. 不明点確認: 必要な情報をユーザーに確認
  4. ディレクトリ作成: docs/sdd/design/ 以下のサブディレクトリを作成
  5. 各ドキュメント作成: テンプレートを使用
  6. 整合性確認: requirements/との整合性をチェック
  7. ユーザー確認: 承認を得て完了

検証チェックリスト

  • アーキテクチャ概要が記載されている
  • 主要コンポーネントが定義されている
  • 技術的決定事項と根拠が記載されている
  • 情報の明確性チェックが完了している
  • requirements/の全要件に対応する設計要素がある
  • CI/CD設計が含まれている
  • 品質基準が定義されている（カバレッジ80%、ミューテーションスコア85%、Linter、複雑性）

要件との整合性チェック

docs/sdd/requirements/が存在する場合、以下を確認：

チェック項目 確認内容
機能カバレッジ すべての要件（REQ-XXX）に対応する設計要素があるか
非機能要件対応 NFR-XXXの要件が設計に反映されているか
過剰設計チェック requirements/にない機能が設計に含まれていないか

ユーザーとの対話ガイドライン

確認が必要な場面

  • アーキテクチャパターンの選択
  • 技術スタックの選定
  • データモデルの構造
  • 外部サービスとの連携方法

推奨度付き選択肢の提示

text
技術スタックについて確認させてください：

A) Next.js + TypeScript
   推奨理由：モダンで型安全、SSR/SSG対応

B) React + JavaScript
   推奨理由：シンプルで導入が容易

どれを選択しますか？

後続スキルとの連携

docs/sdd/design/の作成完了後：

  • task-planning: design/を基にタスクを分解

task-planningスキルで逆順レビュー（タスク → 設計 → 要件）が行われます。

リソース

テンプレート

  • 目次テンプレート: assets/templates/design_index_template_ja.md
  • コンポーネントテンプレート: assets/templates/component_template_ja.md
  • APIテンプレート: assets/templates/api_template_ja.md
  • データベーステンプレート: assets/templates/database_template_ja.md
  • 技術的決定テンプレート: assets/templates/decision_template_ja.md

リファレンス

  • 設計パターン: references/design_patterns_ja.md
  • CI/CDガイド: references/cicd_guide_ja.md
  • EARS記法（要件参照用）: references/ears_notation_ja.md

命名規則

ファイル種別 命名規則 例
コンポーネント ケバブケース user-service.md, auth-handler.md
API リソース名 users.md, items.md
技術的決定 DEC-XXX.md DEC-001.md, DEC-002.md

リンク形式

index.mdから個別ファイルへのリンクは、マークダウン形式と@形式の両方を記載：

markdown
| ComponentA | 目的 | [詳細](components/component-a.md) @components/component-a.md |
  • マークダウン形式: [詳細](components/component-a.md) - GitHub等での閲覧用
  • @形式: @components/component-a.md - Claude Codeがファイルを参照する際に使用

Recommended Agent Skills

Expand your agent's capabilities with these related and highly-rated skills.

windschord/claude_skils

orchestrating-agents

Orchestrates multi-step tasks autonomously using a 3-tier agent hierarchy (Director/Manager/Worker). Use when user says "run this end-to-end", "handle everything", "execute all tasks", or needs parallel task execution with queuing, course correction, and session resume. Provides FIFO task queue, escalation policy, git worktree isolation, and context persistence across agent sessions.

4 2
Explore
windschord/claude_skils

sdd-documentation

SDDワークフロー全体を統括するオーケストレーター。要件定義・設計・タスク計画・実装・逆順レビューの一連のフローを管理する。新規プロジェクトのSDD一括作成、複数フェーズにまたがるワークフロー管理、エラー・バグの体系的な分析と修正に使用する。Do NOT use for 個別フェーズのみの作業（requirements-defining、software-designing、task-planningを直接使用すること）。

4 2
Explore
windschord/claude_skils

sdd-troubleshooting

エラー・バグ・問題を体系的に分析し修正方針を策定する。テスト失敗、ビルドエラー、実行時エラー、動作不良、バグ報告に対応し、根本原因を分析してから修正を行う。Do NOT use for 根本原因分析が不要な軽微な修正（typo、設定値変更、フォーマット修正など）。

4 2
Explore
windschord/claude_skils

self-review

ローカルの変更差分（git diff）を3つのサブエージェントで並列レビューし、結果を統合して修正を適用する。PR作成前やタスク完了前のローカル品質チェックに使用する。ai-code-reviewと同一の6観点・重大度基準を適用する。

4 2
Explore
windschord/claude_skils

depth-interviewing-career

キャリア設計のためのデプスインタビューを実施し、本人の価値観・強み・動機を引き出す。5 Whys、ラダリング法を用いてキャリアビジョンの明確化を支援する。転職相談、自己理解、キャリアカウンセリング、1on1面談の深掘りに使用する。Do NOT use for 製品・サービスのユーザーリサーチ（depth-interviewing-productを使用すること）。

4 2
Explore
windschord/claude_skils

saas-spec-document

SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。

4 2
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results