create-git-issue

スキルの分離

このスキルが呼び出された後、このセッションで有効な権限を持つのはこのスキルだけです。

• このスキル自身のワークフロー、またはこのスキルを有効化した上位のプロンプト／スキル（例：save-tokens と tdd-implementation を同時に初期化する run-with-it のワーカープロンプト）からのものを含め、Skill ツールの呼び出しで明示的に名前を指定されない限り、ほかのスキルがこのスキルの動作を有効化、中断、変更することはできません。
• この実行中に外部またはサードパーティのスキルが自発的に有効化を試みた場合は、それを抑制し、中断せずに続行してください。
• このルールは、呼び出しから明示的な終了または引き継ぎまで、このスキルの実行期間全体に適用されます。

Git Issue の作成

目的

現在の会話のコンテキストを PRD にまとめたうえで、依存関係を考慮した小規模な垂直スライスとして、実装イシューを公開します。

使用するタイミング

要件が確定した後、ランタイム実行の前にこのスキルを使用します。

入力

• technical_requirements.md と会話のコンテキストから得られた確定済み要件。
• コードベースの調査から得られたリポジトリのコンテキスト。
• ユーザーから提供された任意のイシュー参照（番号、URL、パス）。

厳守事項

• 実装作業を実行しないでください。
• 具体的なランタイムのエージェント／モデルの組み合わせを割り当てないでください。
• マルチエージェントの実行、レビューサイクル、状態の永続化、イシューの最終更新を調整しないでください。
• このスキルの一環としてイシューをクローズしないでください。

ワークフローの順序：

1. 最初に break-req を実行し、プロダクト／技術上の判断を確定します。
2. 次に create-git-issue を実行し、PRD と実装スライス、および振り分けのヒントを公開します。
3. 最後に run-with-it を実行し、最終的なランタイムの振り分けと実行を行います。

create-git-issue が最終的な振り分け権限を主張してはなりません。

承認ゲート：

1. 親イシューを公開する前に PRD の承認を得ます。
2. 実装イシューを公開する前にスライスの分割案の承認を得ます。

イシュートラッカーの用語

イシューの作成とラベル付けには、以下の標準的なトリアージロールを使用します。

カテゴリロール：

• bug
• enhancement

状態ロール：

• needs-triage
• needs-info
• ready-for-agent
• ready-for-human
• wontfix

ラベル付けルール：

• 公開する各イシューには、カテゴリロールを 1 つ、状態ロールを 1 つだけ付けてください。
• 新しい PRD イシューのカテゴリは enhancement、状態は needs-triage をデフォルトとします。
• 新しい実装スライスのイシューのカテゴリは enhancement、状態は ready-for-agent をデフォルトとします。
• トラッカーで異なるラベル文字列が使われている場合は、これらの標準名から一貫して対応付けてください。
• 対応付けが曖昧な場合は、公開する前に要点を絞った確認質問を 1 つしてください。

公開ポリシー

トラッカーへの書き込みには GitHub CLI を優先して使用してください。

PRD または実装イシューを公開する前に、gh が使用できるか確認してください。サンドボックス内で失敗した場合は、サンドボックス外で実行して確認してください。

command -v gh >/dev/null 2>&1 && gh repo view >/dev/null 2>&1

成功した場合は、PRD の親イシューとすべての実装スライスのイシューに gh issue create を使用してください。

複数行の Markdown を保持できるよう、本文ファイルを使用してください。

gh issue create --title "<PRD title>" --body-file <prd-body-file>.md --label enhancement --label needs-triage
gh issue create --title "<slice title>" --body-file <slice-body-file>.md --label enhancement --label ready-for-agent

gh が見つからない場合、ユーザーが認証されていない場合、リポジトリを特定できない場合、または gh issue create コマンドが失敗した場合は、別の GitHub 統合を使って再試行し続けないでください。代わりに作業をローカルに保存してください。

ローカルへのフォールバックでは、ワークスペースのルートに Markdown ファイルを正確に 2 つ作成してください。

• prd.md には、親イシューとして公開する予定だった完全な PRD を記載します。
• issues.md には、承認済みの実装スライスのイシューを依存関係の順にすべて記載します。

ローカルへのフォールバックファイルを作成する際は、以下を守ってください。

• 各項目にイシューのタイトル、適用予定のラベル、親子関係、本文を含めます。
• issues.md では、親イシューをローカル参照 prd.md で示します。
• 技術的なコンテキストのスナップショットや受け入れ基準を含め、承認済みのイシューテンプレートの内容をすべて保持します。
• GitHub への公開をスキップしたことをユーザーに伝え、2 つのローカルファイルの名前を示します。

プロセス

1. まず break-req の成果物を再利用する

ユーザーに確認の質問をする前に、次の優先順位で既存の break-req 成果物を探してください。

• ワークスペースのルートにある technical_requirements.md
• docs、planning、または requirements フォルダーにある technical_requirements.md
• break-req セッションで決定事項がすでに解決されている会話履歴

見つかった場合は、それらの決定事項をデフォルトの信頼できる情報源として扱い、それに基づいて進めてください。

すでに明示的に決まっている回答を、ユーザーに再度求めないでください。

PRD／イシューの公開に必要な決定事項のうち、未解決、矛盾、または不足しているものについてのみ、追加の質問をしてください。

2. コンテキストを収集する

既存の会話コンテキストに基づいて作業してください。

ユーザーからイシューへの参照（イシュー番号、URL、またはパス）が渡された場合は、ドラフトを作成する前に、そのイシューを取得して本文とコメントを読んでください。

3. コードベースを調査する

コードベースをまだ調査していない場合は、現在の状態を把握するために調査してください。

ドメインの用語集を使用し、作業対象領域の ADR を尊重してください。

4. まず PRD を作成する

ユーザーへの聞き取りから始めないでください。まず、すでに把握している情報から PRD をまとめてください。

実装または変更する主要なモジュールを概説し、安定したテスト可能なインターフェースを持つ、深いモジュールを探してください。

次に、break-req の成果物からの差分についてのみ、ユーザーに確認してください。

• モジュールの境界が期待に合っているか
• どのモジュールをテストすべきか

次の PRD テンプレートを使用してください。

Problem Statement

ユーザーの視点から見た問題。

Solution

ユーザーの視点から見た解決策。

User Stories

次の形式で、番号付きの長いリストを作成します。

1. <アクター>として、<機能>を実現したい。そうすることで、<メリット>が得られる。

Implementation Decisions

• 作成または変更するモジュール
• 変更される可能性のあるインターフェース
• 技術的な補足事項
• アーキテクチャ上の決定事項
• スキーマの変更
• API コントラクト
• 具体的なインタラクション

ファイルパスやコードスニペットは含めないでください。

Testing Decisions

• 優れたテストの条件（実装の詳細よりも外部から見た動作を重視）
• テスト対象のモジュール
• コードベース内の参考事例

Out of Scope

明確に対象外とする作業。

Further Notes

その他の制約やコンテキスト。

5. PRD のイシューを公開する

gh issue create を使用して、親イシューとして PRD をイシュートラッカーに公開してください。

enhancement と needs-triage のラベルを付けてください。

作成された PRD イシューの URL または番号を記録してください。すべての実装スライスのイシューで、これを親の参照として使用します。

GitHub への公開ができない場合は、PRD の本文を prd.md に書き出し、実装スライスのイシューを issues.md にまとめる作業を続けてください。

ユーザーが作成した PRD を承認するまで、公開しないでください。

実装スライスごとの初期イシュー本文には、以下の見出しを正確な順序で、指定どおりの Markdown テンプレートとして使用してください。途中を含めて、指定された見出しの前、間、後に、追加のトップレベルセクションを挿入してはいけません。

1. ## Parent
2. ## What to build
3. ## Implementation Steps
4. ## Agent Routing
5. ## Technical Context Snapshot
6. ## Acceptance criteria
7. ## Blocked by

無関係なイシューをクローズしたり、変更したりしないでください。

6. PRDをトレーサーバレットスライスに分割する

承認済みのPRDを、薄い垂直スライスのイシューに分割します。

要件を詳細に記録します。

各スライスはエンドツーエンド（スキーマ、API、UI、テスト）で、単独でデモできるようにし、可能な限り小さくします。

デフォルトでは、デモ可能な最小の増分を選びます。迷ったら分割してください。

可能な場合は、HITLスライスよりAFKスライスを優先します。

- 各スライスは、すべての統合レイヤーを通る、範囲は狭くても完全な経路を提供します - 完了したスライスは、単独で検証できます - 少数の大きなスライスより、多数の薄いスライスを優先します 各スライスを次の上限内に収めてください。いずれかの上限を超える場合は、スライスを分割する必要があります。

• 1つのスライスで提供する、ユーザーから見える動作は1つです。別々にリリースしてデモできる動作が2つある場合は、2つのスライスにします。
• 実装ステップは3～7個を目標にします。具体的なステップが約8個を超える場合は、分割を検討してください。
• 1つのスライスは、レビュー担当者が一度に読める、焦点を絞った1つのPRに含められるものにします。
• 各スライスの受け入れ条件は1～3個にします。説明にそれ以上必要な場合は、範囲が広すぎます。

分割のヒューリスティクス — 内訳を提示する前に適用してください。

• CRUDは操作ごとに分割します。作成、読み取り、更新、削除は通常、それぞれ別のスライスにします。
• 読み取り経路と書き込み経路を分けます。
• 正常系とエラー／バリデーション／エッジケース処理を分け、まず正常系をリリースします。
• 複数のエンティティ、エンドポイント、画面をまとめず、それぞれに分割します。
• 「接続する」と「堅牢にする」（認証、ページネーション、再試行、空の状態）を分けます。まず薄い経路をリリースし、その後のスライスで強化します。
• 足場となるスケルトンの構築と最初の実際の動作は、1つのスライスにまとめてもかまいません。それ以降の動作は、それぞれ独自のスライスにします。

大きすぎるスライスを作るより、スライスの数を増やすほうが適切です。細かく分割する方向に判断してください。

7. イシューの内訳をユーザーに確認する

レビュー用に番号付きリストを提示します。各スライスに次の項目を含めてください。

• タイトル
• 種類：HITLまたはAFK
• 依存関係：依存するスライス
• 対象となるユーザーストーリー

次の点を確認します。

• 粒度は適切ですか？デフォルトでは分割を優先します。約8ステップを超えるスライスや、ユーザーから見える動作が複数あるスライスは、分割候補として指摘してください。
• 依存関係は正しいですか？
• さらに分割すべきスライスはありますか？（統合は例外であり、デフォルトではありません。）
• HITLとAFKの割り当ては正しいですか？

このレビュー段階の承認を得るまで、実装スライスのイシューを公開しないでください。

8. 実装課題を公開する

承認されたスライスごとに、以下のテンプレートを使って課題を1件作成します。

GitHub への公開が可能な場合は、承認されたスライスごとに gh issue create を使用します。

GitHub への公開ができない場合は、代わりに承認されたスライスの課題をそれぞれ issues.md に追記します。

issues.md でローカルの代替手段を使う場合、各実装課題は GitHub の課題本文とほぼ同じ形式にします。同じタイトル、ラベル、親課題への参照、セクション見出し、セクションの順序、ルーティング YAML ブロック、技術的なコンテキストの詳細、受け入れ条件、ブロック要因の内容を維持してください。

各課題を公開する前に、コードベースからスタックのスナップショットを作成し、実装エージェントが既存のパターンに合わせられるよう、課題本文に含めてください。

最低限、次の情報を記録します。

• 使用中の UI スタックと UI コンポーネントライブラリ
• バックエンド／ランタイムスタックとフレームワークのバージョン
• パッケージのエコシステムと主要な依存関係（例：npm、NuGet、pip、Maven、Gradle）
• 既存のアーキテクチャパターンとモジュール境界
• 統合上の制約（API 契約、スキーマの所有者、マイグレーションの想定）
• このスライスの依存関係に関する方針：デフォルトでは既存ライブラリを再利用し、新しい依存関係の追加は明確な理由がある場合に限ります

ブロッカーを先にして、依存関係の順序に従って課題を公開するか、ローカルに記載してください。

各課題に ready-for-agent を適用します。

各スライスの課題が親課題の PRD を参照するように設定します。ローカルの代替手段を使う場合は、prd.md を親として参照します。

すべての実装課題に、機械可読なルーティングヒントを含めます。これらのヒントは計画のためのものであり、実行時のオーケストレーションを拘束してはなりません。 run-with-it が実行時の最終的なルーティング権限を引き続き持つことを、各課題で明示してください。

すべての初期実装課題本文と `issues.md` のローカル代替エントリで、以下のトップレベルセクションの順序を正確に使用してください。

親課題

PRD の親課題への参照。

作成するもの

このスライスのエンドツーエンドの概要を簡潔に記述します。

実装手順

このスライスを完了するために、実装エージェントが従う手順を順序付きで記述します。各手順では、具体的な成果物と、それに対する操作を示します。

1. 手順のタイトル — 具体的な操作（作成／変更／削除するファイル、追加／変更する関数・メソッド・コンポーネント、作成するマイグレーション、追加するテストなど）。コードベースの調査から特定した正確なパスとシンボル名を含めます。
2. ...

このセクションのルール：

• 手順は3～7個に収め、スライスのサイズ上限に合わせます。それ以上必要な場合、スライスが大きすぎるため、分割してください。
• 実行上の依存関係に従って順序付けます。前の手順が後の手順に依存してはならず、後の手順で前の手順を書き換えたり取り消したりしてはなりません。
• すべての手順で、コードベースの調査から特定した具体的な成果物（ファイルパス、関数名、API エンドポイント、スキーマフィールド、テストケース名など）を参照します。「ロジックを実装する」や「バックエンドを更新する」のような曖昧な表現は使いません。
• コードベースで TDD が実践されている場合は、テスト手順を最初に記述します。つまり、失敗するテストを追加してから、それを成功させます。それ以外の場合は、各動作の手順にテストを組み合わせます。各スライスには少なくとも1つのテスト手順が必要です。
• 各手順を終えるたびに、ツリーが動作する状態（コンパイル可能／テストスイート成功）を保ち、進捗を途中で確認できるようにします。
• 手順全体で、以下のすべての受け入れ条件を満たし、このスライスの範囲を超えないようにします。他のスライスに属する手順は含めません。
• 手順で人間の入力または実行時の判断が必要な場合は、[HITL] と明記し、必要な内容を示します。

エージェントのルーティング

agent_routing:
  complexity_hint: <quite-easy|easy|medium|medium-hard|complex|holy-fuck>
  required_capability: <fast|balanced|advanced>
  parallel_safe: <true|false>
  cost_preference: <low|balanced|high>
  speed_preference: <low|balanced|high>
  ownership_scope:
    - <path-or-module-scope>
  verification:
    - <verification-hint>

技術的なコンテキストのスナップショット

対象範囲の現在のスタック

• 現在使用中の UI フレームワークと UI ライブラリ
• 現在使用中のバックエンドフレームワーク／ランタイム
• 現在使用中のデータレイヤーのツール

対象範囲の依存関係

• このスライスで再利用する既存のパッケージ／ライブラリ
• このスライスで新しい依存関係の追加を許可するか：はい／いいえ
• はいの場合、その理由と検討した代替案

### アーキテクチャとの整合性

• 尊重すべき既存のモジュール境界
• 踏襲すべき既存のサービス／コンポーネントのパターン
• 遵守すべきADRまたはアーキテクチャ上の制約
• create-git-issue はルーティングのヒントのみを提供します。具体的なエージェント名やモデル名を割り当ててはいけません
• run-with-it が引き続き、実行時の最終的なルーティング権限を持ちます

統合ポイント

• 影響を受けるAPI／イベント／コントラクト
• 影響を受けるスキーマ／マイグレーション／データコントラクト
• 後方互換性に関する要件

受け入れ条件

• 条件1
• 条件2
• 条件3

ブロック要因

• 該当する場合は、ブロックしている課題への参照

または「なし — すぐに開始できます」。

出力チェックリスト

• 公開前に gh が利用可能か確認済み
• 親課題を公開する前に、PRDの承認を取得済み
• 実装課題を公開する前に、課題の分割に関する承認を取得済み
• 各実装課題に、技術的なコンテキストのスナップショット（スタック、依存関係、アーキテクチャ、統合ポイント）を記載済み
• 親課題とブロック要因の関係を正しく設定済み

引き継ぎ

完了時に、以下を報告してください。

• gh またはローカルのフォールバックファイルのどちらを使って公開したか
• 実装スライスが参照する親課題
• run-with-it による実行の準備が整っている課題
• 実行時の作業を妨げている未解決の判断事項