القائمة
確認不要で手早く GitHub Issue を起票する。思いついた要望・課題・バグ・割れ窓の起票に使う。「quick-issue」「issueを起票して」「issueを作って」と指示されたとき。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill quick-issueيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
عرض SKILL.md
| name | quick-issue |
| description | 確認不要で手早く GitHub Issue を起票する。思いついた要望・課題・バグ・割れ窓の起票に使う。「quick-issue」「issueを起票して」「issueを作って」と指示されたとき。 |
正式な開発フロー（/grill-me → /to-plan → /to-issues）を経由せず、確認なしで即座に GitHub Issue を1件起票するスキル。スライス分割・依存関係の整理・ユーザーへの確認は行わない。手早く起票することが目的。
正式フローでまとまった作業を Issue 化したい場合は /to-issues を使うこと。本スキルは単発の軽量起票専用。
起票する Issue は この会話を一切知らない別セッション が読んで着手する。判断基準は一文：
この Issue 本文だけで、会話を知らない実装者が着手できるか。
手早く起票することと、単独で読めることは対立しない。速さのために削ってよいのは推敲であって情報ではない。会話の中にしか無い事実は、面倒でも本文に書き写す。
| ルール | 書き方 | 守らないと起きること |
|---|---|---|
| 会話依存の指示語を使わない | 「上記の」「さっきの」「この件」を禁じ、対象を毎回名指す | 何を指すか復元できず着手できない |
| 場所を名指しする | ファイルパス・シンボル・実行したコマンド・エラー出力を書く | 別セッションが探索からやり直しになる |
| 確認済みの事実と推測を分ける | 確かめたことは事実として、未確認は「未確認」と書く | どこまで再調査すべきか判断できない |
| 却下した案を書く | 取らないと決めた方法を理由ごと書く | 同じ案が蒸し返される |
--assignee @me を付与する。| ラベル | 付与条件 | 何のためか |
|---|---|---|
boy-scout | 無条件 | 正式フローを経ずに積んだ課題を後で棚卸しする |
ai-fixable | 既定（下記の名指し例外に当たらないすべて） | AI が /sweep でまとめて片付ける対象を選ぶ |
issue:needs-human-decision | 下記の名指し例外のいずれかに当たる | 人間が1件ずつ方針を決める対象を選ぶ |
policy-gap | 判定時に該当ポリシー・rules が見つからなかった | 後でポリシーを足す候補を拾う |
issue:needs-clean-session は起票時には付けない。/sweep が着手したうえで観測した事実で貼るラベルなので、起票時には判断材料が無い。
ai-fixable と issue:needs-human-decision は排他で、必ずどちらか一方だけを付ける。どちらも付かない Issue は、一斉対応からも個別相談からも漏れて誰の目にも触れなくなる。policy-gap はこの2値と直交する付加ラベルで、どちらに重ねてもよい。
既定は ai-fixable である。次の例外に当たるときだけ issue:needs-human-decision に切り替える。
| 名指し例外 | 例 |
|---|---|
| 不可逆・外部に出る | ファイル削除・公開・本番操作・外部サービス設定 |
| 要件／プロダクト方針が変わる | 「何を作るか」に触れる |
| ポリシー同士が正面衝突している | どちらを優先するかの裁定が要る |
| 比較に実測が要り、その手段が今ない | 性能・コストのトレードオフ |
| 恒久的に保守が要る資産を新設する | 新規スクリプト・hook・CI ジョブ・外部依存の追加 |
「恒久的に保守が要る資産」の例外は新設にだけ効く。既存ファイルの編集・ドキュメント／ポリシーの改訂・既存設定へのルール追加は当たらない。足した仕組みは以後ずっと保守が要るので、増やすかどうかは人間が決める（refined-engineer-judgment-principles「コードは負債」）。
「案が2つ以上ある」ことは issue:needs-human-decision の理由にならない。 推奨案が立つなら、その根拠と却下案を「対応方針」に書いて ai-fixable を付ける。ポリシーが裁定できる問いを人間に戻すと、AI に判断を委譲する仕組みが成立しない（CLAUDE.md「原則から明確に答えが出るなら AI が自分で決めてよい」）。
| 例 | ラベル | なぜ |
|---|---|---|
| タイポ・表記ゆれ | ai-fixable | 例外に当たらない |
| 新しい判断基準をどの文書に置くか | ai-fixable | 案は複数だがポリシーが裁定できる |
| 既存の静的解析設定にルールを1つ足す | ai-fixable | 既存の仕組みの手直しで、新設ではない |
| 参照先の実在を検証するスクリプトと CI ジョブを新設する | issue:needs-human-decision | 恒久的に保守が要る資産の新設である |
| ポリシーAとBが逆のことを言っている | issue:needs-human-decision | ポリシー同士が正面衝突している |
| 使わなくなったディレクトリを消すか | issue:needs-human-decision | 不可逆である |
policy-gap をいつ付けるか上の判定をする前に、該当するポリシー・rules を必ず探す（docs/policy-hub.md・.claude/rules/）。探して見つからなかったときに policy-gap を重ねて付ける。付けること自体はポリシー新設を意味せず、後の棚卸しの材料である。瑣末な件は棚卸しで捨てればよい。
引数または直前の会話コンテキストから、起票したい内容を読み取る。情報が薄くても起票を止めず、読み取れた範囲でタイトルと本文を組み立てる。
docs/reference/glossary.md）の語彙に寄せる。下記テンプレートに沿って本文を作る。テンプレートの指示は「型」なので、埋めるだけにして書き方を自分で決めない。「タスク一覧」は読み取れる範囲でチェックボックスに分解する（不明なら最小限の1〜2項目でよい）。設計書・docs/requirements.md（要件定義）の更新が必要そうなら、その更新タスクも含める（CLAUDE.md 仕様駆動ルール）。
文体：中学生が一度で追える文で書く。専門用語は使ってよい。読みにくさの原因は用語ではなく言い回しにある。
| ❌ 書かない | ✅ こう書く |
|---|---|
| その位置づけが実効を持たない | そう書いてあるだけで守られない |
| 変更耐性の最大化を企図する | 変更に強くしたい |
| 根拠を取り逃がす | 使えるはずの理由を見逃す |
| 担保する・企図する・起因する | 保つ・ねらう・原因である |
一文に主語と述語は1組まで。長い一文は切る。
図：次のどれか1つでも当てはまるときだけ、/design-doc-mermaid で図を描いて「現状」の表の直後に埋め込む。当てはまらないなら描かない。
| 発火条件 | 例 |
|---|---|
| 登場するファイル・仕組みが3つ以上あり、その参照が一直線でない（分岐・合流・双方向がある） | 複数の Skill が同じ policy を参照し、policy 側が別の Skill を呼び返す |
| 条件で振る舞いが分かれる、またはループする | 失敗時にリトライする処理 |
| 状態が移る（未着手→作業中→完了 のような遷移） | Issue ラベルの遷移規則 |
自前で Mermaid を書き起こしてはならない（CLAUDE.md）。
## この変更が必要な理由1文目に「何が困っているか」を言い切る。2文目以降に「放置するとどう損するか」を書く。合計4行以内。実装の詳細（HOW）は書かない。別セッションの実装者が、判断に迷ったとき優先順位を自力で決められる状態を目指す。
問題が見つかるまでの流れを時系列で書く。3〜5項目、1項目1文。別セッションが「なぜこれが問題なのか」を追体験できる状態を目指す。
下の表を埋めて書く。1セル1文で言い切る。行は足してよいが、観点の列は変えない。
| 観点 | 内容（1文で言い切る） |
|---|---|
| 対象箇所 | path/to/file.ts:42 の functionName など、実在するパス・シンボル |
| 確認済み | このセッションで確かめた事実 |
| 未確認 | 別セッションが調べ直すべきこと |
| 却下した案 | 取らないと決めた方法と、その理由（無ければ「なし」） |
表に入りきらない引用・エラー出力・長い根拠は <details> に逃がし、本文には出さない。
（ここに転記する）
ai-fixable を付けたときだけ書く（issue:needs-human-decision のときはセクションごと省き、「人間に決めてほしいこと」に書く）。別セッションが方針を決め直さず、そのまま着手できる状態を目指す。
採る案：何をするかを1文で書く。 根拠：なぜその案かを1文で書く。裁定に使ったポリシー・rules があれば名指しする。 却下した案：取らないと決めた案と理由を1行ずつ書く（無ければ「なし」）。
実装を完了させるために必要なタスクをチェックボックス形式で列挙する。実装者はこのリストを1つずつ確認し、完了ごとに gh issue edit でチェックを更新する（CLAUDE.md の厳守ルール）。設計書・docs/requirements.md（要件定義）の更新が必要な場合は、その更新タスクも必ず含めること。
どうなったら閉じてよいかを書く。タスクの言い換えではなく、外から観測できる状態で書く（例：npm run lint が通る）。
issue:needs-human-decision を付けたときだけ書く（ai-fixable のときはセクションごと省く）。人間が Issue を開いた瞬間に「何を決めればよいか」が分かる状態を目指す。
該当する名指し例外：どれに当たるかを書く（例：不可逆・外部に出る）。
論点：人間に何を決めてほしいのかを1文で書く（例：使わなくなった docs/old/ を消すか残すか）。
| 案 | 利点 | 欠点 | AI の見立て |
|---|---|---|---|
| 案1 | 有力（根拠を1文で） | ||
| 案2 | — |
このIssueを実装する際に使う開発フローSkillを実行順に記載する。issue番号だけで開発フローを自動追従させるための情報なので省略しない。変更種別→Skillの対応は CLAUDE.md「開発フロー」が正典。ドキュメント修正のみなど該当Skillが無い場合は「該当なし（直接編集）」と書く。
| 順 | 変更種別 | 使用Skill |
|---|---|---|
| 1 | 例：アプリ実装 | /code-dev |
本文を書いたら、この会話を知らない自分が読んだつもりで一度読み返す。満たしていない項目はその場で書き足す（ユーザーへの確認はしない）。
観点 / 内容 のままで、対象箇所・確認済み・未確認・却下した案の4行が埋まっているgh issue list --search "<タイトルの主要語>" で確認したpolicy-gap を付けた）ai-fixable / issue:needs-human-decision のどちらか一方を決めたissue:needs-human-decision を付けたなら、名指し例外のどれに当たるかを言えて、「人間に決めてほしいこと」に論点と選択肢を書いたai-fixable を付けたなら「対応方針」に採る案・根拠・却下案を書いたgh issue create を1コマンドで実行する。本文はヒアドキュメント or --body-file で渡す。
gh issue create \
--title "<タイトル>" \
--assignee @me \
--label boy-scout,<ai-fixable|issue:needs-human-decision>[,policy-gap] \
--body "$(cat <<'EOF'
（テンプレートの全セクションを埋めた本文）
EOF
)"
gh label create <名前> --description "<「付与するラベル」表の付与条件>" で作ってから同じコマンドを再実行する。事前確認はしない（毎回の gh label list は速さを損なうため、失敗したときだけ払う）。/quick-issue <起票したい内容>
例：
/quick-issue ログイン失敗時のエラーメッセージが英語のままなので日本語化したい