Menü
Issue本文の着手レディネスレビュー。作業着手に足る記述品質があるかを検証する全 workflow 共通ゲート。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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 はハーネス経由ではプロンプトに自動注入される（prompt.py 側で provider 別に整形）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。
| # | 観点 | 指摘対象 |
|---|---|---|
| 1 | 構造の完備 | 概要・目的・完了条件の3セクションが存在し、空でない |
| 2 | 概要の具体性 | 「何を」「どこに」が特定できない曖昧な記述（対象モジュール・機能が不明） |
| 3 | 目的の根拠 | 背景・動機がない「〜したい」だけの記述、または想像・推測に基づく理由付け |
| 4 | 完了条件の検証可能性 | 客観的に判定不能な条件（「改善する」「最適化する」等の主観表現） |
| 5 | 1次情報の明示 | 事実として述べている内容に根拠がない。想像や勝手な予測が事実のように書かれている |
| 6 | 記述間の矛盾 | 概要と完了条件の不整合、目的と完了条件の乖離、スコープの暗黙的な膨張 |
| 7 | 作業スコープの推定可能性 | 作業対象の判断材料が本文にない |
| 14 | workflow 内判定可能性 | 通常完了条件に merge 後・実機適用後・外部応答後など workflow の RETRY で環境非依存に再現できない確認が混在している、または事後確認欄が ## 完了条件 の末尾サブセクションになっていない |
| 15 | 重要判断の着手可能性 | one-way door が人間未決、source of truth の指定・優先順位が矛盾、または AI が人間の判断を代行しなければ作業スコープや公開契約を確定できない |
観点 14 の分類基準は
docs/dev/workflow_completion_criteria.md
§ workflow 内完了条件と事後確認の分離を正本とする。誤分類は本文編集で修正可能なため
RETRY とし、ABORT にしない。
観点 15 は
_shared/critical-decision-checklist.md
を正本として、Issue 本文だけでなく人間の Issue コメントと、本文で source of truth に
指定された参照先も確認する。重要そうかではなく、誤ったときに後段で安く直せるかで
3 分類する。
ABORTRETRYone-way door になりやすい代表軸は、同正本の「one-way door になりやすい判断軸」を 参照する。個別項目を本 skill に複製せず、可逆性で判定する。
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・14・15 が通っていても、追加観点で不足があれば 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,comments \
--jq '{title: .title, body: .body, labels: [.labels[].name], comments: [.comments[] | {author: (.author.login? // .author), body: .body}]}'
取得した本文と人間のコメントを以降のステップで分析する。コメントが AI / bot の出力か 人間決定かを識別できない場合、そのコメントだけを人間決定の根拠にしない。
## 概要, ## 目的, ## 完了条件 の3セクションが存在し、内容が空でないことを確認## 完了条件 の通常項目は workflow を RETRY して環境非依存で同じ結果を得られるか確認する。得られない項目は末尾の ### ワークフロー完了後の確認項目 に分離され、事後確認がない場合はセクションなしまたは - なし になっていることを確認する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 | 共通観点 1〜7・14・15 と該当 type 追加観点をクリア → 作業着手に進行可 |
| RETRY | 人間決定は存在するが記述・参照が不足、またはその他の修正可能な矛盾・不足・根拠不明あり → 具体的指摘を提示、修正後に再レビュー |
| ABORT | one-way door が人間未決、source of truth 間の優先順位が未決、または 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〜7・14・15と該当type追加観点について、構造・具体性・根拠・検証可能性・1次情報・整合性・スコープ推定・workflow内判定可能性・重要判断の着手可能性に問題なし
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | 全観点クリア |
| RETRY | 指摘事項あり |
| ABORT | one-way door が人間未決、source of truth が未解決に矛盾、または Issue 自体が不適切 |
ABORT の場合、suggestion に人間が決める項目、競合する選択肢・情報源、再開条件を
具体的に列挙する。one-way door を RETRY に流して /issue-fix-ready に補完させない。
設計書（draft/design/）に基づき、TDD（テスト駆動開発）アプローチを用いて機能を実装する。
実装完了後の成果物に対し、設計整合性とコード品質の観点から厳格なレビューを実施する
Issue 作成後・workflow 起動前に人間が明示起動する要件 interview。one-way door を含みうる重要な Issue で、未決の decision tree を 1 問ずつ推奨案付きで確認し、決定事項と provenance を Issue に固定するときだけ使用する。軽微な Issue や workflow 実行中には自動起動しない。
Issue要件に基づき、draft/design/に設計書を作成する。worktree内での作業が前提。
Create a validated sequential Issue series plan from an explicitly ordered GitHub Issue list. Use when a maintainer wants to generate or update an ID-named YAML file under .kaji/series, select standard workflows from Issue type metadata and workflow descriptions, or preview a series without starting it.
dev workflow 向けの最終チェック。PR 前に品質ゲート、docs 整合、設計書昇格、Issue 更新をまとめて確認する。