القائمة
review-ready の RETRY 指摘に基づき Issue 本文を修正する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
設計書（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 更新をまとめて確認する。
| description | review-ready の RETRY 指摘に基づき Issue 本文を修正する。 |
| name | issue-fix-ready |
issue-review-ready が RETRY を返した指摘事項に基づき、Issue 本文を修正する。
指摘を盲目的に受け入れるのではなく、妥当性を検討し、修正と反論を使い分ける。
| タイミング | このスキルを使用 |
|---|---|
/issue-review-ready で RETRY 後 | ✅ 必須 |
| PASS 済みの Issue | ❌ 不要 |
ワークフロー内の位置: create → review-ready → (fix-ready → review-ready) → start → ...
worktree 不要（メインリポジトリから実行可能）。
$ARGUMENTS = <issue_id>
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される（prompt.py 側で provider 別に整形）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。
Issue 本文の取得:
uv run kaji issue view [issue_id] --json title,body,labels --jq '{title: .title, body: .body, labels: [.labels[].name]}'
レビュー指摘の取得:
uv run kaji issue view [issue_id] --comments
最新の「レディネスレビュー」コメントから RETRY の指摘事項を抽出する。
各指摘事項について 1つずつ 検討する。
A: 修正する (Agree)
docs/ パス、関連 Issue/PR 番号、CLI 出力、ログ等B: 反論する (Disagree)
uv run kaji issue edit で Issue 本文を更新する。
uv run kaji issue edit [issue_id] --commit --body "[updated-body]"
注意事項:
通常完了条件に workflow 外の確認が混在しているという指摘は、次の手順で修正する。
docs/dev/workflow_completion_criteria.md § workflow 内完了条件と事後確認の分離を読む## 完了条件 の末尾サブセクション
### ワークフロー完了後の確認項目 へ移す- なし にする項目の文言とチェック状態は移動時に維持する。通常完了条件と事後確認の両方へ複製しない。
修正内容と反論を Issue コメントに記録する。
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
## レディネス指摘への対応報告
### 対応済み
- **[観点名]**: (指摘内容の要約)
- 修正内容: (どう修正したか)
### 見送り・反論
- **[観点名]**: (指摘内容の要約)
- 理由: (なぜ対応しなかったか。根拠となるロジック)
### 次のステップ
`/issue-review-ready [issue_id]` で再レビューを実施してください。
EOF
以下の形式で報告すること。
## レディネス指摘対応完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |
### 次のステップ
`/issue-review-ready [issue_id]` で再レビューを実施してください。
実行完了後、以下の形式で verdict を出力すること。
---VERDICT---
status: PASS
reason: |
指摘対応完了
evidence: |
全指摘事項に対応済み
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | 修正完了 |
| ABORT | Issue 自体が不適切で修正不可能 |