create-issue

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 を含めてよい。

手順

1. 入力の収集

   • 会話文脈から「背景」「やりたいこと」「配慮してほしいこと」に相当する情報を抽出する
   • 「背景」「やりたいこと」への抽出は背景と What に限定する。会話文脈に How(実装方法)が含まれていても、そこには書かない(実装上の要望は「配慮してほしいこと」に回す)
   • タイトルが指定されていない場合は「やりたいこと」から生成し、ユーザーに提示して確認する

2. 不足情報の聞き出し

   背景・What の情報が不足していて、本文を書かないと認識齟齬を生む場合は、ユーザーに聞き出す。聞き出すのは背景と What だけ。How は聞かず、推測もしない。

   聞き方は一度にまとめて行う:

   • 不足している項目(背景・What)を一覧化する
   • 各項目に推奨案(想定回答)を添えて一括提示する
   • ユーザーは推奨案に異論がある項目だけ答えればよい形にする。無回答は推奨案で合意とみなす
   • 聞き出した結果を本文に反映する

   How は聞かない。実装要望は、ユーザーが自発的に出した場合のみ「配慮してほしいこと」に書く。

3. 投稿先リポジトリの決定

   • --repo owner/repo が指定されていればそれを使う
   • 未指定なら happy663/dotfiles をデフォルトとする
   • 外部リポジトリ(OSS等)への投稿は、ユーザーが明示的に指定した場合のみ実行する

4. 本文をファイルに書き出す

   • HEREDOC のエスケープ罠を避けるため、必ずファイル経由で渡す
   • パス例: /tmp/issue-body.md
   • Write ツールで直接書き出す

5. 投稿前の確認

   • タイトルと本文をユーザーに提示する
   • 投稿先リポジトリを明示する
   • ユーザーの承認を得てから投稿する

6. 投稿

   gh issue create --repo <owner/repo> --title "<title>" --body-file /tmp/issue-body.md
   

7. 投稿後の検証

   • 発行された 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 は聞かない・推測しない
• タイトルは動詞始まり推奨(例: 「〜を追加する」「〜を修正する」)
• 敬語や冗長な表現は避け、端的に記述する