Menü
設計レビューの指摘事項に基づき、設計ドキュメントを修正または議論する。
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 | 設計レビューの指摘事項に基づき、設計ドキュメントを修正または議論する。 |
| name | issue-fix-design |
設計レビューで指摘された内容に対し、論理的な妥当性を検討した上で、設計ドキュメントを更新します。
| タイミング | このスキルを使用 |
|---|---|
/issue-review-design で Changes Requested 後 | ✅ 必須 |
| 一次情報の記載を求められた後 | ✅ 必須 |
ワークフロー内の位置: design → review-design → (fix → verify) → implement
常に注入される変数:
| 変数 | 型 | 説明 |
|---|---|---|
issue_id | str | 正規化済み Issue ID（GitHub 数値または local ID） |
issue_ref | str | 人間可読の Issue 参照（GitHub では #<issue_id>、local では bare ID） |
step_id | str | 現在のステップ ID |
条件付きで注入される変数:
| 変数 | 型 | 条件 | 説明 |
|---|---|---|---|
previous_verdict | str | resume または inject_verdict: true 指定ステップ | 前ステップの verdict |
cycle_count | int | サイクル内ステップのみ | 現在のイテレーション番号 |
max_iterations | int | サイクル内ステップのみ | サイクルの上限回数 |
$ARGUMENTS = <issue_id>
コンテキスト変数 issue_id が存在すればそちらを使用。
なければ $ARGUMENTS の第1引数を issue_id として使用。
issue_ref はハーネス経由ではプロンプトに自動注入される（harness が provider 別に整形する）。手動実行時は issue_id から導出する: GitHub 数値 ID なら #<issue_id>、local-* 形式なら bare ID（# を付けない）。
以下のドキュメントを Read ツールで読み込んでから作業を開始すること。
docs/dev/testing-convention.mddocs/reference/python-standards.mddocs/dev/kaji-workflow.md_shared/worktree-resolve.md の手順に従い、Worktree の絶対パスを取得。
レビュー結果の取得:
previous_verdict が存在する場合はそれを確認（ハーネス経由）レビュー内容の取得:
uv run kaji issue view [issue_id] --comments
最新の「設計レビュー結果」を取得。
設計書の現状確認:
cat [worktree_dir]/draft/design/issue-[issue_id]-*.md
各指摘事項について検討します。
設計書に「参照情報（Primary Sources）」セクションを追加：
## 参照情報（Primary Sources）
| 情報源 | URL/パス | 根拠（引用/要約） |
|--------|----------|-------------------|
| (公式ドキュメント名) | (URL) | (設計判断の裏付けとなる引用または要約) |
一次情報の例:
根拠の書き方:
アクセス可能性ルール:
レビュワー（agent）がアクセスできない一次情報は使用できません。
| 情報の種類 | 対応方法 |
|---|---|
| 公開URL | そのまま記載（推奨） |
| ログイン必須/有償 | ローカルにダウンロードしてリポジトリに配置、または該当箇所を引用 |
| 社内限定/NDA | 使用不可。公開版ドキュメントを探すか、該当箇所のスクリーンショット・引用で代替 |
A: 修正する (Agree)
B: 反論する/議論する (Discuss)
指摘を受け入れる場合、設計書を修正します。
cd [worktree_dir] && git add draft/design/ && git commit -m "docs: update design for [issue_ref]"
Issueにコメントします:
uv run kaji issue comment [issue_id] --commit --body-file - <<'EOF'
# 設計修正報告
## 対応済み
- **(指摘内容)**
- 修正: (どのように設計を変更したか)
## 議論/見送り
- **(指摘内容)**
- 理由: (なぜその設計を維持するのか、トレードオフの説明)
## 次のステップ
`/issue-verify-design [issue_id]` で修正確認をお願いします。
EOF
以下の形式で報告してください:
## 設計修正完了
| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| 対応済み | N 件 |
| 見送り | M 件 |
### 次のステップ
`/issue-verify-design [issue_id]` で修正確認を実施してください。
実行完了後、以下の形式で verdict を出力すること:
---VERDICT---
status: PASS
reason: |
修正完了
evidence: |
全指摘事項に対応済み
suggestion: |
---END_VERDICT---
重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。
| status | 条件 |
|---|---|
| PASS | 修正完了 |
| ABORT | 修正不可能 |
設計書（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 更新をまとめて確認する。