メニュー
ユーザーに提示する前のプラン品質のための軽量セルフレビューチェックリスト。 エージェント呼び出しなし — オーケストレーターがこのチェックリストを直接実行する。 以下の場合に使用: - /spec-plan の最終出力を提示する前の完了時 - レビューエージェントを起動せずに仕様⇔設計の一貫性を検証する時 - /spec-review への引き渡し前の簡易品質ゲート 非対象: フル並列エージェントレビュー（それには /spec-review --auto を使用）
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
| name | plan-self-review |
| description | ユーザーに提示する前のプラン品質のための軽量セルフレビューチェックリスト。 エージェント呼び出しなし — オーケストレーターがこのチェックリストを直接実行する。 以下の場合に使用: - /spec-plan の最終出力を提示する前の完了時 - レビューエージェントを起動せずに仕様⇔設計の一貫性を検証する時 - /spec-review への引き渡し前の簡易品質ゲート 非対象: フル並列エージェントレビュー（それには /spec-review --auto を使用） |
| allowed-tools | Read, Glob, Grep |
| model | sonnet |
| user-invocable | false |
/spec-plan フェーズ 4 の終了時に、最終プランをユーザーに提示する前にオーケストレーターが実行する軽量品質ゲート。エージェントは起動しない — コンテキスト予算を保持する。
/spec-plan フェーズ 4 の終了時、仕様と設計ファイルが保存された後にこのスキルをロード。
チェックリスト実行前のファイルサイズチェック:
このセルフレビューは以下の両方の条件が満たされる場合のみ適切:
いずれかのファイルが 200 行を超える場合:
→ このチェックリストをスキップし、--auto フラグ付きで /spec-review に直接進む
→ 並列レビューエージェントの方が大きなドキュメントに適している
これは subagent-contract スキルで定義されたクイックルックアップ制限を尊重する。
オーケストレーターが両方の出力ファイルを読み、各項目を PASS または FLAG として確認する。
| # | チェック | 検証方法 |
|---|---|---|
| S1 | 受入基準が測定可能 | 各基準に具体的な条件があり、「うまく動くべき」でない |
| S2 | エッジケースが列挙されている | 少なくとも 3 つのエッジケースまたはエラーシナリオが定義 |
| S3 | スコープ外が定義されている | セクションが存在し少なくとも 1 つの除外が記載 |
| S4 | 曖昧な言葉がない | "should"、"might"、"could"、"possibly" を検索 — 要件内にあればフラグ（根拠内は OK） |
| S5 | セキュリティ要件がある | 認証、認可、バリデーション、または「理由付きで N/A」 |
| S6 | 非機能要件がある | パフォーマンス、スケーラビリティ、または「理由付きで N/A」 |
| # | チェック | 検証方法 |
|---|---|---|
| D1 | 実装マップにファイルがある | Create/Modify アクション付きで少なくとも 1 ファイルが記載 |
| D2 | ビルドシーケンスがある | 少なくとも 2 つの順序付きステップ |
| D3 | トレードオフが文書化されている | 少なくとも 1 つのトレードオフまたは却下された代替案 |
| D4 | ファイル参照が妥当 | 参照されたファイルが存在する（Glob チェック）か「Create」としてマークされている |
| # | チェック | 検証方法 |
|---|---|---|
| C1 | 仕様要件が設計でカバーされている | 各仕様セクションが設計コンポーネントにマッピング |
| C2 | 設計が仕様と矛盾しない | 仕様要件に違反する設計選択がない |
| C3 | ビルドシーケンスが全コンポーネントをカバー | 実装マップの各コンポーネントがビルドシーケンスに出現 |
## セルフレビュー結果
合格: [N]/13
フラグ: [N]
### フラグされた項目
- [S4] 曖昧な言葉: 要件 3.2 に "should" が含まれている
- [C1] 仕様セクション「エラーハンドリング」に対応する設計コンポーネントがない
### 評価
[ALL CLEAR / MINOR FLAGS / NEEDS ATTENTION]
| 結果 | アクション |
|---|---|
| ALL CLEAR（フラグ 0 件） | プランをそのままユーザーに提示 |
| MINOR FLAGS（1-2 件のフラグ） | フラグを付記してプランを提示: 「セルフレビューで [N] 件の注意事項を検出: ...」 |
| NEEDS ATTENTION（3+ 件のフラグ） | 提示前にフラグされた項目を修正。仕様の問題は仕様を編集、設計の問題は設計を編集。その後チェックリストを 1 回再実行。 |