9.4 KiB
argument-hint, description, allowed-tools
| argument-hint | description | allowed-tools | ||||
|---|---|---|---|---|---|---|
| <タスク名> | 技術詳細とアーキテクチャ設計を作成 |
|
技術詳細ドキュメントを作成します
タスクの技術仕様とアーキテクチャ設計を詳細化し、technical-details.md を生成します。
【対象タスク名】 $ARGUMENTS
実行手順
0. ステアリングドキュメントの読み込み
以下のステアリングドキュメントを読み込み、プロジェクトの技術標準を把握：
specs/_steering/tech.md- 最重要: 技術スタック、アーキテクチャパターン、開発標準specs/_steering/structure.md- プロジェクト構造、命名規則specs/_steering/product.md- プロダクト方針
ステアリングドキュメントが存在しない場合:
- 警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。先に
/sdd:steeringを実行することを推奨します。」
重要: tech.mdに記載されている技術スタックとアーキテクチャパターンを必ず尊重してください。
1. タスクディレクトリの確認
タスク名が指定されている場合:
specs/[taskname]/ディレクトリの存在を確認specs/[taskname]/overview.mdおよびspecs/[taskname]/specification.mdが存在するか確認
タスク名が指定されていない場合:
specs/ディレクトリ内の利用可能なタスクをリスト表示- AskUserQuestionツールを使用してどのタスクについて作業するかユーザーに選択を求める
2. 既存ドキュメントの読み込み
以下のドキュメントを読み込み、技術詳細化に必要な情報を抽出：
specs/[taskname]/overview.md- プロジェクト概要、主要機能specs/[taskname]/specification.md- 機能要件、データ要件、インターフェース要件specs/_steering/tech.md- 既存の技術スタック、アーキテクチャパターンspecs/_steering/structure.md- コード構造、命名規則
3. technical-details.mdの生成
specs/[taskname]/technical-details.md を生成：
# 技術詳細ドキュメント
## アーキテクチャ
### システム構成図
[Mermaid記法でシステム構成を図示]
```mermaid
graph TB
Client[クライアント]
API[APIサーバー]
DB[データベース]
Client --> API
API --> DB
技術スタック
重要: 以下は specs/_steering/tech.md に準拠しています。
言語・ランタイム
- 言語: [steering/tech.mdから取得]
- ランタイム: [steering/tech.mdから取得]
- フレームワーク: [steering/tech.mdから取得]
主要ライブラリ
[steering/tech.mdのKey Dependencies/Librariesを参照]
このタスク固有の追加ライブラリ:
- [タスク固有のライブラリ]
インフラ構成
[デプロイ環境、インフラ構成]
技術選定（タスク固有の技術のみ）
注意: steering/tech.md で既に定義されている技術については記載不要です。このタスク固有の技術選定のみ記載してください。
[技術名]（必要な場合のみ）
- 採用理由: [1-2行で簡潔に]
- steering/tech.mdとの関係: [準拠/逸脱の明記]
技術選定が不要な場合: 「steering/tech.mdの標準技術を使用」と記載
データ設計
データモデル
[specification.mdのデータ要件を具体的なスキーマに変換]
エンティティ図
erDiagram
User ||--o{ Post : creates
User {
int id PK
string email
string name
}
Post {
int id PK
int user_id FK
string title
text content
}
データベーススキーマ
重要: steering/tech.md で定義されているデータベース技術を使用
[テーブル1]
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
name VARCHAR(100) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
データフロー
[データの流れを図示]
API設計
エンドポイント一覧
命名規約: steering/structure.md の規約に準拠
| メソッド | パス | 説明 | 入力 | 出力 |
|---|---|---|---|---|
| GET | /api/users | ユーザー一覧取得 | クエリパラメータ | User[] |
| POST | /api/users | ユーザー作成 | UserInput | User |
| GET | /api/users/:id | ユーザー詳細取得 | id | User |
| PUT | /api/users/:id | ユーザー更新 | id, UserInput | User |
| DELETE | /api/users/:id | ユーザー削除 | id | 成功/失敗 |
リクエスト/レスポンス仕様（必要な場合のみ）
複雑なAPI仕様がある場合のみ詳細を記載。標準的なCRUD操作の場合は省略可。
[エンドポイント名]（必要な場合のみ）
- 入力: [JSON例]
- 出力: [JSON例]
- エラー: [エラーコード一覧]
認証・認可
重要: steering/tech.md のセキュリティ要件に準拠
- 認証方式: [JWT/Session/OAuth2 - steering/tech.mdから]
- 認可方式: [RBAC/ABAC]
- トークン管理: [保存場所、有効期限]
セキュリティ
重要: specification.md および steering/tech.md のセキュリティ要件に準拠
セキュリティ要件
[specification.mdから取得]
実装方針
- 認証: [実装方法]
- 認可: [実装方法]
- データ暗号化: [実装方法]
- 監査ログ: [実装方法]
パフォーマンス要件（ユーザー指定時のみ）
[specification.mdで指定された場合のみ含める]
- レスポンスタイム: [目標値と測定方法]
- スループット: [目標値と測定方法]
- 最適化方針: [具体的な最適化手法]
開発環境（ユーザー指定時のみ）
重要: steering/tech.md の開発環境に準拠
必要なツール
[steering/tech.md の Required Tools を参照]
このタスク固有の追加ツール:
- [タスク固有のツール]
セットアップ手順
# 1. 依存関係のインストール
[コマンド]
# 2. 環境変数の設定
[コマンド]
# 3. データベースのセットアップ
[コマンド]
# 4. 開発サーバーの起動
[コマンド]
テスト戦略（ユーザー指定時のみ）
重要: steering/tech.md のテスト標準に準拠
テストの種類
- 単体テスト: [フレームワーク、カバレッジ目標]
- 統合テスト: [範囲、実行タイミング]
- E2Eテスト: [ツール、シナリオ]
カバレッジ目標
[steering/tech.md から取得、またはタスク固有の目標]
**生成時の注意点**:
- **⚠️ 最重要**: steering/tech.md に記載されている技術スタックを**必ず使用**すること
- **⚠️ 重要**: steering/tech.md から逸脱する場合は、明確な理由を記述すること
- **⚠️ 重要**: steering/structure.md の命名規約、コード構造に準拠すること
- **⚠️ 重要**: 詳細であれば詳細であるほど良いわけではない。必要な部分だけを必要なだけ書くこと
- 不明なところは勝手に決めずに「**不明**」と明記し、複数の案（案A、案B、案Cなど）を記述すること
- specification.mdは機能要件の詳細を、technical-details.mdは技術実装の詳細を記述し、役割を明確に分離すること
### 4. 完了報告
✅ 技術詳細ドキュメントを作成しました ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📍 作成先: specs/[taskname]/technical-details.md 📝 エンドポイント数: [N]件
💡 次のアクション:
- Phase計画:
/sdd:plan-phases [taskname] - 不明点の明確化:
/sdd:clarify-spec [taskname]━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
## 注意事項
- **⚠️ 最重要**: steering/tech.md を必ず参照し、プロジェクトの技術標準に準拠すること
- steering/tech.md から逸脱する場合は、明確な理由と承認を得ること
- specification.mdとの役割分担を明確にする（機能要件 vs 技術実装）
- 不明なところは勝手に決めずに「**不明**」と明記すること
## 内部品質チェック
**重要**: 以下のチェックはコマンド内部で実施し、**生成されるspecファイルには結果を記載しません**。
### ステアリングドキュメントレビュー（内部処理）
ドキュメント生成後、内部的にステアリングドキュメントとの整合性を確認：
- tech.mdの技術スタックとの整合性（最重要）
- structure.mdの構造規約との整合性
- product.mdのビジネス目標との整合性
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
### 矛盾チェック（内部処理）
ドキュメント生成後、内部的に仕様書間の矛盾を確認：
- specification.mdとtechnical-details.mdのデータ設計の整合性
- API設計と機能要件の整合性
- データモデルとAPI仕様の整合性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。