Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:39:29 +08:00
commit f2613ae15b
26 changed files with 5240 additions and 0 deletions

111
commands/verify/docs.md Normal file
View File

@@ -0,0 +1,111 @@
---
argument-hint: <taskname> <phase番号>
---
# Phase計画書とドキュメントの検証
指定したPhaseのドキュメントとプロセス管理が適切に行われているかを検証します。
【引数】
$ARGUMENTS
## 引数の形式
- `<taskname>` - タスク名specs/[taskname]/ディレクトリ)
- `<phase番号>` - 検証対象のPhase番号1, 2, 3...
## 検証手順
### 1. 準備
- 引数の解析未指定の場合はAskUserQuestionで確認
- `specs/[taskname]/tasks/phase{N}-*.md` の存在確認
### 2. Phase計画書のタスク完了状況チェック
Phase計画書を読み込み
- タスク目次全タスクが「完了」、TDDステップRed/Green/Refactor完了を確認
- タスク詳細:状態、開始/完了日時、依存関係を確認
### 3. Phase完了条件のチェック
Phase計画書の「Phase完了条件」セクションの各チェックボックスを確認
- 全タスク完了
- 全テスト通過
- 品質チェック成功
- コードレビュー承認
### 4. overview.mdとの整合性
- 対象Phaseの状態が「進行中」または「完了」か確認
- 前Phaseが「完了」状態か確認
- 前Phaseの成果物がoverview.mdに記載されているか確認
### 5. 次Phaseへの引き継ぎ事項の確認
Phase計画書の「次Phaseへの引き継ぎ事項」セクションを確認
- 成果物リストの存在
- 未解決の課題、技術的負債の明記
### 6. Phase間のドキュメント整合性Phase 2以降のみ
- 前Phase計画書の「次Phaseへの引き継ぎ事項」から成果物リストを抽出
- 現Phase計画書で該当成果物が言及されているか確認
### 7. 検証結果レポート
```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📋 Phase {N} ドキュメント検証レポート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 specs/{taskname}/ - Phase {N}
📅 {YYYY-MM-DD HH:MM}
## 総合評価
{✅ / ⚠️ / ❌}
## 検証結果
### タスク完了状況
{✅/⚠️/❌} {completed}/{total} タスク
### Phase完了条件
{✅/⚠️/❌} {completed}/{total} 項目
### overview.md整合性
{✅/⚠️/❌}
### 引き継ぎ事項
{✅/⚠️/❌}
### Phase間ドキュメント整合性
{✅/⚠️/❌/N/A}
## 🚨 要対応項目
{問題のリスト}
## 💡 次のアクション
✅: `/sdd:verify:requirements {taskname} {N}` で要件検証へ
⚠️/❌: 問題解決後、再検証(`/sdd:verify:docs {taskname} {N}`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
### 8. 問題への対応(⚠️/❌の場合)
AskUserQuestionで各問題の対応方針を確認最大4問/回):
- 選択肢に「修正する」「スキップする」「対応しない」等を含める
- 選択後、TodoWriteでタスク作成
## 注意事項
- ドキュメントとプロセス管理のみを検証
- コードやテストの実行は `verify:requirements``verify:quality` で実施
## 矛盾チェック(必須)
ドキュメント検証後、仕様書間の矛盾がないか必ず contradiction-checker SubAgent を使用して確認してください:
```bash
# contradiction-checker SubAgentを使用指摘のみ、修正は行わない
Task(contradiction-checker): specs/[taskname]/ の全ドキュメント間の矛盾をチェックしてください。Phase計画書の状態とタスク記録が整合しているか確認してください。
```

120
commands/verify/quality.md Normal file
View File

@@ -0,0 +1,120 @@
---
argument-hint: <taskname> <phase番号>
---
# Phase実装の品質検証
指定したPhaseの実装コードの品質、コーディング規約、テストを検証します。
【引数】
$ARGUMENTS
## 引数の形式
- `<taskname>` - タスク名specs/[taskname]/ディレクトリ)
- `<phase番号>` - 検証対象のPhase番号1, 2, 3...
## 検証手順
### 1. 準備
- 引数の解析未指定の場合はAskUserQuestionで確認
- `specs/[taskname]/tasks/phase{N}-*.md` の存在確認
- Phase計画書から実装ファイルリストを抽出
### 2. コーディング規約チェック
実装ファイルをGrepツールでチェック
**禁止事項**:
- `any`型の使用(`pattern: "\bany\b"`)→ ファイルパス:行番号を記録
- barrel import/export`pattern: "export \* from"`)→ ファイルパス:行番号を記録
**要確認**:
- `interface`の使用(`pattern: "^\s*interface\s+"`)→ コメントで理由が説明されているか確認
### 3. テストの確認と実行
- 各実装ファイルに対応するテストファイル(`*.test.ts`, `*.spec.ts`等)の存在確認
- AskUserQuestionでテストコマンドを確認例: `volta run --node $(cat .node-version) yarn test`
- テストを実行し、成功/失敗/スキップ数を記録
### 4. 品質チェックコマンドの実行
- AskUserQuestionで品質チェックコマンドを確認例: `yarn lint && yarn type-check && yarn build`
- 各コマンドを実行し、結果を記録:
- Lint: エラー数、警告数
- Type check: 型エラー数
- Build: 成功/失敗
### 5. Phase間の実装品質チェックPhase 2以降のみ
- 前Phaseの成果物がimportされているかGrepで`import`文を検索)
- 型の互換性確認type-checkの結果を参照
### 6. 検証結果レポート
```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔧 Phase {N} 品質検証レポート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 specs/{taskname}/ - Phase {N}
📅 {YYYY-MM-DD HH:MM}
## 総合評価
{✅ / ⚠️ / ❌}
## 検証結果
### コーディング規約
- any型: {✅/❌} {違反数}件
- barrel import/export: {✅/❌} {違反数}件
- interface使用: {✅/⚠️}
{違反がある場合: ファイルパス:行番号}
### テスト
- テストファイル: {exists}/{expected}
- 実行結果: 成功 {passed} / 失敗 {failed} / スキップ {skipped}
### 品質チェック
- Lint: {✅/⚠️/❌} {エラー}E / {警告}W
- Type check: {✅/❌} {エラー}件
- Build: {✅/❌}
### Phase間統合Phase 2以降
{✅/⚠️/❌/N/A}
## 🚨 要対応項目
{問題のリスト}
## 💡 次のアクション
✅: Phase完了可能。overview.mdを「完了」に更新推奨
⚠️: 警告を解決後、再検証(`/sdd:verify:quality {taskname} {N}`
❌: 重大な問題を解決後、再検証
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
### 7. 問題への対応(⚠️/❌の場合)
AskUserQuestionで各問題の対応方針を確認最大4問/回):
- 選択肢に「修正する」「対応しない」等を含める
- 選択後、TodoWriteでタスク作成
### 8. overview.md更新提案✅の場合のみ
AskUserQuestionで「overview.mdのPhase状態を『完了』に更新しますか」と確認。
## 注意事項
- `.node-version`がある場合は`volta run`を使用
- テスト・品質チェックコマンドは必ずユーザーに確認
- コーディング規約(`any`禁止、barrel禁止は厳格にチェック
## 矛盾チェック(必須)
品質検証後、仕様書とコードの整合性を必ず contradiction-checker SubAgent を使用して確認してください:
```bash
# contradiction-checker SubAgentを使用指摘のみ、修正は行わない
Task(contradiction-checker): specs/[taskname]/ の全ドキュメント間の矛盾をチェックしてください。実装の品質が仕様書の要求水準と整合しているか確認してください。
```

View File

@@ -0,0 +1,135 @@
---
argument-hint: <taskname> <phase番号>
---
# Phase要件と実装の整合性検証
指定したPhaseの実装が仕様書の要件を満たしているか、Phase間の整合性が保たれているかを検証します。
【引数】
$ARGUMENTS
## 引数の形式
- `<taskname>` - タスク名specs/[taskname]/ディレクトリ)
- `<phase番号>` - 検証対象のPhase番号1, 2, 3...
## 検証手順
### 1. 準備
- 引数の解析未指定の場合はAskUserQuestionで確認
- `specs/[taskname]/tasks/phase{N}-*.md` の存在確認
### 2. specification.mdとの整合性
#### 機能要件
- Phase計画書の「実装する機能」リストを抽出
- 各機能のファイルをGlobで検索し、実装状況を確認
- 関数・クラスの存在、パラメータ・戻り値、エラーハンドリングをコードレビュー
#### 非機能要件
specification.mdの非機能要件パフォーマンス、セキュリティ、可用性等について
- 関連キーワードでGrep検索
- 実装ファイル内の対応を確認
### 3. technical-details.mdとの整合性
#### 技術スタック
- 記載された技術・ライブラリの使用確認Grepでimport文を検索
- package.jsonとの整合性確認
#### データ設計(型定義、スキーマ等)
- Grepで型名を検索し存在確認
- データ構造の一致を確認
#### API設計
- エンドポイントの実装確認(ルーティングファイル検索)
- リクエスト・レスポンス形式の一致確認
### 4. Phase間の実装整合性Phase 2以降のみ
#### 前Phaseの成果物
- 前Phase計画書の「次Phaseへの引き継ぎ事項」から成果物リストを抽出
- Globで各成果物ファイルの存在を確認
- ファイル内容の簡易チェック
#### 前Phaseの成果物の使用状況
- 現Phase実装での前Phase成果物のimportを確認Grepで検索
- 主要な関数・型・クラスの使用箇所を確認
#### Phase間インターフェース
- 前Phaseのexport定義を確認Grepで`export`検索)
- 現Phaseでの使用方法との整合性確認
### 5. 機能レベルの実装検証
specification.mdの各機能について
- 実装ファイルを特定・読み込み
- コードレビュー:関数・クラスの存在、シグネチャ、ビジネスロジック
- エッジケース・例外処理の実装確認
- テストファイルの存在確認
### 6. 検証結果レポート
```markdown
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📐 Phase {N} 要件検証レポート
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 specs/{taskname}/ - Phase {N}
📅 {YYYY-MM-DD HH:MM}
## 総合評価
{✅ / ⚠️ / ❌}
## 検証結果
### 機能要件
{✅/⚠️/❌} {implemented}/{total} 機能
### 非機能要件
{✅/⚠️/❌/N/A}
### technical-details.md整合性
- 技術スタック: {✅/⚠️/❌}
- データ設計: {✅/⚠️/❌/N/A}
- API設計: {✅/⚠️/❌/N/A}
### Phase間実装整合性
- 前Phase成果物の存在: {✅/⚠️/❌/N/A}
- 前Phase成果物の使用: {✅/⚠️/❌/N/A}
- インターフェース整合性: {✅/⚠️/❌/N/A}
### 実装品質
- 実装詳細: {✅/⚠️/❌}
- エッジケース・例外処理: {✅/⚠️/❌}
## 🚨 要対応項目
{問題のリスト(ファイルパス:行番号を含む)}
## 💡 次のアクション
✅: `/sdd:verify:quality {taskname} {N}` で品質検証へ
⚠️/❌: 問題解決後、再検証(`/sdd:verify:requirements {taskname} {N}`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```
### 7. 問題への対応(⚠️/❌の場合)
AskUserQuestionで各問題の対応方針を確認最大4問/回):
- 選択肢に「実装する」「仕様を見直す」「対応しない」等を含める
- 選択後、TodoWriteでタスク作成
## 注意事項
- 仕様書と実装の整合性を検証
- 機能レベルの実装検証を実施(コードレビュー)
- Phase間の成果物の存在と使用状況を確認
## 矛盾チェック(必須)
要件検証後、仕様書とコードの整合性を必ず contradiction-checker SubAgent を使用して確認してください:
```bash
# contradiction-checker SubAgentを使用指摘のみ、修正は行わない
Task(contradiction-checker): specs/[taskname]/ の全ドキュメント間の矛盾をチェックしてください。実装が仕様書と整合しているか確認してください。
```