implement-task-linear

Linear のタスクを実装する

提示された Linear の課題をすべて、1 つのブランチと 1 つの PR でまとめて実装します。提示された課題は必須の入力であり、実装範囲の境界をまとめて定めるものです。各課題の来歴とリポジトリのコンテキストは、作業を黙って追加することなく、実装方法を具体化します。PR を公開する前に、提示された課題をすべて完了してください。対象のいずれかでブロッカーが発生した場合、変更全体の公開を中断します。

このスキルは、$complete-work を Linear 固有のラッパーとして使用します。デリバリー計画を立てる前に、そのスキルを読んでください。ブランチのセットアップ、段階的なコミット、検証、プッシュ、create-pr による PR の作成、finish-pr によるレビューと CI の収束を担当します。そのスキルまたは必要な依存関係を利用できない場合は、部分的なワークフローで代用せず、実装前に不足している前提条件を報告して解決してください。このスキルの実行は、ワークフロー全体の実施を許可するものです。マージ、デプロイ、リリースは別途ユーザーから依頼されるまで行わないでください。

チケットの草案作成や変更を行う前に、$linear-ticket を読み、適用してください。各対象の検証済みのチーム／プロジェクトの境界と、このワークフローで限定された許可を渡してください。チケットの内容、採番、メタデータ、見積もり、ネイティブな書き込みと読み戻し検証は、このスキルが担当します。

行動を開始する前に、予定している調査とデリバリーについて、簡潔で正確な箇条書きをいくつか示してください。ステップ 1～3 は読み取り専用の調査と確認です。これらを使って、ブランチの作成、リポジトリの編集、Linear の変更を行う前に、十分な情報に基づく計画を立ててください。

1. 対象と Linear の境界を特定する

曖昧さのない Linear の課題識別子または URL を 1 つ以上受け取ります。指定がない場合はユーザーに確認し、提示された参照をすべて解決して、同じ課題を指す参照は重複を除きます。各課題の識別子、URL、受け入れ条件、チーム／プロジェクト ID、ワークフロー状態 ID、見積もり、実装と検証の対象範囲、保存状況を記録した対象台帳を管理します。以下の各ステップでは、この台帳内のすべての課題に対して、対象ごとの調査と照合を行います。

各対象について、説明全文、ステータス、ラベル、チーム、プロジェクト、関連識別子、コメント、要件に関わる添付ファイルを取得します。正確なチーム ID とプロジェクト ID を記録します。プロジェクトがない場合は、周辺の Linear の作業を調査する前に、ユーザーにプロジェクトを割り当てるか、指定したプロジェクトへの割り当てを許可するよう求めてください。

明示的に指定された対象は、チームやプロジェクトが異なる場合があります。それぞれの境界は別々に維持してください。各対象について、関連する Linear の課題を読み取る場合も変更する場合も、その対象独自の境界を適用します。

• 記録済みの両方の ID を指定してクエリし、各結果に両方の ID が含まれていることを確認します。
• 親課題、サブ課題、ブロッカー、重複課題、関連課題は、未検証の識別子を直接取得するのではなく、範囲を限定したクエリで特定します。
• スコープをまたぐ関連は、利用できないコンテキストとして扱い、その存在のみを報告します。
• 許可された書き込みでは、記録済みの両方の ID を linear-ticket に渡します。

対象チームに関係するワークフロー状態、特に進行中、レビュー中、バックログ、ブロック状態がある場合はその状態を、ID によって特定します。曖昧な場合は推測せずに報告します。

読み取り専用のこの段階で、linear-ticket の見積もり調査機能を使用します。評価した見積もりとその根拠は、ステータス変更を含め、許可された対象または関連課題へのすべての更新に反映します。

提示されたすべての対象について、受け入れ条件、チーム／プロジェクト ID、使用可能なワークフロー状態が記録された時点で、このステップは完了です。

2. プロベナンスチェーンをたどる

リポジトリのルートを特定し、リポジトリ内で他の作業を始める前に、該当する AGENTS.md をすべて読みます。

次に、以下の順序でコンテキストを確認します。対象が明示的に依存している場合を除き、各情報源は任意です。

1. 起点となる仕様 — 対象内に明示された Source のパスや URL、仕様へのリンク、デザインへのリンク、要件を含む添付ファイルをすべてたどります。to-linear で仕様がネイティブの親として表現されている場合は、チームとプロジェクトを指定したクエリでその親を見つけ、両方の ID を確認したうえで、説明全体とコメントを読みます。プロベナンスが記録されていない場合は、docs/、specs/、.scratch/ を検索し、対象のタイトル、ソース名、機能スラッグに明確に一致するものが一つだけあるか確認します。候補が複数ある場合は、どれを選ぶか確認してください。意図、依存関係、または乖離を明らかにできる場合は、対象範囲内の親課題、ブロッカー、マイルストーンやサイクルの関連課題、重複する課題を調べます。
2. 計画 — ルートに PLAN.md がある場合は、全体を読みます。全体的な成果、順序、依存関係、計画における対象の位置づけを把握するために使います。
3. ドメインコンテキスト — ルートに CONTEXT.md がある場合は、全体を読みます。ルートに CONTEXT-MAP.md がある場合も全体を読み、対象に該当するコンテキスト項目をすべてたどります。コンテキストファイルで定義するのはプロジェクトの用語とドメインの境界であり、実装範囲ではありません。
4. 決定事項 — ルートの docs/adr/ 以下にある該当 ADR と、コンテキスト固有の docs/adr/ を確認します。選択した仕様、計画、コンテキストファイル、ADR、および現在の会話に記載された関連成果物への参照をたどります。
5. リポジトリの実態 — 関連するコード、テスト、ドキュメント、スキーマ、マイグレーション、生成物、設定、Git の状態を調べます。関係のないユーザーの変更は保持します。

前提となるスキルによって、このチェーンの一部がすでに用意されている場合があります。

• grill-with-docs によって、CONTEXT.md、CONTEXT-MAP.md、ADR が用意されている場合があります。
• to-spec によって、実装上の決定事項、合意済みのテストの境界、対象外の事項が起点となるトラッカーの課題に記載されている場合があります。
• to-linear によって、ネイティブの親課題または Source 参照を通じて起点情報が対象に引き継がれ、永続的な制約が Context にコピーされている場合があります。

任意の成果物が存在しなくても、実装を妨げることはありません。明示された参照先については、必ず確認するか、参照先を利用できない理由を報告してください。

次の優先順位に従って、情報を評価します。

• 提供された対象課題が、成果物と受け入れ条件を合わせて定義します。
• 起点となる仕様と PLAN.md は、対象範囲を広げることなく、意図、順序、対象外の事項を説明します。
• コンテキストファイルと ADR は、用語、境界、永続的な決定事項を定めます。
• リポジトリは、現在の実装の実態を示します。

重要な矛盾や古くなった情報があれば明らかにしてください。意図する動作、公開インターフェース、互換性、または対象範囲が変わる場合に限り、確認を求めます。

この手順は、すべての対象について明示されたプロベナンス参照先をすべて確認するか利用できない旨を報告し、該当するコンテキスト成果物をすべて読み、対象要件をそれぞれ「実装済み」「一部実装」「未実装」「矛盾あり」「ブロック中」に分類した時点で完了です。

3. 明確化し、デリバリーを計画する

実装前に、以下を平易な言葉で簡潔な箇条書きにして、ユーザーに概要を伝えます。

• 具体的な成果と変更される箇所
• 小さなデリバリー手順と各手順の確認方法。合意済みの公開テスト用シーム、または適合する既存の最上位シームを含めます。
• ディスカバリーで判明した重要な前提、トレードオフ、コンテキストの不足、差異
• ユーザーに必要な対応。続けて、complete-work によるコミット、PR、CI／レビュー完了までの計画を示します。

概要はすばやく把握できるようにまとめます。参照した情報源は簡潔に示し、判断に説明が必要な場合に限って詳しく説明します。要件、動作、範囲、互換性、公開インターフェースに関する重要な不確実性は、ブランチの作成や実装に着手する前にユーザーと解消します。そのような判断にインタビューが必要な場合は、complete-work の条件付き $grilling インタビューを使い、すでに得られている回答も引き継ぎます。明確で実行可能なタスクでは、概要を伝えれば十分であり、重複した承認待ちは不要です。

すべての対象について、各受け入れ基準と長期的に適用される制約を、実装変更または具体的な検証方法に対応付けます。提示された対象全体をひとつのデリバリーとして扱い、依存関係と重複する要件を計画します。統合した作業をひとつのリポジトリとPRでデリバリーできることを確認します。できない場合は、実装前にユーザーとその矛盾を解消します。既存の動作は、検証して初めて実現済みとして扱います。シームの選択によって公開インターフェースが新設または実質的に変更される場合、上流の成果物ですでに確定していなければ、ユーザーに確認します。

統合したデリバリーに向けて、簡潔なレビューコンテキストを用意します。すべての対象の基準への対応状況、確定したトレードオフ、対象外とした項目を complete-work とPRに引き継ぎます。また、LinearにアクセスできないPR Agentが意図を評価できるよう、短い情報源リンクと十分な説明を含めます。対象ごとの完全な記録は別途保持し、PRの概要には重要な制約のみを記載して、ディスカバリーメモ全体の転記は避けます。

この手順の完了条件は、ユーザーに概要が伝えられ、すべての受け入れ基準にデリバリーと検証の経路があり、すべての重要な質問に回答が得られていることです。

4. complete-work を通じてデリバリーする

統合したスコープについて $complete-work を一度実行し、すべての対象の完全な要件、入手できる場合は元のユーザーストーリー、受け入れ基準、情報源、長期的に適用される制約、合意済みの計画、テスト用シーム、ユーザーの判断を引き継ぎます。create-pr のユーザーストーリーのルールを含む、完全なワークフローに従います。技術的な背景のない読者にも理解できる、日常的な言葉による簡潔なストーリーを必須とし、必要に応じて元の表現を調整します。GitとPRの手順は complete-work に従います。ブランチのセットアップは、上記の読み取り専用のディスカバリーと明確化の後に行います。編集前に、改めて取得したベースブランチと計画を照合し、新たに重要な不確実性が判明した場合はユーザーと解消します。

統合した作業の実装を開始したら、各対象をそのチームの「解決済み In Progress」ステータスに移します。ただし、すでにそれより先に進んでいる場合、またはユーザーがステータスの維持を求めている場合は除きます。後のスライスで対応予定の対象も含め、開始時点ですべての対象について実施します。この操作とその後のすべてのチケット更新には linear-ticket を使用し、検証済みの結果または失敗を記録に残します。

complete-work 内では、検証可能な動作について、合意済みの公開シームでレッドからグリーンへ進めながら、検証済みの垂直スライスとして実装します。必要なドキュメント、スキーマ、マイグレーション、生成成果物、設定も含めます。PR公開前のゲートを通過する前に、リポジトリ標準、適用されるADR、提示されたすべての対象のすべての基準、元となる仕様の制約に照らして差分全体を監査します。指摘事項を修正し、影響を受けるチェックを再実行します。必須の対象作業は、すべてこのひとつの変更に含めます。

PR 作成時にすべての対象をリンクし、レビュー状態を更新する

タイトルのプレフィックスルールに従うため、すべての対象識別子に加え、タスクの根拠となり、PR によって完全に完了する関連チケットも create-pr に渡してください。また、PR の説明文の末尾に、指定した対象をすべて記載する締めくくりの行を含めてください。例：

Fixes ENG-123, ENG-124, ENG-125, ENG-126, and ENG-127

1 つの対象だけの場合はその識別子 1 つを含め、台帳に記載された実際の識別子を使用してください。既存の GitHub–Linear 統合は、これらの締めくくりの参照を使って PR をリンクし、マージ時にチケットを自動的にクローズします。この統合の設定は変更せず、マージまではチケットをオープンのままにしてください。

PR の作成または再利用が完了したら、直ちに保存済みのタイトルと説明文を読み返してください。タイトルが create-pr のチケットプレフィックスルールに従っていること、締めくくりの参照に指定した対象がすべて含まれていることを確認してください。漏れがあれば修正してから、finish-pr に進む前に、すべての対象についてステップ 5 の PR コメントと In Review への遷移を実行してください。この時点でレビューや CI が未完了でも、これらの遷移を実行する妨げにはなりません。

ユーザーの入力が必要なときは協力する

利用可能なツール、アクセス権、確定済みの要件で進められる限り、自律的に作業を続けてください。ユーザーの判断、認証情報、権限、アカウント設定、その他の前提条件が必要になった場合は、速やかに依頼し、次の内容を説明してください。

• これまでに実装・検証した内容。役立つ場合は、確認可能な成果物、スクリーンショット、プレビューも提示してください。
• 不足しているものと、それによって実行できない残りの動作や検証項目。
• それを提供または取得する方法。設定やアクセス権が必要な場合は、該当サービスまたはアカウントへの直接リンク、関連する設定画面、必要最小限の手順を含めてください。
• 設定場所。該当する場合は、正確な環境変数名またはシークレット名と対象環境を示してください。
• 完了後にユーザーに確認してほしいことと、その後に再開する作業。

ユーザーに手動設定を依頼する前に、利用可能な認証済みツールと既存の設定を確認してください。設定手順は、推測で案内せず、該当サービスの公式ドキュメントで最新の情報を確認してください。認証情報は適切なシークレットストアまたはローカル環境に設定し、チャットで値を尋ねたり、コミットしたりしないでください。

たとえば、動作する UI は確認できる状態でも、API キーがないためにライブデータの取得がブロックされている場合があります。UI を提示し、未検証の連携を明示したうえで、サービスへのリンクと設定手順を案内してください。ユーザーの応答を待つ間も、独立して進められる作業は続けてください。ユーザーから入力が届くまでは、それに依存する作業を一時停止し、届いたら前提条件を検証して作業を再開してください。時間が経過しただけでは、回答とはみなされません。complete-work の完全性ゲートは引き続き適用されます。不完全な実装やモックデータを根拠に、不完全な対象の PR を公開してはいけません。

5. Linear を調整し、引き継ぐ

上記の指示に従い、PR 作成時にこの調整を実行し、さらに complete-work が最終監査または停止条件に達した後にも再度実行します。すべての対象と、変更した関連課題を再取得し、各課題のチーム／プロジェクトの境界を再確認してください。既存の引き継ぎコメントを再利用し、最終確認時に重複して投稿するのではなく、根拠に変更があれば更新してください。

提示されたすべての対象について、必要な成果がすべて実装・検証され、共有 PR が存在する場合は、対象ごとに次を行います。

1. 共有 PR へのリンクを含む簡潔な対象コメントを追加または更新し、その対象の受け入れ条件と実装・検証の根拠を対応付けます。現在の CI／レビュー状況と、finish-pr が報告したブロッカーも含めてください。
2. linear-ticket を通じて、現在の状態がそれより前段階の場合に限り、対象を所属チームの解決済み「In Review」状態に移動し、検証済みの結果を台帳に記録します。

完了済み、キャンセル済み、アーカイブ済み、「In Review」、その他の終端状態またはそれより先に進んでいる状態は維持してください。いずれかの対象で実装または必須の検証がブロックされている場合、統合 PR は公開せず、着手済みの対象は「In Progress」のままにするか、該当する場合は解決済みのブロック状態にし、未達の基準、根拠、依存関係を記録してください。実装の準備状況と、未完了の PR レビューまたは CI を区別してください。finish-pr の完了定義を満たした場合にのみ、ワークフローが完全に完了したと報告してください。マージ後の完了状態への移行は、設定済みの GitHub–Linear 自動化に任せてください。

関連する Linear 作業

ユーザーは、実装の根拠に基づく場合に限り、該当する対象に記録されたチーム／プロジェクトの境界内で、最小限の関連課題の変更を許可しています。

正当なフォローアップの作成と、根拠に基づく関連課題の更新には linear-ticket を使用し、起点となる対象とその境界を渡してください。重複確認、基準の網羅性、出所、マイルストーン／番号付け、見積もり、検証に関する規則が適用されます。このワークフローでは、提示されたすべての対象の範囲外にある最小限の関連編集とフォローアップが許可されています。マイルストーンの作成、および既存の名前／タイトルの変更には、引き続き明示的な承認が必要です。対象に必要な作業は統合実装に含め、未達の前提条件はブロッカーとして残してください。すべて網羅されたことが検証済みの関連課題は、同じチケット手順を通じて、以前の状態から「In Review」に移動できます。

引き継ぎ

以下を報告してください。

• 提示されたすべての対象の識別子、URL、検証済みの最終状態。
• 共有 PR の URL、提示されたすべての対象について検証済みのクローズ参照、および finish-pr の最終監査。該当するものがない場合は、PR の作成またはワークフローの完了を妨げている具体的な前提条件。
• 実装した成果と変更した箇所。
• 検証コマンドと結果。
• 受け入れ条件の網羅状況。
• 使用したコンテキストソースと、利用できなかった明示的な参照先。
• 見つかった重大な差異または矛盾。
• 実装の判断を変更するに至った、参照した関連課題すべて。
• 作成または変更したすべての課題について、その理由、状態、URL。
• 作成または変更した各課題について、保存した見積もりと簡潔な根拠、仮の規模に関する前提、または無効化／エラーの具体的な結果。
• ブロッカー、制限事項、フォローアップ作業。

関連する Linear 課題に変更がなかった場合は、その旨を明記してください。