to-linear

Linear へ

主要ソースを、承認済みの順序付きバックログに変換します。下書きを作成する前に、$linear-ticket を読み、適用してください。個々のチケットの内容、メタデータ、見積もり、変更、検証はすべてこれに従います。このワークフローでは、登録先の選択、ソースの解決、分割、グラフ全体のレビュー、公開順序を扱います。確認済みの登録先と承認済みの提案を linear-ticket に渡してください。

プロセス

1. 登録先を確認する

分析や下書きの前に、linear-ticket の明示的なチーム／プロジェクト選択と確認の手順を使用してください。このワークフローでは登録先を推測しないでください。ユーザーが選択をやり直さない限り、この実行内のすべてのチケットで、確認済みの登録先を使用します。

2. ソース、コンテキスト、既存のチケットを解決する

スコープの主要ソースを、以下の順序で必ず1つ解決してください。

1. 実行時に明示的に指定されたソース、またはユーザーがこの実行用に明示的に指定したソース：ファイル、イシュー識別子またはURL、貼り付けられた計画／仕様。参照されたイシューは、本文とコメントをすべて取得して読みます。
2. それ以外の場合は、現在の会話で最も新しく確定した計画または仕様。成果物を参照している場合は、その成果物を取得してすべて読みます。
3. それ以外の場合は、ルートの PLAN.md があれば、それをすべて読みます。
4. それ以外の場合は、停止してユーザーにソースを尋ねます。

PLAN.md が存在していても、明示的に指定されたソースを優先します。どのソースを選択したかを伝えてください。複数の候補ソースを統合して新たなスコープを作成しないでください。ソースの選択が曖昧な場合や、矛盾によって意図する成果が大きく変わる場合は、ユーザーに確認してください。

CONTEXT.md、該当する AGENTS.md、参照ソース、関連するADR、設計、コード、テストは、補足コンテキストとして扱います。チケットの正確さに影響する場合は、それらを読みます。CONTEXT.md は、ドメイン用語、境界、長期的な決定について権威ある情報源ですが、補足コンテキストによって主要ソースのスコープを暗黙に拡大してはいけません。

来歴の取り扱いのため、主要ソースと安定した参照先を linear-ticket に渡してください。

作業範囲が広い場合は、サブエージェントを使って、モジュールごとの調査、先行事例の検索、重複の確認など、範囲を限定した独立の読み取り専用調査を行います。調査中も、ほかの独立した分析を進め、その後、下書きの作成前にすべての結果を照合してください。主要エージェントがソースの選択、提案全体の作成、ユーザーの承認、Linear へのすべての変更を担当します。サブエージェントを介してLinearの項目を同時に作成または編集してはいけません。

登録先を確認した後、linear-ticket のスコープに沿った棚卸しと重複レビューを適用し、ソース全体を確認してから分割してください。一致するマイルストーンや、すでにカバーされているイシューは再利用します。範囲を絞った項目や省略した重複項目は、提案全体に明記してください。下書き中に見積もりの調査を適用し、公開の承認までは書き込みを保留します。

3. マイルストーンとトレーサーバレットチケットを下書きする

Human作業とプレファクタリング作業も含め、各スライスを linear-ticket に沿って下書きします。

分割の前に必要なプレファクタリングを確認し、該当する成果は、それによって可能になるスライスより前に配置します。その際は linear-ticket のスコープルールを使用してください。

マイルストーンへの所属と番号付けは、linear-ticket および番号付けのリファレンスに沿って計画します。マイルストーン全体を、時系列順かつトポロジカル順に並べ、前提となるマイルストーンを先に配置します。承認済みの挿入または番号変更に含まれる既存項目にも、番号付けのルールを適用してください。

linear-ticket の前提条件ルールを使用して、提案全体をトポロジカル順に並べます。すべてのマイルストーンを1つのグラフとして扱ってください。チケットは、それ自体のブロッカーが完了すると着手可能になり、先行するマイルストーンに未完了の作業が残っていても構いません。並行して作業するエージェントが実行できる、ブロックされていない作業のフロンティアを特定します。垂直スライスとして安全にリリースできない大規模な機械的リファクタリングでは、順序付けられた拡張・移行・縮小のチケットを使用します。

4. ユーザーとレビューする

選択した主要ソースと、完全な提案をマイルストーン順に提示します。各マイルストーンには既存／新規のステータスを示し、各チケットにはタイトル、既存／新規のステータス、ブロッカー、冒頭のユーザーストーリー、提供する成果、受け入れ基準、担当者（Agent または Human）、ラベル、ソースの出典情報を示します。新規または編集するチケットごとに、提案する見積もりと簡潔な根拠を含め、既存の見積もりへの変更と暫定的な規模の仮定を明示します。除外または範囲を絞った重複項目と、独立して作業できるエージェントチケットの初期フロンティアも明示します。

マイルストーンの名称と順序、チケットの順序、粒度、ユーザーストーリー、依存関係、重複項目の扱い、基準、ラベル、該当する見積もり、出典情報、並行作業のフロンティアについて、ユーザーに承認を求めます。明示的な承認を得るまで公開しないでください。

5. 公開して検証する

公開直前に、対象範囲内のインベントリ全体を更新し、新たな重複項目と使用済み番号を照合します。承認された時系列順に不足しているマイルストーンを作成し、変更が承認されていない既存のマイルストーン名はそのまま維持します。不足しているチケットは linear-ticket を通じて、マイルストーンごと、タイトル番号の昇順で公開し、必須の初期状態として Backlog を指定し、承認済みの全フィールドとイシューごとの変更を渡します。承認済みの編集がない既存イシューには手を加えません。

すべてのイシューが存在したら、承認済みのグラフ全体について、linear-ticket の個別のネイティブ関連付け処理を実行します。新しいイシューと、関連付けの変更が承認された既存イシューをすべて含めます。マイルストーンをまたぐ依存関係も含め、すべての直接的なエッジを提案全体と照合して確認します。

利用可能な場合は、Linear のネイティブなマイルストーン／イシューの並べ替え機能を使用します。それ以外の場合は、作成順と番号付きタイトルを正とし、返された順序を確認して、Linear 上で手動の並べ替えが必要な場合は明確に報告します。順序を強制するために、マイルストーンの目標日を決して捏造しないでください。

新規または編集を承認されたイシューすべてに対し、linear-ticket の保存フィールド、見積もり、説明、番号の検証を行います。保存されたマイルストーン名を再読み込みし、完全な順序を承認済みの提案と照合して確認します。未承認の既存の不整合があれば明らかにします。報告前に、対象範囲内の不一致を修正し、未解決の失敗を報告します。

最後に、プレーンテキストで Milestone order: <最初> → <2番目> → <3番目> と記載し、その後に同じマイルストーン順、番号昇順でイシューの識別子／URLを列挙します。続けて Parallel frontier: <issues> と記載し、別々のエージェントが並行して実装できる、ブロックされていない Agent チケットを列挙します。該当するチケットがない場合は Parallel frontier: none と記載します。