publish-issues

Issue の公開

目の前にあるもの――この会話、仕様、またはユーザーがたった今説明したアイデア――を、リポジトリのトラッカーに登録するトレーサーバレット型 Issueのセットに変換します。それぞれの Issue には、作業をブロックする Issue を明記します。これは、triage の受信キューに対する送信側の機能です。

トラッカー操作については docs/agents/issue-tracker.md を、ラベル文字列については docs/agents/triage-labels.md を確認します。どちらかが見つからない場合は、その旨を伝えて configure-repo を提案してください。それまでの間、ローカルの .scratch/ ファイルに下書きを作成できますが、リモートトラッカーを使うには設定が必要です。

公開するすべての Issue の本文は、必ず次の行から始めます。

> *This issue was drafted by AI with `publish-issues`.*

この行は、triage がこれらの Issue をスキップするために読み取るマーカーでもあります。これらの Issue は最初からエージェント対応の状態にあるため、再度トリアージして実際の仕様に不完全な仕様を重ねてはいけません。

位置づけ

下書きを始める前に適切なスキルを選び、より包括的なスキルと作業を重複させないでください。

対象	使用するスキル	使用しないスキル
すくい上げ可能な作業として記録する会話／アイデア／仕様	publish-issues（このスキル）	—
トレース可能な requirements.md → design.md → tasks.md が必要な tier-2 機能	plan-tasks（既定では1 つの機能 Issueを公開）	publish-issues
評価が必要な未処理の Issue、または外部 PR	/triage — ユーザーが実行するスキル。ユーザーには実行するよう伝えてください	publish-issues

ユーザーがすでに仕様の 3 点セットをすべて作成している場合、plan-tasks は Requirements covered: の共通部分を含む1 つの機能 Issueを公開します。ここで計画タスクを再登録しないでください。publish-issues は、3 点セットを経ていない作業に使います。

プロセス

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

会話内にすでにある情報をもとに作業します。ユーザーが参照情報（仕様のパス、Issue 番号、URL など）を渡した場合は、まず本文とコメントをすべて読んでください。完了条件： ユーザーが渡した参照情報をすべて最後まで読み、登録対象の範囲を明示的な対象／対象外リストとして書き出していること。

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

まだ調査していない場合は、コードを調べ、タイトルと説明にプロジェクトのドメイン用語集（CONTEXT.md）を使い、対象領域の ADR を尊重してください。後続の作業を容易にするプレファクタリングを探します。「変更を容易にしてから、容易になった変更を行う」という考え方です。プレファクターは最初の Issue として独立させます。完了条件： スライスのタイトルに使われるドメイン名詞がすべて CONTEXT.md に記載されており、プレファクターが最初のスライスとして登録されているか、明示的に不要と判断されていること。

3. 垂直スライスを下書きする

作業をトレーサーバレット型の Issue に分割します。

• 各スライスは、すべてのレイヤー（スキーマ、API、UI、テスト）を通る、範囲が狭くても完全な経路を実装します。垂直スライスとし、1 つのレイヤーだけを扱う水平スライスにはしないでください。
• 完了したスライスは、それ単体でデモまたは検証が可能です。
• 各スライスは、新しいコンテキストウィンドウ 1 つに収まる規模にします。
• プレファクタリングがある場合は、最初のスライスとして順序付けます。

各スライスにブロック関係を付けます。つまり、着手前に完了していなければならない他のスライスを指定します。ブロッカーがないスライスはすぐに着手できます。

大規模なリファクタリングは例外です。 大規模なリファクタリングとは、カラム名の変更や共有シンボルの型変更など、コードベース全体に影響が波及する機械的な変更です。単一の編集によって何千もの呼び出し箇所が一度に壊れ、垂直スライスを 1 つも正常に完了できません。この場合は、拡張 → 移行 → 縮小の順に進めます。まず、新しい形式を古い形式と併存する形で追加し、何も壊れない状態にします。次に、影響範囲に合わせて（パッケージ単位、ディレクトリ単位など）バッチに分け、呼び出し箇所を移行します。各バッチは拡張作業にブロックされます。古い形式が残っているため、バッチから次のバッチへ進んでも CI はグリーンを保ちます。最後に、すべての移行バッチにブロックされる Issue で古い形式を削除します。バッチ単独ではグリーンを保てない場合は、それらを共通の統合ブランチにまとめ、すべてのバッチがブロックする最終的な統合・検証 Issue を設けます。グリーンが保証されるのは、その最終 Issue のみです。

完了条件： すべてのスライスが垂直スライス（または、正当な理由のあるリファクタリングバッチ）であり、それぞれにブロック関係が設定されていること。

4. ユーザーに確認する

分割案を番号付きリストで提示します。各スライスについて、タイトル、ブロックしているもの、実現すること（スライスによって実現するエンドツーエンドの動作）を示します。その後、次の点を尋ねます。

• 粒度は適切ですか。大きすぎますか、小さすぎますか。
• ブロック関係は正しいですか。各スライスは、本当に着手の妨げとなるスライスだけに依存していますか。
• 統合または分割すべきものはありますか。

ユーザーにしか判断できないほどスライスの内容が不明確な場合は、REQUIRED SUB-SKILL: clarify-decisions を使い、一度に1つずつ質問して内容を明確にしてから公開します。ユーザーが分割案を承認するまで繰り返します。**完了条件：**ユーザーがスライスとそのブロック関係を承認していること。

5. 公開する

承認されたスライスを、設定済みのトラッカーに**依存関係の順序（ブロッカーを先に）**で公開します。これにより、各スライスのブロック関係に実際の識別子を指定できます。スライスの内容はどのトラッカーでも同じです。異なるのはブロック関係の形式だけです。

• ローカルファイル → ローカルテンプレートを使い、.scratch/<feature-slug>/issues/<NN>-<slug>.md にスライスごとに1ファイル作成します。依存関係の順に 01 から番号を付けます。結合したファイルは作成しないでください。
• リモートトラッカー（github / gitlab / linear） → 依存関係の順にスライスごとに1件のイシューを作成します。docs/agents/issue-tracker.md に従い、プラットフォームにネイティブなサブイシュー機能やブロック関係がある場合はそれを使います。ない場合は、各イシューの「Blocked by」にブロックするイシューの識別子を記入します。

すぐに着手できるものにだけラベルを付けます。 ready-for-agent（docs/agents/triage-labels.md に記載された対応ラベル）は、自律型エージェントが今すぐイシューに着手できることを意味します。そのため、ブロッカーが未完了のスライスに付けてはいけません。そうすると、エージェントが完了できない作業を始めてしまいます。ラベルを付けるかどうかは、ブロック関係がトラッカーによって強制されているかという、観察可能な特性に基づいて判断します。

• ブロック関係が強制される場合 — トラッカーがブロック中のイシューを自動的に保留します（ネイティブな依存関係リンク、Linear の blocks 関係など）。すべてのスライスに ready-for-agent を付けます。ブロック関係がブロック中のスライスの着手を制御します。
• ブロック関係がテキストだけの場合 — 「Blocked by」が本文中の行にすぎず、それを強制する仕組みがない場合（GitHub Issues、ローカルファイルなど）、フロンティア（未完了のブロッカーがないスライス）だけに ready-for-agent を付けます。ブロックされている各スライスにはカテゴリラベルだけを付け、ブロッカーが完了したら各スライスを昇格させるようユーザーに伝えます。ラベル機能がない場合（ローカルの .scratch/ ファイルなど）は、テンプレートの Status フィールドで同じ2つの状態を表します。フロンティアには ready-for-agent、その先のスライスには blocked を設定します。

フロンティアに沿って作業します。 ブロッカーがすでに公開されているスライスを公開し、上記のルールに従ってラベルを付けます。単純な一連の依存関係の場合、上から順に進めます。親イシューをクローズしたり変更したりしないでください。 **完了条件：**承認されたすべてのスライスがトラッカー上に存在し、ブロック関係が設定され、すぐに着手できるスライスだけに ready-for-agent が付いていること。

—

このイシューは AI が publish-issues を使って作成しました。

実装すること： レイヤーごとの実装項目の一覧ではなく、ユーザーの視点から、このスライスによって実現するエンドツーエンドの動作を記載します。

Blocked by： このスライスの着手を妨げる番号／タイトル、または「None — can start immediately」。

Status： 上記のラベル付けルールに従って記入します。

• 受け入れ条件 1
• 受け入れ条件 2

このイシューは AI が publish-issues を使って作成しました。

実装すること

レイヤーごとの実装ではなく、ユーザーの視点から、このスライスによって実現するエンドツーエンドの動作を記載します。

受け入れ条件

• 条件 1 — 独立して検証できること
• 条件 2

Blocked by

• ブロックする各イシューの識別子、または「None — can start immediately」。

## 親

既存の課題から起票した場合は、元の課題の識別子を記載します。該当しない場合は省略します。

どちらの形式でも、ファイルパスや行番号ではなく、動作とインターフェースを記述してください。これらは古くなるためです。例外として、スパイク調査で、説明文よりも判断を具体的に示すスニペット（状態マシン、リデューサー、スキーマ、型の形状など）が作成された場合は、判断に関わる部分をインラインで記載し、スパイク調査から得られたものであることを明記してください。既存の仕様で作業が網羅されている場合は、関連する受け入れ条件に要件 ID（CODE-N.M）を記載し、トレーサビリティを維持してください。

完了条件

すぐに着手できるスライスを示してください。次のステップとして、各スライスの作業には実行系（build-in-waves／build-by-story／build-inline）または単独の test-first を使用し、スライスごとにコンテキストをクリアするよう案内してください。