279 lines
9.4 KiB
Markdown
279 lines
9.4 KiB
Markdown
---
|
||
argument-hint: <タスク名>
|
||
description: 技術詳細とアーキテクチャ設計を作成
|
||
allowed-tools: ["Read", "Write", "Task", "AskUserQuestion"]
|
||
---
|
||
|
||
# 技術詳細ドキュメントを作成します
|
||
|
||
タスクの技術仕様とアーキテクチャ設計を詳細化し、`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` を生成：
|
||
|
||
```markdown
|
||
# 技術詳細ドキュメント
|
||
|
||
## アーキテクチャ
|
||
|
||
### システム構成図
|
||
[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のデータ要件を具体的なスキーマに変換]
|
||
|
||
#### エンティティ図
|
||
|
||
```mermaid
|
||
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]
|
||
```sql
|
||
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 を参照]
|
||
|
||
このタスク固有の追加ツール:
|
||
- [タスク固有のツール]
|
||
|
||
### セットアップ手順
|
||
```bash
|
||
# 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仕様の整合性
|
||
|
||
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。
|