| name | create-issue |
| description | 会話文脈から GitHub issue を作成する。「issueを作って」「issue立てて」等のリクエストで使用。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクション構成。「背景・やりたいこと」は背景と What(何をやりたいか)に集中し How(実装方法)は書かない。「配慮してほしいこと」は任意(省略可)で制約・要望を書く。 |
| argument-hint | [title] [--repo owner/repo] |
| allowed-tools | Bash, Write, Read |
| disable-model-invocation | true |
Issue作成スキル
会話文脈から GitHub issue を作成する。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクションで組み立てる。「背景」「やりたいこと」は背景と What(何をやりたいか)に集中し、How(実装方法)は書かない。実装方法は担当者の判断に委ねる。実装上の要望や制約がある場合は「配慮してほしいこと」に書いてよく、そこでは How を含めてもよい。
必須入力
- タイトル: 一行で何のissueか分かるもの
- 本文: 下記の3セクション構成
- リポジトリ: 明示指定がなければ
happy663/dotfiles
本文構成
以下の3セクションで作成する。「背景」「やりたいこと」は背景と What を書き、How(実装方法)は書かない。「配慮してほしいこと」は任意で、書くべきことがなければ省略してよい(ないならないで問題ない)。
- 背景: なぜやるか、どういう文脈か。判断材料になる情報を残す
- やりたいこと: 達成したいゴール(What)。どう実装するか(How)ではなく、何を達成したいかを書く
- 配慮してほしいこと(任意・省略可): 進める上で意識してほしい制約・前提、または実装上の要望。ここでは How(実装方法の指定)を含めてもよい。Must と Nice-to-have を書き分けるため、各項目の先頭に
[必須] / [できれば] プレフィックスを付ける。ここに書く内容は着手時点の想定であり、調査の過程で変わりうる(例: 実は配慮不要だった、別の配慮が必要だった、[必須] が [できれば] に緩和された等)ことを前提とする
完了条件は独立セクションとして持たない。「やりたいこと」を具体的に書けば実質的に兼ねる。ゴールがぼやける場合は「やりたいこと」の末尾に達成状態を明記する。
What と How の境界
「背景」「やりたいこと」に書くのは背景と What だけ。How は意図的に書かない。迷ったときの判断基準:
- What: 達成したい状態・成果。「〜ができること」「〜を解決すること」
- How: 実装方法・技術選定・手順。「〜というライブラリを使う」「〜というファイル構成にする」「〜の手順で進める」
How になりそうな記述は「やりたいこと」に書かず、担当者に委ねる。ただし、実装方法に関する要望や動かせない制約は「配慮してほしいこと」に書いてよく、そこでは How を含めてよい。
手順
-
入力の収集
- 会話文脈から「背景」「やりたいこと」「配慮してほしいこと」に相当する情報を抽出する
- 「背景」「やりたいこと」への抽出は背景と What に限定する。会話文脈に How(実装方法)が含まれていても、そこには書かない(実装上の要望は「配慮してほしいこと」に回す)
- タイトルが指定されていない場合は「やりたいこと」から生成し、ユーザーに提示して確認する
-
不足情報の聞き出し
背景・What の情報が不足していて、本文を書かないと認識齟齬を生む場合は、ユーザーに聞き出す。聞き出すのは背景と What だけ。How は聞かず、推測もしない。
聞き方は一度にまとめて行う:
- 不足している項目(背景・What)を一覧化する
- 各項目に推奨案(想定回答)を添えて一括提示する
- ユーザーは推奨案に異論がある項目だけ答えればよい形にする。無回答は推奨案で合意とみなす
- 聞き出した結果を本文に反映する
How は聞かない。実装要望は、ユーザーが自発的に出した場合のみ「配慮してほしいこと」に書く。
-
投稿先リポジトリの決定
--repo owner/repo が指定されていればそれを使う- 未指定なら
happy663/dotfiles をデフォルトとする
- 外部リポジトリ(OSS等)への投稿は、ユーザーが明示的に指定した場合のみ実行する
-
本文をファイルに書き出す
- HEREDOC のエスケープ罠を避けるため、必ずファイル経由で渡す
- パス例:
/tmp/issue-body.md
- Write ツールで直接書き出す
-
投稿前の確認
- タイトルと本文をユーザーに提示する
- 投稿先リポジトリを明示する
- ユーザーの承認を得てから投稿する
-
投稿
gh issue create --repo <owner/repo> --title "<title>" --body-file /tmp/issue-body.md
-
投稿後の検証
- 発行された issue 番号/URL を取得する
gh issue view <番号> --repo <owner/repo> --json body --jq .body で本文を取得- バックスラッシュ混入等の意図せぬエスケープがないか確認する
- 問題があればユーザーに報告する
出力フォーマット例
## 背景
- [なぜ必要か、どういう文脈か]
- [判断材料になる周辺情報]
## やりたいこと
- [達成したいゴール(What)]
- [具体的なアウトプット像]
## 配慮してほしいこと
- [必須] [制約・前提、または実装方法(How)の要望]
- [できれば] [守れるとうれしい希望]
注意事項
- 本文は必ずファイル経由(
--body-file)で渡す。--body の直接指定や HEREDOC は使わない
- コードブロックやバックティックを含む場合は、投稿後の確認を必ず行う
- 「背景」「やりたいこと」は背景と What を書き、How(実装方法)は書かない。実装方法は担当者の判断に委ねる
- 「配慮してほしいこと」は必須ではない。無理に埋めなくてよい。書くべきことがなければ省略し、ないならないで問題ない
- 「配慮してほしいこと」には制約・前提、または実装方法(How)の要望を書いてよい
- 「配慮してほしいこと」の各項目には
[必須] / [できれば] を付けて強弱を明示する。担当者が Must と Nice-to-have を区別できるようにするため
- 「配慮してほしいこと」は着手時点の想定であり、調査で変わりうることを担当者に共有する。変化が生じたら issue コメントで更新経緯を残す運用を推奨する
- 不足情報は背景・What だけを一括で聞き出す。How は聞かない・推測しない
- タイトルは動詞始まり推奨(例: 「〜を追加する」「〜を修正する」)
- 敬語や冗長な表現は避け、端的に記述する
