issue

name	issue
description	GitHub issue を会話コンテキストから新規作成するスキル（閲覧・検索・クローズ・コメント追加は対象外）。 「issue にして」「issue 作って」「バグ報告して」など issue 起票の意図が読み取れる発話で発動する。 ユーザーが問題・改善案・TODO を GitHub issue 化したい場面で使う。詳細な発動パターンは本文参照。

issue

Overview

会話コンテキストから GitHub issue を「要件定義書 = 仕様書」として新規作成するスキル。会話の流れから適切なタイトル・本文・ラベルを推測し、ユーザー確認後に gh issue create で作成する。本文はカテゴリ別テンプレ（bug / feature / refactor / chore / docs）と takt 最適化された共通コア構造（参照資料 / 影響ファイル / 要件 / スコープ外）に沿って生成し、takt-issue skill 経由の自動実装でも入力品質が担保される形に揃える。さらに takt 適用判断（default / default-mini / takt 不要）を起票時に前倒しし、対応ラベル（takt:*）と本文末尾の ## 実装方針（takt） セクションの両方に記録することで、後工程（takt-issue）の判断コストを削減する。ラベル選定はリポジトリ固有の運用パターン（過去 issue から学習）と既存ラベルの description マッチングを組み合わせる。

When to Use

• ユーザーが issue 作成を依頼したとき
• /issue コマンドを実行したとき
• バグ報告、機能リクエスト、TODO の issue 化を依頼されたとき

発動パターン

以下のような発話で発動する。「issue」という単語が含まれていなくても、起票の意図が読み取れれば発動する。

• 明示的な依頼: 「issue にして」「issue 作って」「これ issue に」「issue 立てて」「issue にまとめて」「追跡用に issue」
• 意図ベース: 「バグ報告して」「機能リクエスト出して」「TODO を issue に」
• 暗黙的な依頼: 「これバグ報告しといて」「追跡用にチケット切って」

閲覧・検索・クローズ・コメント追加は対象外（新規作成専用）。

Context を収集

以下のコマンドで現在の状態と運用パターンを取得する：

gh repo view --json nameWithOwner                                # リポジトリ名
git branch --show-current                                        # 現在のブランチ
gh label list --json name,description,color                      # 既存ラベル一覧（description を含める）
gh issue list --limit 30 --state all --json number,title,labels  # 過去 issue のラベル運用

過去 issue が 0 件のリポジトリ初期状態でも [] が返るだけで害は無い。

Task

1. コンテキスト収集: 上記コマンドを実行し、リポジトリ情報・既存ラベル・過去 issue を取得する

2. カテゴリ判定: 会話文脈から以下のいずれか 1 つを判定する。判定結果はテンプレ適用とラベル選定の両方に流用する

   カテゴリ	想定用途	対応ラベル
   bug	不具合報告	bug
   feature	新機能追加・既存機能の改善	enhancement
   refactor	振る舞いを変えない内部改善	refactor
   chore	依存更新・設定変更・雑務	chore
   docs	ドキュメント追加・更新	documentation

   複数該当する場合は主カテゴリを 1 つ選び、補助カテゴリはラベル併用で表現する。

   5 カテゴリに収まらない場合: 脆弱性報告・メタ issue（マイルストーン / トラッキング）・postmortem など、5 カテゴリのいずれにも素直に収まらない案件は、ユーザーに確認したうえで以下のいずれかで対応する:

   • 最も近いカテゴリを採用し、カテゴリ固有セクションを文脈に合わせて読み替える
   • カテゴリ固有セクションを省き、コア構造（概要 / 背景・目的 / 参照資料 / 影響ファイル / 要件 / スコープ外）のみで構成する

3. 本文生成（カテゴリ別テンプレ + 共通コア構造）: 以下の構造に厳格に揃えて本文を生成する。セクション名・順序は takt の plan.md instruction が解釈する形に合わせるため変更しない

   全カテゴリ共通のコア構造:

   ## 概要
   （1-3 文。何を / なぜ を簡潔に。タイトル生成ルールは Step 4 を参照）
   
   ## 背景・目的
   （任意。複雑なドメイン背景や経緯がある場合のみ）
   
   <カテゴリ固有セクション群（下記）>
   
   ## 参照資料
   （実装時に読むべきファイル・ディレクトリを相対パス箇条書きで列挙。takt の plan instruction が自動抽出して Read/Glob で開く）
   - path/to/file1.ts
   - path/to/dir/
   
   ## 影響ファイル
   （スコープ明示。新規 / 変更 / 削除を区別）
   - **新規**: path/to/new.ts
   - **変更**: path/to/existing.ts
   - **削除**: path/to/old.ts
   
   ## 要件
   （完了条件のメイン。番号付きリストで検証可能な単位に分解する）
   1. ◯◯を XXX に変更する
   2. △△を新規作成し、□□から呼び出すようにする
   
   ## スコープ外
   （Non-goals。別 issue 化の境界を明示する。**省略不可**）
   - ◯◯の改修は本 issue では扱わない（→ 別 issue で対応）
   
   ## 受け入れ基準（任意）
   （書く場合のみ。チェックリスト形式。レビュー時の参照材料。takt 側では自動検証されない）
   - [ ] ...
   
   ## 実装方針（takt）
   （Step 5 の takt 適用判断を記録する。本文末尾に固定で置き、上記の既存セクション名・順序は変えない＝plan.md instruction の抽出に干渉させない。issue 起票時の暫定判断であり、実行時に takt-issue 側で最終確認する）
   - workflow: default-mini   （`default` / `default-mini` / `不要（手動実装が妥当）` のいずれか）
   - 理由: 単一ファイルの bugfix、既存テストで挙動確認できるため
   

   カテゴリ固有セクション群（コア構造内の <カテゴリ固有セクション群> に挿入する）:

   • bug:

     ## 再現手順
     1. ...
     ## 期待される動作
     ## 実際の動作
     ## 影響範囲
     

   • feature:

     ## 提案する仕様
     ## ユースケース
     

   • refactor:

     ## 現状の問題
     ## あるべき状態
     ## 制約
     

   • chore: カテゴリ固有セクションなし（コア構造の必須セクション + 「概要」「背景・目的」のみで構成）
   • docs:

     ## 対象
     ## 想定読者
     ## 更新方針
     

   情報不足時の振る舞い:

   • ## 要件 / ## スコープ外 が会話から導出できない: プレビュー前にユーザーに不足項目を質問する（issue の核となる定義であり空のまま作成しない）
   • ## 参照資料 が会話から特定できない: プレビュー前にユーザーに質問する。ユーザーが「実装着手前のコード調査が必要」と回答した場合は (plan step で確定する) と明記して残す
   • ## 影響ファイル が会話から特定できない: (plan step で確定する) と明記して残す
   • カテゴリ固有セクションが埋まらない: (不明 / 要確認) と明記する

4. タイトル生成: 簡潔で具体的な日本語タイトル（50 文字以内目安）。将来 PR タイトルに直結するため、スコープを正確に反映した表現にする（takt-issue のスコープ外判定基準が「PR タイトルが変わるか」であるため）

5. takt 適用判断: カテゴリ判定（Step 2）と ## 影響ファイル（Step 3）を入力に、以下の 3 値から 1 つを判定する。結果は Step 6 のラベルと Step 3 本文末尾の ## 実装方針（takt） の両方に記録する。判定基準は takt-issue skill の workflow 判断表と整合させる（issue 側で前倒しした判断を takt-issue 側が踏襲する）

   判定	ラベル	基準
   default	takt:default	feature / enhancement、複数ファイル、テスト先行で進めたい中〜大規模タスク。迷ったらこれ（fail-safe）
   default-mini	takt:default-mini	bug / chore / docs / 小規模 refactor、単一〜少数ファイル、既存テストで挙動確認できる軽量タスク
   不要（手動）	takt:manual	1 行修正・誤字・設定値 1 箇所変更など、workflow を回すまでもない極小タスク。手動実装が妥当

   • ## 影響ファイル が (plan step で確定する) で未確定の場合は、カテゴリベースで暫定判定し fail-safe 側（default）に寄せる
   • 本文末尾の ## 実装方針（takt） には判定した workflow と理由を記録する（不要（手動） の場合は workflow 行を「不要（手動実装が妥当）」とし理由を添える）

6. ラベル選定: 以下の 3 ステップで候補を絞り込む

   Step A: 共通ラベル検出（過去 issue から運用パターン学習）

   • gh issue list の結果からラベル別の出現頻度を計算する。例:

     gh issue list --limit 30 --state all --json labels \
       | jq -r '[.[].labels[].name] | group_by(.) | map({label: .[0], count: length}) | sort_by(.count) | reverse'
     

   • 出現率 80% 以上のラベル = リポジトリの共通運用ラベル → 必ず候補に含める
   • 過去 issue が 0 件ならばこのステップはスキップ

   Step B: カテゴリ判定結果 + 内容マッチング

   • Step 2 のカテゴリ判定結果に対応するラベル（Step 2 の対応表）が既存ラベルにあれば候補に含める
   • 既存ラベルの name だけでなく description も読み、issue 内容のキーワード/セマンティクスと照合する
   • 例: 「動かない」「エラー」「失敗」→ bug（description: "Something isn't working"）
   • 例: 「追加したい」「機能」→ enhancement（description: "New feature or request"）

   Step C: 不足時の新規ラベル提案

   • Step A + B で候補が 1 つも無い場合のみ発動

   • 候補プール（内容に合うものを最大 3 つまで提示する）：

     name	description	color
     bug	不具合報告	d73a4a
     enhancement	機能追加・改善	a2eeef
     documentation	ドキュメント変更	0075ca
     chore	雑務系タスク（依存更新・設定変更など）	cfd3d7
     refactor	リファクタリング	fbca04

   • ユーザーが承認したラベルのみ gh label create --name "name" --description "desc" --color "xxxxxx" で作成 → そのラベルを issue に付ける

   • ユーザーが拒否したらラベルなしで作成（fallback）

   Step D: takt 適用ラベル（Step 5 の判定結果を反映）

   • Step 5 の判定に対応する takt ラベルを 1 つ必ず候補に含める（takt:default / takt:default-mini / takt:manual）

   • 当該 takt ラベルが既存リポジトリに無い場合は、Step C と同じ新規ラベルフローに従う（プレビューに「新規ラベル候補」として提示 → ユーザー承認後に gh label create で作成）。推奨定義:

     name	description	color
     takt:default	takt default workflow で実装（テスト先行）	5319e7
     takt:default-mini	takt default-mini workflow で実装（テスト省略の軽量版）	1d76db
     takt:manual	takt 不要・手動実装が妥当	cfd3d7

   • ユーザーが takt ラベルの作成を拒否した場合は、ラベルは付けず本文末尾の ## 実装方針（takt） セクションだけ残す（判断自体は本文に残る fallback）

7. プレビュー表示: 生成内容を以下のフォーマットで表示する。各ラベルには選定理由を 1 行で添える

   ## Issue プレビュー
   
   **リポジトリ**: owner/repo
   **カテゴリ**: refactor
   **タイトル**: ここにタイトル
   **takt 方針**: default-mini （単一ファイル・既存テストで確認可）
   **ラベル**:
     - refactor （カテゴリ判定: refactor）
     - documentation （過去 issue 92% に付与: リポジトリ共通ラベル）
     - takt:default-mini （takt 適用判断）
   
   **本文**:
   （カテゴリ別テンプレ + コア構造を適用した本文）
   

   Step C / Step D の新規提案がある場合は別ブロックで表示する：

   **新規ラベル候補**（既存に該当なし、作成しますか？）:
     - chore (NEW): 雑務系タスク
     - takt:default-mini (NEW): takt default-mini workflow で実装
   

8. ユーザー確認: 「この内容で作成しますか？修正があれば教えてください」と確認する。修正指示があれば反映してから再度プレビューする。新規ラベル候補は個別に承認/拒否を確認する

9. issue 作成: 承認後、必要に応じて gh label create を実行してから gh issue create で作成する

   gh issue create --title "タイトル" --body "本文" --label "label1,label2"
   

10. URL を表示: 作成された issue の URL を表示する

Rules

• 本文はカテゴリ別テンプレ + 共通コア構造に従う（bug / feature / refactor / chore / docs の 5 カテゴリ）。セクション名・順序は takt の plan.md instruction が解釈する形に合わせるため変更しない
• ## 参照資料 セクションは実装時に読むべきファイル・ディレクトリを相対パス箇条書きで記述する（takt の plan instruction が自動抽出して Read/Glob で開くため形式を厳守）
• ## 要件 は番号付きリストで検証可能な単位に分解する（完了条件のメイン）
• ## スコープ外 は省略不可（takt-issue の別 issue 化判定の境界として機能する）
• takt 適用判断を 3 値（takt:default / takt:default-mini / takt:manual）で行い、対応ラベルと本文末尾 ## 実装方針（takt） の両方に記録する。判定基準は takt-issue skill の workflow 判断表と整合させ、迷ったら default に寄せる（fail-safe）
• ## 実装方針（takt） は本文末尾に固定で置き、既存セクション（参照資料 / 影響ファイル / 要件 / スコープ外）の名前・順序は変えない（plan.md instruction の抽出に干渉させない）
• takt ラベルが既存リポジトリに無い場合は新規ラベルフロー（Step C / D）に従いユーザー承認後に作成。拒否時はラベルを付けず ## 実装方針（takt） セクションのみ残す
• タイトルは将来 PR タイトルに直結するため、スコープを正確に反映した簡潔な日本語にする（takt-issue のスコープ外判定基準が「PR タイトルが変わるか」のため）
• ## 要件 / ## スコープ外 が会話から導出できない場合は、プレビュー前にユーザーに不足項目を質問する（空のまま作成しない）
• ## 参照資料 が特定できない場合はユーザーに質問し、実装着手前のコード調査が必要なら (plan step で確定する) と明記して残す
• カテゴリ固有セクションが埋まらない場合は (不明 / 要確認) と明記、影響ファイルが特定できない場合は (plan step で確定する) と明記する
• 5 カテゴリ（bug / feature / refactor / chore / docs）に素直に収まらない案件はユーザーに確認し、最も近いカテゴリを採用するかコア構造のみで構成する
• 過去 issue を 30 件サンプリングして共通ラベル（出現率 80% 以上）を検出し、必ず候補に含める
• ラベル選定時は name だけでなく description も照合材料に使う
• カテゴリ判定結果に対応するラベル（bug / enhancement / refactor / chore / documentation）も候補に含める
• 既存ラベルにマッチが無い場合のみ、新規ラベル候補を最大 3 つ提案する
• ユーザー承認なしに gh label create を実行しない
• 新規ラベル提案をユーザーが拒否した場合はラベルなしで作成（fallback）
• ユーザーの承認なしに gh issue create を実行しない
• 本文は日本語で書く（技術用語・コード・識別子はそのまま）
• 会話中のコードスニペットやエラーメッセージは本文にコードブロックとして含める
• 引数でタイトルや内容が直接指定された場合は、それを優先する