Menu
構造化されたタイトルと本文で GitHub Issue を生成する。単独で成立し、前段を要求しない。challenge / research の成果物が会話にあれば本文の根拠に使い、/think の plan 下書きがあれば `## Plan` 節へ移設する。issue 番号を渡すと、起票済みで Plan 節を持たない issue へ plan を転記する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
issue が build に投入できる形かを検分し、verdict (build-ready / needs-plan / needs-fix) と指摘を返す。起票には使わない (/issue)。PR のスクリーニングには使わない (/preview)。
Inspect whether an issue is in shape to hand to build, returning a verdict (build-ready / needs-plan / needs-fix) and the findings. Do NOT use to file an issue (use /issue) or to screen a PR (use /preview).
critic-design による敵対的批判を伴う設計探索。生き残った案を構造化 plan にまとめ、自己点検して呼び出し元に返す。plan の永続先は issue の Plan 節が唯一。計画意図のないコードベース調査には使わない (代わりに /research)。
Design exploration with adversarial critique by critic-design. Assembles the surviving approach into a structured plan, self-checks it, and returns it to the caller. The issue's Plan section is the plan's only persistent home. Do NOT use for codebase investigation without planning intent (use /research instead).
Generate GitHub Issue with structured title and body. Standalone; requires no upstream stage. When challenge / research artifacts exist in the conversation, they feed the body's evidence; when a /think plan draft exists, it is transferred into the `## Plan` section. Given an issue number, it transfers a plan into a filed issue that has no Plan section.
scout CLI 経由で Web 検索、ページ取得、GitHub リポジトリ探索を行う。
| name | issue |
| description | 構造化されたタイトルと本文で GitHub Issue を生成する。単独で成立し、前段を要求しない。challenge / research の成果物が会話にあれば本文の根拠に使い、/think の plan 下書きがあれば `## Plan` 節へ移設する。issue 番号を渡すと、起票済みで Plan 節を持たない issue へ plan を転記する。 |
| when_to_use | Issue作って, Issue書いて, Issue作成, GitHub Issue, buildに渡す準備, Plan転記 |
| allowed-tools | Bash(gh:*) Bash(cat:*) Bash(ugrep:*) Read AskUserQuestion |
| model | opus |
| argument-hint | [issue description | issue number] |
単独で成立する起票スキル。会話コンテキストに /challenge//research//think の成果物があれば、/challenge の verdict は起票判断に、/research の発見は本文の根拠に使い、/think の plan 下書きは ## Plan 節へ移設する。どの段を通すかは人間が決める。
$ARGUMENTS は Issue 説明。空なら AskUserQuestion で説明を尋ねる。
issue 番号か URL だけを受け取ったときは、起票済み issue へ plan を転記する。gh issue view <ref> --json title,body で取った本文を起草済みとみなして Phase 2 から始め、Phase 4 の起票を gh issue edit <ref> --body-file <path> に置き換える。plan 下書きが無ければ /think の実行を提案して止まり、## Plan を既に持つ issue は /qualify の検分に回す。
~/.claude/settings.json から language を読み、その言語で Issue 本文とテンプレートを翻訳する。未設定なら英語をデフォルトとする。英語のまま残すのは識別子/コード/コマンド/固有名だけで、設定言語に平易な同義語がある英単語を地の文に混ぜない。テンプレート由来の見出しと Plan 節の抽出キーワードは英語のまま維持する。
.claude/OUTCOME.md があれば読み、issue が outcome に資するか確認する判別不能な場合は feature をデフォルトとする。タイトルには種別をキャピタライズして角括弧で囲ったプレフィックスを付ける。
| 種別 | 用途 |
|---|---|
| bug | 既存のものが壊れているか期待通り動かない |
| feature | 新しい能力や拡張要望 |
| docs | ドキュメント追加や訂正 |
| chore | メンテナンス、設定、依存更新 |
ここで決めるのは起票するかどうか。次の 3 基準をすべて満たす bug は軽微で、起票せず /fix で直接対応する選択肢がある。起票する場合も、本文フッターに「軽微につき /fix で対応してもよい」と注記する。原因未特定の間欠 bug は該当しない。
| 基準 | 内容 |
|---|---|
| 変更範囲 | 1 ファイルに収まる |
| 再現 | 再現手順が確定している |
| 調査 | コードベースの横断調査が不要 |
issue の Why を、本文起草の前に確立する。1 メッセージにつき 1 質問し、期待する答えを仮説として推奨回答に添える。コードベースで解決できる疑問は、問う前に Read や ugrep で探索する。次の 3 点が説明から読み取れるか、次に問う質問の答えを予測できるようになったら、質問をやめて起草に進む。
| 質問 | 本文での置き場 |
|---|---|
| 誰がこれを必要としているか | What & Why |
| どんな痛みが存在し、その根拠は何か | What & Why |
| 計測可能な結果として何を成功とみなすか | Acceptance Criteria |
gh api "repos/{owner}/{repo}/contents/.github/ISSUE_TEMPLATE" --jq '.[].name' で .md を列挙する。ファイル名や name が種別を含む GitHub テンプレートがあれば、その本文を読んで先頭 frontmatter の name/about/labels/title を外し骨格にする。無ければ、skill ディレクトリ直下の templates/<type>.md を使う。
ユーザーが決めた要件は無印。ユーザーが未決定のまま残した判断と未検証の事実だけに (tentative: <着手時のアクション>) をインラインで付ける。不確かな HOW は書かない。
| 論点 | 内容 |
|---|---|
| マーカーの言語 | 本文言語を問わず tentative のまま書く。build の抽出キーワードのため |
| issue レベルの前提 | Premises 節を持つ feature と bug はそこへ置き、chore と docs はインラインだけ |
| 下流での扱い | build が assumptions として抽出し、draft PR でユーザーが覆せる veto 対象になる |
独立して実装可能な criteria が 2 つ以上あれば、AskUserQuestion で分割を問う。選択肢は「1 issue のまま」か「epic と子 issue に分割」。1 つの成果物を検証するだけの細かいチェックは数えず、1 issue 内に留める。N 件の起票は取り消しにくいため、自動分割はしない。承認時はこの issue を epic として起票し、以降のフローはそのまま epic に通す。
${CLAUDE_SKILL_DIR}/references/prose-review.md と、本文言語に対応する空句ファイルの基準で本文をインライン精査する。空句ファイルは日本語なら phrases.ja.md、英語なら phrases.en.md。Phase 3 で移設する Plan 節は対象外とし、手を入れない/think のものがあればそれを、無ければ .claude/workspace/planning/ の該当ファイルを選ぶ。plan 下書きが無ければ、この照合を省く本文と ## Plan で同じ知識が重なる箇所すべてを対象にする。同じ知識かどうかは、片方を直すともう片方も直る関係かで判定し、独立に変わりうるものは両方に残す。重複した本文側は ## Plan への参照に置き換える。置き換えたあとも、その見出しが何をする変更かを述べる 1 行、却下理由と根拠の file:line、痛みの記述は本文に残す。参照は本文から ## Plan へ向ける。plan は /think が本文より先に独立したファイルへ書き出し、本文の節はそのあとに生まれる。食い違うときは plan を正として本文を直す。Acceptance Criteria も Outcome と重なるが、人間のマージ判断に使い build に届かないので本文に残す。
| 本文の節 | Plan 側の対応 |
|---|---|
| Approach | unit の contract |
| Testing Decisions | T-NNN |
| Premises | 前提 |
| Scope の In scope | files |
/think の plan 下書きがあるときだけ実施し、無ければ節ごと省略する。.claude/workspace/planning/ から issue のタイトルに一致する最新の *.plan.md を Read し、## Plan と ## Backlog candidates の両節をそのまま本文へ移設する。書式と検証は /think の書き出し時と build の Load validate が担い、移設した内容には手を入れない。
Create this issue? と確認する。## Plan 節が無く build workflow に渡す規模なら、選択肢に「起票を保留して /think で plan を作る」を足すgh issue create --title "<title>" --body-file <path> で起票する。出力から Issue URL を取得する/slice の実行を提案する。自動では起動しない/fix <番号>、4 ファイル以上または新機能なら build workflow に番号を渡す。build workflow に渡す issue が Plan 節を持たないなら、/think で plan を作り /issue <番号> で転記してから渡し、渡す前の検分には /qualify を使う。いずれも自動では起動しないpriority:* は必須とし、影響度に応じて critical、high、medium、low のいずれかを付ける。それ以外のラベルは、リポジトリの慣例に合わせる。