Menu
Issue本文の着手レディネスレビュー。作業着手に足る記述品質があるかを検証する全 workflow 共通ゲート。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| description | Issue本文の着手レディネスレビュー。作業着手に足る記述品質があるかを検証する全 workflow 共通ゲート。 |
| name | issue-review-ready |
Issue 本文が作業着手に足る記述品質を持つかをレビューする 全 workflow 共通のゲートスキル。
issue-create 後、issue-start の前に実行し、記載の矛盾・不足・根拠のない推測を指摘する。
| タイミング | このスキルを使用 |
|---|---|
| Issue 作成後、作業着手前 | ✅ 必須 |
| 既に作業フェーズに入っている Issue | ❌ 不要 |
ワークフロー内の位置:
worktree 不要（メインリポジトリから実行可能）。
常に注入される変数:
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 正規化済み Issue ID（GitHub 数値または local ID） |
issue_ref | str | 人間可読の Issue 参照（GitHub では #<issue_id>、local では bare ID） |
step_id | str | 現在のステップ ID |
$ARGUMENTS = <issue_id>
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される（harness が provider 別に整形する）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。
| # | 観点 | 指摘対象 |
|---|---|---|
| 1 | 構造の完備 | 概要・目的・完了条件の3セクションが存在し、空でない |
| 2 | 概要の具体性 | 「何を」「どこに」が特定できない曖昧な記述（対象モジュール・機能が不明） |
| 3 | 目的の根拠 | 背景・動機がない「〜したい」だけの記述、または想像・推測に基づく理由付け |
| 4 | 完了条件の検証可能性 | 客観的に判定不能な条件（「改善する」「最適化する」等の主観表現） |
| 5 | 1次情報の明示 | 事実として述べている内容に根拠がない。想像や勝手な予測が事実のように書かれている |
| 6 | 記述間の矛盾 | 概要と完了条件の不整合、目的と完了条件の乖離、スコープの暗黙的な膨張 |
| 7 | 作業スコープの推定可能性 | 作業対象の判断材料が本文にない |
Issue のラベル（type:feature / type:bug / type:refactor / type:docs）に応じて、上記共通観点に加えて以下を確認する。
ラベル取得（type: ラベルを全件、改行区切りで取得する）:
uv run kaji issue view [issue_id] --json labels --jq '[.labels[].name] | map(select(startswith("type:"))) | .[]'
判定の優先順（「未付与」「複数付与」「canonical 外」を区別）:
type: ラベルは single-select 運用（1 Issue に 1 ラベルのみ）。以下の cardinality チェックを上から順に適用する:
type:feature / type:bug / type:refactor / type:docs） → 対応する追加観点を適用する。type:test / type:chore / type:perf / type:security など） → type:feature と同等の追加観点（feat 列）を適用する（dispatch 方式のフォールバック規則）。| # | 観点 | feat | bug | refactor | docs |
|---|---|---|---|---|---|
| 8 | ユースケース / ユーザーストーリー | ✅ ユースケース or 「[Role] として [Goal] のために [Action] したい」が 1 本以上 | — | — | — |
| 9 | スコープ境界の明示 | ✅ feat の範囲内で閉じるか（混在禁止の宣言があるか） | — | ✅ feat / fix の混在禁止が明記 | — |
| 10 | OB / EB / 再現手順 | — | ✅ 壊れた挙動（OB）・あるべき挙動（EB）・再現手順が分離して記述 | — | — |
| 11 | 測定可能な改善指標 | — | — | ✅ 現状の問題が観測値に落ちており、改善指標が定量 or 定性で固定されている | — |
| 12 | 対象ドキュメントパス | — | — | — | ✅ 対象ドキュメントのパスまたは領域が明示されている |
| 13 | コード変更の非混入宣言 | — | — | — | ✅ docs-only であり、コード変更が混ざらない宣言がある |
重み付けの方針: 上記追加観点は「その type 特有の情報不足」を検出する目的。共通観点 1〜7 が通っていても、追加観点で不足があれば RETRY とする。
以下のいずれかが Issue 本文中またはリンク先に存在すれば、根拠ありと判断する:
docs/ 配下のファイルパス）#123 形式）作業スコープが推定可能であれば OK。workflow によって判断材料は異なる:
dev workflow（コード変更を含む Issue）:
docs-only workflow:
docs/dev/, CLAUDE.md, スキル定義）issue-review-design の役割）uv run kaji issue view [issue_id] --json title,body,labels --jq '{title: .title, body: .body, labels: [.labels[].name]}'
取得した本文を以降のステップで分析する。
## 概要, ## 目的, ## 完了条件 の3セクションが存在し、内容が空でないことを確認Step 1 で取得した labels から type を判定し（上記「ラベル取得」の優先順に従う）、対応する追加観点を確認する:
type:feature（1 件） → 観点 8, 9type:bug（1 件） → 観点 10type:refactor（1 件） → 観点 9, 11type:docs（1 件） → 観点 12, 13type:test / type:chore / type:perf / type:security 等） → 観点 8, 9（feat と同等）| status | 条件 |
|---|---|
| PASS | 全観点クリア → 作業着手に進行可 |
| RETRY | 矛盾・不足・根拠不明あり → 具体的指摘を提示、修正後に再レビュー |
| ABORT | Issue 自体が不適切（重複、目的不明で修正不能等） |
Verdict に応じて以下の形式で Issue コメントに投稿する。
PASS の場合:
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
## レディネスレビュー
全観点クリア。作業着手に進行可。
EOF
RETRY の場合:
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
## レディネスレビュー
### 指摘事項
1. **[観点名]**: 具体的な指摘内容
2. **[観点名]**: 具体的な指摘内容
### 判定
RETRY — 上記を修正後、再度 `/issue-review-ready [issue_id]` を実行してください。
EOF
ABORT の場合:
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
## レディネスレビュー
### 理由
具体的な ABORT 理由（重複先 Issue 番号、修正不能と判断した根拠など）。
### 判定
ABORT — この Issue は作業着手の対象外です。
EOF
以下の形式で報告してください:
## レディネスレビュー完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 判定 | PASS / RETRY / ABORT |
### 次のステップ
- PASS: `/issue-start [issue_id]` で worktree をセットアップ
- RETRY: Issue 本文を修正後、再度 `/issue-review-ready [issue_id]` を実行
- ABORT: Issue を close するか、内容を根本的に見直し
実行完了後、以下の形式で verdict を出力すること:
---VERDICT---
status: PASS
reason: |
全チェック観点をクリア
evidence: |
構造完備、具体性・根拠・検証可能性・1次情報・整合性・スコープ推定すべて問題なし
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | 全観点クリア |
| RETRY | 指摘事項あり |
| ABORT | Issue 自体が不適切 |
dev workflow 向けの最終チェック。PR 前に品質ゲート、docs 整合、設計書昇格、Issue 更新をまとめて確認する。
docs-only workflow 向けの最終チェック。docs 整合と Issue 状態を確認し、PR に進めるか判定する。
docs review の指摘に対応し、ドキュメントのみを修正する。コードやテストは変更しない。
docs-only の変更をレビューし、事実整合性・実装整合性・運用整合性の観点から判定する。
docs-only の更新を行う。コードやテストは変更せず、現行実装・CLI・運用方針との整合を確認しながら docs を修正する。
docs review の指摘が適切に修正されたかを確認する。新規指摘は行わない。