| name | quick-issue |
| description | 確認不要で手早く GitHub Issue を起票する。grill-me/to-plan/to-issues の正式フローを経由せず、思いついた要望・課題・バグをその場で軽量に Issue 化したいときに使う。「quick-issue」「issueを起票して」「issueを作って」と指示されたとき。 |
Quick Issue
正式な開発フロー（/grill-me → /to-plan → /to-issues）を経由せず、確認なしで即座に GitHub Issue を1件起票するスキル。スライス分割・依存関係の整理・ユーザーへの確認は行わない。手早く起票することが目的。
正式フローでまとまった作業を Issue 化したい場合は /to-issues を使うこと。本スキルは単発の軽量起票専用。
このスキルの方針
- 確認不要：ユーザーへの問い返し（AskUserQuestion・承認待ち）は行わず、与えられた情報からそのまま起票する。
- デフォルトで自分にアサイン：
--assignee @me を付与する。
- 必須2セクション（「この変更が必要な理由」「タスク一覧」）を本文に必ず含める。
処理フロー
1. 入力の解釈
引数または直前の会話コンテキストから、起票したい内容を読み取る。情報が薄くても起票を止めず、読み取れた範囲でタイトルと本文を組み立てる。
- タイトル：内容が一目で伝わる簡潔な日本語（目安40文字以内）。プロジェクトの用語集（
docs/reference/glossary.md）の語彙に寄せる。
- 起票内容がまったく不明な場合のみ、起票せずユーザーに1行確認する。
2. 本文の組み立て
下記テンプレートに沿って本文を作る。「タスク一覧」は読み取れる範囲でチェックボックスに分解する（不明なら最小限の1〜2項目でよい）。設計書の更新が必要そうなら、その更新タスクも含める（CLAUDE.md 仕様駆動ルール）。
## この変更が必要な理由
なぜこの Issue が必要なのかを WHY 中心に記述する。解決する課題・背景・もたらす価値を書く。実装の詳細（HOW）ではなく目的に焦点を当て、別セッションの実装者が判断に迷ったとき優先順位を自力で決められる状態を目指す。
タスク一覧
実装を完了させるために必要なタスクをチェックボックス形式で列挙する。実装者はこのリストを1つずつ確認し、完了ごとに gh issue edit でチェックを更新する（CLAUDE.md の厳守ルール）。設計書の更新が必要な場合は、その更新タスクも必ず含めること。
3. 起票
gh issue create を1コマンドで実行する。本文はヒアドキュメント or --body-file で渡す。
gh issue create \
--title "<タイトル>" \
--assignee @me \
--body "$(cat <<'EOF'
## この変更が必要な理由
...
## タスク一覧
- [ ] ...
EOF
)"
- ラベルはユーザーが明示した場合のみ
--label で付与する（指定がなければ付けない）。
- 起票後、作成された Issue の URL を表示して完了とする。
使用方法
/quick-issue <起票したい内容>
例：
/quick-issue ログイン失敗時のエラーメッセージが英語のままなので日本語化したい
