issue

za:issue — プランから GitHub issue を作成

/za:plan などで作った実装プランを、GitHub の issue に落とし込む。狙いは、プランに 書かれた意図を着手可能な単位に整理し、プロジェクトのルールに沿った issue として 登録すること。

issue は外部に作成され、後から消すのは手間なので、作成前に必ず内容をユーザーに提示して 承認を得る（後述）。下の手順を順番に実行する。

手順

1. 作成先リポジトリを確認する

gh repo view --json nameWithOwner -q .nameWithOwner で、issue を作る GitHub リポジトリを 確認する。これは「どこに作られるか」を取り違えないため。

• リモートが無い／gh 未認証などで取得できない場合は、その旨を伝えてユーザーに確認する （作成先を --repo owner/name で指定するか、リポジトリを用意してもらう）。勝手に 別リポジトリへ作らない。

2. プランファイルを読む

issue の元ネタとなるプランは、このスキルに渡された引数のパスから読む （例: /za:issue docs/plans/20260607-add-login.md）。

• 引数が無い場合: docs/plans/ の中身を一覧し、「どのプランから issue を作りますか？」と ユーザーに選んでもらう。docs/plans/ も無ければ、対象ファイルのパスを尋ねる。
• 指定パスが見つからない場合: 推測で別ファイルを開かず、見つからない旨を伝えて正しい パスを確認する。

プランは全文を読む。スコープ・実装ステップ・影響範囲・未確定事項が issue 分割の 判断材料になる。

3. issue 作成ルールを読む

docs/ISSUE.md を読む。これはこのプロジェクトでのissue のタイトル規約・本文テンプレート・ 使用するラベル・担当やマイルストーンの付け方などのルール。issue は必ずこれに従う （プロジェクトが書式の所有者であり、こちらが勝手な形式を持ち込まない）。

• 無い場合: 「docs/ISSUE.md が無いため標準の書式・ラベル無しで作成します」と伝え、 末尾の**「デフォルトの issue 書式」**を使う。

4. issue を設計する（必要なら分割）

プランの規模と構造を見て、1 つの issue にするか、複数に分割するかを判断する。

分割する目安（どれかに当てはまれば分割を検討）:

• 独立した複数の成果物・機能領域を含む
• 1 つでは着手・レビューの単位として大きすぎる
• 部分ごとに独立して着手・検証できる（並行作業や段階的リリースが可能）

分割するときは、各 issue をそれ単体で着手・検証できる縦スライスにする（レイヤーを 横に割らない）。issue 間に順序依存があれば「依存（blocked by）」として明示する。 全体像が分かりにくくなる場合は、親（トラッキング）issue を立てて子をぶら下げることも検討する。 小さく単一目的のプランなら、無理に割らず 1 issue にする。

各 issue について、タイトル・本文（ISSUE.md の書式）・ラベル・依存関係・（あれば）担当を 組み立てる。元プランへの参照（ファイルパスやリンク）を本文に残すと追跡しやすい。

5. ユーザーに提示して承認を得る

作成予定の issue を番号付きの一覧で提示する。各項目に最低限:

• タイトル
• 種別/ラベル
• 依存（blocked by）— 分割した場合
• 本文の要点（数行で）

そのうえで「この粒度・分割・依存で作成してよいか」を確認する。粒度が粗い/細かい、 依存が違う、統合/分割すべき、という指摘があれば直してから次へ進む。

（ユーザーが事前に「確認は不要、そのまま作成して」と明示している場合は、この承認を 省いてよい。）

6. GitHub に issue を作成する

承認後、gh issue create で作成する。本文は日本語や複数行を安全に渡すため、一時ファイルに 書いて --body-file で渡すか、ヒアドキュメントで --body-file - に流す。

gh issue create --title "<タイトル>" --body-file <本文ファイル> \
  --label "<ラベル>"   # ISSUE.md に従う。担当やマイルストーンがあれば --assignee / --milestone

• 分割した場合は**依存順（blocker から先）**に作成する。先に作った issue の番号/URL を、 後続 issue の「依存」欄に実際の値で埋め込めるようにするため。
• 作成のたびに返る issue の URL を控える。

7. 元のプランファイルを done へ移動する

issue の作成がすべて成功したら、起点にしたプランファイルを docs/plans/done/ 配下へ 移動する。これは「issue 化が済んだプラン」と「まだ着手していないプラン」を見分けやすく するため。

• 移動先: docs/plans/done/{元のファイル名}。docs/plans/done/ が無ければ作成する。
• ファイルが Git 管理下なら git mv を使い、移動が履歴に残るようにする （未追跡なら通常の移動でよい）。
• issue 作成が一部でも失敗した場合は移動しない（未完了のプランを done に紛れ込ませない）。 その場合は何が成功し何が失敗したかを伝える。

8. 完了報告

作成した issue を、タイトルと URL の一覧で報告する。分割した場合は依存関係も添える。 親 issue を立てた場合はそのリンクも示す。最後に、プランファイルを docs/plans/done/ へ 移動したことも一言添える。

---

デフォルトの issue 書式

docs/ISSUE.md が存在しない場合に使う標準テンプレート。

## 概要
{この issue で何を実現するか}

## やること
- {着手内容を箇条書きで（レイヤー別の手順ではなく、達成すべき振る舞い）}

## 受け入れ条件
- [ ] {完了と判断できる条件}
- [ ] ...

## 依存
- {先に完了が必要な issue への参照。無ければ「なし（すぐ着手可）」}

## 参照
- 元プラン: {プランファイルのパス}