majiayu000 Prompt Review Skill
When to use
- 新しい prompt file を追加/変更した直後
- /コマンドの出力が毎回ブレる、長すぎる、使いづらいと感じたとき
- prompt が増えてきて整理したいとき（重複・命名の整合を取りたい）
Inputs
- 対象パス（例:
.github/prompts/bootstrap-docs.prompt.md） - もしくは
.github/prompts/全体
Output（固定フォーマット）
docs/prompt-review-report.md を作成/更新し、以下の構成で出す:
- Summary（全体所見 + P0/P1/P2件数）
- Prompt-by-prompt findings（各promptごと）
- P0: 壊れる/呼べない/誤動作しうる
- P1: 使いにくい/ブレやすい
- P2: 改善余地（読みやすさ/保守性）
- Recommended edits（具体的修正案。必要なら差分形式）
Review checklist（必須観点）
A. Frontmatter & naming
- name がユニークで、短く、用途が想像できる
- description が「何をする / いつ使う」を言い切っている
- argument-hint が実際の入力に合っている（例が有効）
- agent/tools が適切（過剰権限でない）
- prompt files はMarkdownでワークフローを定義する想定なので、frontmatterの整備が重要
B. Reusability (variables)
${input:...}を最低2つ以上使い、再利用可能- 入力が曖昧なら「期待値」や「選択肢」を input の説明に入れる
- 変数名が一貫（product, feature, scope など）
C. Output stability
- 出力フォーマットが固定（章立て/表/チェックリスト）
- “成功時/失敗時の出力” が明示されている
D. Duplication control
- ルール/規約は instructions / skills に寄せ、promptにコピペしない
- 参照先（docs/ や skills）をリンクで示す（重複排除）
E. Tooling & safety
- tools は最小限（read/search中心、edit/executeは必要時のみ）
- 破壊的操作や外部送信をしない（必要なら明示し承認ゲートを設ける）
- “自動実行/停止/承認待ち”の制御が明確（あなたのフローだと特に重要）
Procedure
.github/promptsを列挙し、対象promptを特定- 各promptを読み、A〜Eで評価
- 可能なら
scripts/validate_prompts.pyを実行し、機械チェック結果も取り込む docs/prompt-review-report.mdを更新して提示- ユーザーが「修正して」と言った場合のみ、該当promptを直す（勝手に改変しない）