Issue Create

GitHub Issue を作成し、適切なラベルを付与する。

本スキルは issue-review-ready（.claude/skills/issue-review-ready/SKILL.md の共通・type 別チェック観点）で RETRY にならない水準の本文を生成することを目標とする。単なるテンプレ埋めではなく、「何を」「どこに」「なぜ」「何が満たされれば完了か」「その根拠」を明示できるまで対話で不足を補う。

いつ使うか

ワークフロー内の位置: create → (grill-me: 任意・明示起動) → review-ready → start → ...

引数

$ARGUMENTS = <title> [type] [description]

• title (必須): Issue タイトル
• type (任意): feat / fix / refactor / docs / test / chore / perf / security（デフォルト: feat）
• description (任意): 詳細説明。省略時は対話で収集。

type → ラベル マッピング

参照: docs/rfc/github-labels-standardization.md（GitHub Labels 標準化ドキュメント）

実行手順

Step 1: 引数の解析

$ARGUMENTS から title, type, description を取得する。

• type が未指定なら feat をデフォルトとする
• description が未指定または情報不足なら、ユーザーに対話で詳細を確認する

Step 2: review-ready のチェック観点に沿った素材収集

本文起草の前に、以下が揃っているかを確認する。不足している場合は 対話で補う、またはコマンド実行・ファイル閲覧で事実を確認する。推測で埋めない。

補強のヒント:

• 「〜したい」で止まる動機は、どの現状のどこが問題かを 1 文追加する
• 「改善する」「最適化する」等の主観表現は、計測可能な判定条件に置き換える（例: 「実行時間 X 秒以内」「Y が表示される」「make check 通過」）
• 「らしい」「はず」など推測を断定調に書かない。確認できないものは Issue に書かずに事実確認してから書く

Step 3: Issue 本文の作成（type 別テンプレートを Read して適用）

Step 1 で確定した type に応じて、以下のテンプレートファイルを Read ツールで読み込み、その本文構造に従って Issue 本文を組み立てる。

canonical 外 type のフォールバック: test / chore / perf / security を受け取った場合は issue-feat.md を使用する（dispatch 方式の制約）。

dispatch 方式: パターン A（Read ツールによる静的選択読み）を採用。SKILL.md は薄く保ち、テンプレート本文は外部ファイルで管理する。

各テンプレートには「本文の雛形」に加えて、type 特有のチェックポイント（例: feat のユースケース、bug の OB/EB、refactor の測定指標、docs の対象パス）が記載されている。テンプレート末尾の「チェックポイント」を対話で必ず確認してから本文を確定する。

共通の追記ルール（全 type 共通）:

• 設計書の配置先が明らかなら draft/design/issue-<issue_id>-<slug>.md を参考欄に予告してもよい
• 推測や「〜らしい」を事実として書かない
• 対話で集めた 1 次情報（URL / docs パス / Issue 番号 / ログ）は参考欄に必ず明記する
• 観点 15 で対話中に確定した重要判断（source of truth の指定、人間が決定済みの方針とその出典、 one-way door の未決事項）は、参考欄の末尾に ### 重要判断 サブセクションを設けて本文へ必ず記録する。 記録しないと creation の対話にしか残らず、issue-review-ready は Issue 本文と人間コメントしか 検査しないため（issue-review-ready/SKILL.md Step 1）provenance が失われ、RETRY/ABORT か provenance 欠落のまま進行する。記録形式は 判断 / 方針 / 出典（人間決定の参照）/ 未決事項 とし、 判断対象がなければ - 該当なし と確認根拠を書く。判断軸の正本は _shared/critical-decision-checklist.md
• ## 完了条件 の末尾に ### ワークフロー完了後の確認項目 を置く。workflow を RETRY して 環境非依存で同じ結果を得られない merge 後・実機適用後・外部応答後の確認だけをここへ分離する
• 事後確認がなければ同サブセクションは - なし とし、未チェックの placeholder を残さない
• 分類の正本は docs/dev/workflow_completion_criteria.md § workflow 内完了条件と事後確認の分離

Step 4: Issue 作成とラベル付与

kaji issue create --title "[title]" --body "[body]" --label "[label]"

Step 5: 完了報告

Issue 作成後に .claude/skills/grill-me/SKILL.md の「要否門番」と同じ基準で、 workflow 開始前の interview が必要かを判定する。one-way door を含みうる重要な Issue なら /grill-me [issue_id] を推奨し、軽微で不要なら /issue-review-ready [issue_id] を案内する。 grill-me を自動起動せず、issue-create 内で interview を代行しない。

以下の形式で報告すること。

## Issue 作成完了

| 項目 | 値 |
|------|-----|
| Issue | [issue_ref] |
| タイトル | [title] |
| Type | [type] |
| ラベル | [label] |
| URL | [issue-url] |

### 次のステップ

- grill-me 推奨: `/grill-me [issue_id]` を明示起動し、完了後に `/issue-review-ready [issue_id]`
- grill-me 不要: `/issue-review-ready [issue_id]`

Verdict 出力

実行完了後、以下の形式で verdict を出力すること。

---VERDICT---
status: PASS
reason: |
  Issue 作成成功
evidence: |
  Issue [issue_ref] を作成、ラベル付与済み
suggestion: |
---END_VERDICT---

重要: verdict は stdout にそのまま出力 すること。Issue コメントや Issue 本文更新とは別に、最終的な verdict ブロックは stdout に残す。

status の選択基準