fusion-issue-authoring

イシューの作成

エージェントモード

このスキルでは、イシューの種類に応じたドラフト作成ロジックに、内部エージェントモードを使用します。

• agents/bug.agent.md：バグに特化したイシューの作成とトリアージの構成
• agents/feature.agent.md：機能に特化したスコープと受け入れ条件の構成
• agents/user-story.agent.md：役割／ワークフロー／シナリオに基づくストーリーの構成
• agents/task.agent.md：チェックリストを優先したタスク分解と依存関係の計画
• agents/devils-advocate.agent.md：分類後に重要な懸念を提起する（モデレートモード）常時有効の品質協力エージェント。明示的に依頼された場合、スコープや基準に重大な不足がある場合、またはアーキテクチャの曖昧さを示す要素が2つ以上ある状態で fusion-issue-task-planning から呼び出された場合に、構造化された詳細な聞き取りを実施します（インタロゲーターモード）。

エージェントモードは、イシューの種類の分類に基づいて内部で有効になります。ユーザーがエージェントファイルを直接参照することはありません。共有ゲート（ラベル、担当者の確認、ドラフトのレビュー、公開の確認、変更の順序付け）は、このスキル内で引き続き適用されます。

使用する場面

アイデア、バグ、機能リクエスト、ユーザーニーズを、明確で実行可能な GitHub イシューにまとめる場合や、イシューの作成・更新における最上位のルーターとして使用します。

典型的なきっかけ：

• 「イシューを作成して」
• 「チケットのドラフトを書いて」
• 「これを GitHub イシューにまとめて」
• 「この作業項目の構成を手伝って」
• 「このイシューを更新／管理／整理して」
• 「これをサブイシューとして追加して／親イシューを設定して／子イシューとしてリンクして」

使用しない場面

• コード変更の実装
• PR の作成やレビュー
• イシューのドラフト作成につながらない一般的な調査
• ユーザーの明示的な確認なしに GitHub の状態を変更する場合

必要な入力

公開前に、以下を収集します。

• 対象リポジトリ
• イシューの目的／背景と種類（Bug、Feature、User Story、Task）
• 更新の場合は既存のイシュー番号／URL
• リポジトリのラベル一覧（またはラベルを意図的に省略する確認）。セッション中はリポジトリごとにラベル一覧全体をキャッシュし、ローカルで絞り込みます。ホストのセッションメモリを優先し、利用できない場合は .tmp/ のキャッシュファイルを使用します（コミットしないでください）。
• 親イシュー／関連イシューへのリンクと依存関係の方向（サブイシューか、ブロック関係か）
• 担当者の希望（@me、特定の人、または未割り当て）。キャッシュ済みの担当者候補の検索結果を再利用します。ユーザーが @me または正確なログイン名を指定した場合は検索を省略します。

必要な情報が不足している場合は、references/questions.md にある簡潔な確認質問をします。 イシューの作成先が不明確な場合は、変更コマンドのドラフトを作成する前に、どこにイシューを作成／更新するかを明示的に尋ねます。

手順

ステップ1 — 分類して振り分ける

リクエストを Bug、Feature、User Story、Task に分類し、対応するエージェントモードを有効にします。

• Bug -> agents/bug.agent.md
• Feature -> agents/feature.agent.md
• User Story -> agents/user-story.agent.md
• Task -> agents/task.agent.md

曖昧な場合は、必須の確認事項だけを尋ねます。

デビルズアドボケイトによる確認：agents/devils-advocate.agent.md はモデレートモードで常時有効になっており、進行を妨げずに、分類後に最も重要な懸念を2～3点提示します。ユーザーが「厳しく質問して」と依頼した場合、「ストレステストして」と言った場合、スコープや基準に重大な不足がある場合、またはアーキテクチャの曖昧さを示す要素が2つ以上ある状態で fusion-issue-task-planning から呼び出された場合は、インタロゲーターモードに切り替え、種類ごとのエージェントに引き継ぐ前に、構造化された詳細な聞き取りを実施します。デビルズアドボケイトは、確認済みの決定事項と記録されたリスクを返した後、種類ごとのドラフト作成エージェントに引き継ぎます。

ステップ2 — リポジトリとテンプレートを確定する

• 変更を行う前に、作成先のリポジトリを確定します。
• リポジトリが明示されていない場合は、現在のワークスペースで、種類ごとのイシューの振り分け先を定めたコントリビューターガイド（CONTRIBUTING.md、contribute/）を確認します。ユーザーに尋ねる前に、見つかった振り分けルールを適用します。
• リポジトリに振り分けの指針がない場合は、イシューの作成先を明示的に尋ねます。
• テンプレートの優先順位：
  1. リポジトリのテンプレート（.github/ISSUE_TEMPLATE/）
  2. 専門分野別の代替テンプレート

ステップ 3 — 重複を確認する

mcp_github::search_issues で焦点を絞った重複検索を 1 回実行し、下書きや公開の前に該当項目を提示します。 ユーザーがスコープやタイトルを大幅に変更しない限り、広範な重複検索を繰り返さないでください。

ステップ 4 — まず下書きを作成する

書き始める前に、ユーザーの設定とセッションメモリを確認し、希望する下書きの保存場所を調べます。保存された設定があれば、それを使用します。設定が見つからず、意図が曖昧な場合は、一度だけ質問し、回答をセッション中に記憶します。設定が見つからず、確認すべき点もない場合は、.tmp/{TYPE}-{CONTEXT}.md を既定の保存先とします。GitHub Flavored Markdown で下書きを作成します。

ステップ 5 — レビューして確認する

• まず、内容の編集が必要か尋ねます。
• 変更を加える前に、公開するかどうか明示的に確認します。
• ユーザーが明示的に確認しない限り、最初の下書きと同じ段階で公開や更新を行わないでください。

ステップ 6 — 共通の確認事項を適用する

変更を加える前に、次の項目を確認します。

• ラベル（対象リポジトリに存在するラベルのみ）
• 担当者の指定（@me、特定のログイン名、または未割り当て）

共通確認事項のキャッシュポリシー：

• owner/repo のラベルを初めて照会する際は、リポジトリのラベル一覧を 1 回取得し、アクティブなセッション中はキャッシュします。ホストがセッションメモリを提供している場合は /memories/session/<owner>-<repo>-labels.json を優先し、それ以外の場合は .tmp/issue-authoring-labels-<owner>-<repo>.json を使用します。
• キャッシュがある場合は、要求されたラベルをローカルで検証します。要求されたラベルごとに個別の照会を繰り返さないでください。
• ホストが個別ラベルの照会しか提供せず、ラベル一覧のキャッシュもまだない場合は、ラベルを 1 つずつ順に確認しないでください。任意のラベルを省略するか、ユーザーが確認したラベルのみを最初の mcp_github::issue_write 呼び出しに含めて、拒否された場合に 1 回だけ対処するかを尋ねます。
• ユーザーがすでに @me または正確な GitHub ログイン名を指定している場合は、mcp_github::search_users を呼び出さないでください。
• 担当者の照会が必要な場合は、アクティブなセッション中、owner/repo（または owner）と検索クエリをキーとして候補結果をキャッシュします。/memories/session/<owner>-<repo>-assignee-candidates.json または /memories/session/<owner>-assignee-candidates.json を優先し、それ以外の場合は .tmp/issue-authoring-assignee-candidates-<owner>-<repo>.json を使用します。
• レート制限により任意のラベルや担当者の補完ができない場合は、再試行を繰り返すのではなく、それらを省略して続行するか尋ねます。

ステップ 7 — MCP を介して変更を加える（順序厳守）

明示的な確認を得た後、次の順序で MCP による変更を実行します。

1. mcp_github::issue_write で、既知の全項目（title、body、およびサポートされている場合に限り labels、assignees、type）を指定して作成／更新します
2. ステップ 1 で必須フィールドが不明で、後から判明した場合に限り、任意の mcp_github::issue_write を 1 回だけ追加で実行します
3. 関係や順序の変更が要求された場合に限り、mcp_github::sub_issue_write を実行します
4. ブロッカー／ステータスに関するメモが明示的に要求された場合に限り、mcp_github::add_issue_comment を実行します

MCP サーバー／認証／設定の不足により変更に失敗した場合：

• 失敗の内容を明確に説明します
• references/mcp-server.md のセットアップ手順を案内します
• ユーザーがセットアップ完了を確認した後に再試行します

レート制限への対応：

• レート制限による失敗（API rate limit exceeded、secondary rate limit、GraphQL のクォータ超過）を検出し、明確に報告します。
• レート制限に達した場合は、必須でない照会を停止し、任意の情報補完を省略します。
• 下書きの成果物を保持し、再試行を繰り返さずに安全な再試行手順を提示します。
• 同等の機能を持つ MCP ツールがある場合は、場当たり的な gh api／GraphQL の再試行よりも MCP ツールを優先します。
• GraphQL にフォールバックする場合、変更には 1 回あたりセカンダリ制限のポイントを 5 消費し、照会は 1 ポイントを消費します。そのため、フィールドを 1 回の変更呼び出しにまとめ、変更呼び出しの間隔を少なくとも 1 秒空けます。
• リクエストを再試行する前に、retry-after と x-ratelimit-reset ヘッダーに従います。

type のルール：

• リポジトリでイシュータイプが設定されている場合に限り、type を使用します。
• 利用可能な場合は、組織ごとにキャッシュされたイシュータイプを使用します。
• mcp_github::list_issue_types は、キャッシュがない場合、またはキャッシュが無効な場合に限り呼び出します。
• イシュータイプがサポートされていない場合は、セッションの残りの間、type を省略します。

ステップ 8 — 関連付けを検証する

リンクする前に：

• 分解にはサブイシューを使用します
• 前提条件を表すにはサブイシューの順序を使用します
• 依存関係グラフに矛盾がないことを確認します

詳細な動作とペイロードの例は、references/instructions.md と references/mcp-server.md を参照してください。

保持すべきコア動作

• 分類を最初に行うワークフロー
• エージェントモードへのルーティングを行うワークフロー
• 下書きを最初に作成するワークフロー
• 重要なコンテキストが不足している場合の確認質問
• GitHub を変更する前の明示的な確認

詳細な作成ガイダンスは references/instructions.md を参照してください。 フォールバックテンプレートの場所：

• バグ：assets/issue-templates/bug.md
• 機能：assets/issue-templates/feature.md
• ユーザーストーリー：assets/issue-templates/user-story.md
• タスク：assets/issue-templates/task*.md

期待される出力

• 選択したエージェントモードのパス
• .tmp/ 配下の下書きイシューファイルのパス
• 使用したテンプレートのソース（リポジトリのテンプレートパスまたはフォールバックアセットパス）
• 提案するタイトル、本文の概要、ラベル
• イシュータイプの計画
• 依存関係の計画（順序＋提案するサブイシュー／ブロッキングリンク）
• 担当者の計画（割り当てる人、または明示的な未割り当ての判断）
• 公開／更新コマンドを実行する前の明示的なステータス：Awaiting user content approval
• 見つかった関連／重複イシューへのリンク
• 確認後に実行する正確な作成／更新コマンド
• 確認済みの変更後にのみ、作成／更新されたイシューの URL／番号
• リポジトリのテンプレートがない、または不十分な場合に提案するテンプレートの保守フォローアップ

安全性と制約

絶対に行わないこと：

• 明示的なユーザー確認なしに mcp_github::issue_write の作成／更新を実行する
• ユーザーが下書きの内容を正しいと確認する前に、イシューを公開／更新する
• ユーザーが GitHub への公開を望んでいると決めつける
• シークレット／認証情報を要求または公開する
• 明示的な確認なしに破壊的なコマンドを実行する

必ず行うこと：

• 下書きを簡潔で編集しやすい状態に保つ
• イシューの文章では、実装方法（HOW）よりも内容（WHAT）と理由（WHY）を優先する
• リポジトリ全体を含むイシュー参照を使用する（例：owner/repo#123）
• イシューをクローズする意図がある場合は、クローズキーワードを使用する（例：fixes owner/repo#123、resolves owner/repo#123、closes owner/repo#123）