6.7 KiB
argument-hint, allowed-tools
| argument-hint | allowed-tools | |||||
|---|---|---|---|---|---|---|
| <タスク名> |
|
technical-details.md の実現可能性検証と更新
specs/[taskname]/technical-details.md を実際のプロジェクト構造と照らし合わせて検証し、矛盾や不整合がある場合は technical-details.md を更新します。
実行手順
1. タスク名の確認
引数で指定されたタスク名、または specs/ ディレクトリ内の既存タスク一覧からタスクを選択。
タスク名が指定されていない場合、ユーザーに確認すること。
2. ステアリングドキュメントの読み込み
以下のステアリングドキュメントを読み込み、プロジェクトのコンテキストを把握：
specs/_steering/product.md- プロダクト方針specs/_steering/tech.md- 技術スタックspecs/_steering/structure.md- プロジェクト構造specs/_steering/principles.md- 開発原則
ステアリングドキュメントが存在しない場合は警告を表示し、処理を続行。
3. technical-details.md の読み込み
specs/[taskname]/technical-details.md を読み込み、記載されている内容を把握：
- アーキテクチャ構成
- 技術スタック
- インフラ構成
- データベース設計
- API設計
- ファイル構造
- 依存ライブラリ
- その他全ての記載内容
4. プロジェクト構造の調査
technical-details.md に記載されている内容に関連する実際のプロジェクト構造を調査：
4.1 技術スタックの確認
記載されている技術に関連する設定ファイルを確認：
package.json- 依存ライブラリ、スクリプト、バージョンtsconfig.json/jsconfig.json- TypeScript/JavaScript設定.node-version/.nvmrc- Node.jsバージョン- ビルドツールの設定ファイル（webpack.config.js, vite.config.ts, next.config.js など）
- その他、technical-details.md で言及されている設定ファイル全て
4.2 ディレクトリ構造の確認
記載されているディレクトリやファイルパスが実際に存在するか、または既存の構造と整合するかを確認。
4.3 データベース関連の確認
記載されているデータベース設計に関連する既存ファイルを確認：
- ORM/スキーマファイル（Prisma, TypeORM, Sequelize など）
- マイグレーションファイル
- データベース設定ファイル
- その他データベース関連の全てのファイル
4.4 API構造の確認
記載されているAPIエンドポイントやルーティングに関連する既存ファイルを確認：
- ルーティングファイル
- コントローラー
- ミドルウェア
- API関連の全てのファイル
4.5 その他の確認
technical-details.md で言及されている全ての要素について、実際のプロジェクト内の対応するファイルや設定を確認。
5. 整合性チェック
technical-details.md の記載内容と実際のプロジェクト構造を比較し、以下を確認：
- 記載されている技術スタックは既存のものと互換性があるか
- 記載されているディレクトリやファイルパスは既存の構造と整合するか
- 記載されているライブラリは既存の依存関係と競合しないか
- 記載されているバージョンは実現可能か
- 記載されている設計は既存のパターンと矛盾しないか
- その他、全ての記載内容が実際のプロジェクトで実現可能か
6. technical-details.md の更新
検証結果に基づいて、technical-details.md を更新：
更新方針
-
矛盾する記述の修正
- 既存プロジェクトと矛盾する箇所を実現可能な内容に修正
-
曖昧な記述の具体化
- プロジェクト構造から判明した具体的な情報で更新
- 曖昧な記述を具体的なパス、ファイル名、ライブラリ名に修正
-
不足情報の補完
- 既存プロジェクトから必要な情報を補完
- 実際のパスやファイル名を明記
-
新規・既存の明示
- 新規作成が必要なものは「新規作成」として明記
- 既存を利用するものは「既存を利用」として明記
-
不明点の明記
- 判断できない箇所は「不明」と明記
- 複数の実装案がある場合は「案A」「案B」として列挙
更新時の注意事項
- 既存の構造を尊重し、既存の規約に従う
- 曖昧な表現を避け、具体的に記述
- 理想論ではなく、実際に実装可能な内容を記述
- 大規模な変更が必要な場合は段階的な移行方法を記述
7. 完了報告
✅ technical-details.md の実現可能性検証と更新が完了しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 更新先: specs/[taskname]/technical-details.md
📝 変更箇所: [N]箇所
💡 次のアクション:
- 不明箇所がある場合: `/sdd:clarify-spec [taskname]`
- Phase構成作成: `/sdd:plan-phases [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
注意事項
- 推測ではなく、実際のファイルやコードに基づいて判断すること
- 曖昧な表現を避け、具体的なパス、ファイル名、ライブラリ名を使用
- プロジェクトの既存の規約や構造を優先すること
- 判断できない箇所は「不明」と明記し、複数案がある場合は列挙すること
内部品質チェック
重要: 以下のチェックはコマンド内部で実施し、生成されるspecファイルには結果を記載しません。
ステアリングドキュメントレビュー（内部処理）
検証・更新後、内部的にステアリングドキュメントとの整合性を確認：
- tech.mdの技術スタックとの整合性
- 既存プロジェクトとの互換性
- structure.mdの構造規約との整合性
- principles.mdの開発原則との一致
問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。
矛盾チェック（内部処理）
検証・更新後、内部的に仕様書間の矛盾を確認：
- technical-details.mdの変更が他のドキュメントと整合しているか
- specification.mdとの整合性
- overview.mdとの整合性
矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。