linear-close

Linear Close

実装レビュー後、PR がマージされた場合、issue ID を直接含むコミットが存在する場合、または squash／インポートのリリース証拠によって、期待されるファイルと内容が現在の main に存在し、release/main の CI が通過したことが確認できる場合に使用します。現在の Linear issue ID と、チケットの証拠に記録された実装済み issue ID のチームプレフィックスが、issue が別のチームに移動されたために異なる場合は、同じクローズアウトのルールに従って古い実装済み ID を手動で確認し、両方の ID を記載したメモを添えて現在の issue をクローズします。

以下を読み、従ってください。

• agents/closer.md
• docs/workflow.md
• docs/agent-required-passes.md
• docs/comment-validation.md
• docs/tools.md
• templates/linear-status-comment.md

コードの実装、PR のマージ、レビュー方針の変更は行わないでください。このスキルは、マージ済み PR の証拠、issue ID を含むコミットの証拠、または squash／インポートのリリース証拠が存在する場合にのみ、作業を最終確定します。

このスキルの実行時に、issue のステータスがすでに Done になっている場合があります。実装担当者がクローズ用のマジックワード（Fixes HCL-123）を使用すると、マージ時に Linear が issue を自動的に移動するためです。すでに Done の issue は想定どおりとして扱います。証拠を確認し、ダッシュボードを更新し、クローズアウトコメントを投稿して、llm-* と in-use を削除してください。その場合、ステータスを Done に移動する操作は何も行いません。issue を再オープンしたり、すでに Done であることをエラーとみなしたり、クローズアウトの最終確定を省略する理由にしたりしないでください。

Claim Lock

docs/workflow.md の Claim Lock Rule に従ってください。開始時に issue を再読込します。すでに in-use が付いており、この実行が自分の claim の再開ではない場合は、変更を加えず、issue が claim 済みであることを報告して停止します。それ以外の場合は、issue を claim する際に in-use ラベルを追加します。in-use は llm-* 名前空間の対象外なので、クローズアウト時に llm-* を削除しても残ります。最終確定時（ブロックされた場合や放棄して停止する場合も同様）に、in-use を明示的に削除してください。

claim 時に、issue の説明に linear-ai:claim ブロック（templates/linear-claim-block.md）を追加し、claimed_by: linear-close と ISO 8601 形式の claimed_at を記載します。最終確定時に、in-use ラベルの削除と併せて claim ブロックも削除します。

Linear MCP Contract

利用可能な場合は、以下の Linear MCP ツールを使用してください。

• get_issue - issue の説明、ダッシュボード、ラベル、ステータス、プロジェクト、ブランチのメタデータ、リンクを読み取ります。
• list_comments - 最新のマーク付き計画／ステータスコメントと、過去のクローズアウト証拠を探します。
• save_comment - 最終の不変なマーク付きステータス／クローズアウトコメント、またはブロックされたクローズアウトの証拠を投稿します。
• save_issue - issue の説明とダッシュボードを更新し、ステータスを Done に移動して、すべての llm-* ラベルと in-use claim を削除し、累積する sp-* ラベルを保持します。

利用可能な場合は、Git／GitHub の証拠を使用してください。

gh pr view <PR> --json url,state,isDraft,baseRefName,mergeCommit,statusCheckRollup,commits > pr.json
git pull
git merge-base --is-ancestor <merge-commit> origin/main

コミットを直接クローズアウトする場合は、issue ID と完了したステータスチェックを含むコミット証拠を取得します。

{
  "oid": "replace-with-commit-sha",
  "subject": "fix(HCL-123): example issue commit",
  "statusCheckRollup": [
    { "name": "test", "status": "COMPLETED", "conclusion": "SUCCESS" }
  ]
}

squash／インポートのリリースをクローズアウトする場合は、release/main の成功したチェックと、現在の mainline ref に照らして検証できるファイルのアサーションを含むリリース証拠を取得します。

{
  "statusCheckRollup": [
    { "name": "release main CI", "status": "COMPLETED", "conclusion": "SUCCESS" }
  ],
  "files": [
    { "path": "dist/manifest.json", "contains": "\"version\":\"2026.06.14\"" }
  ]
}

以下を使用して、クローズアウト証拠を検証します。

scripts/verify_closeout.ts --issue-id <ISSUE-ID> --pr pr.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <ISSUE-ID> --commit commit.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <CURRENT-ISSUE-ID> --implemented-issue-id <OLD-ISSUE-ID> --commit commit.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <ISSUE-ID> --release release.json --repo . --base origin/main

--implemented-issue-id は、issue が移動された後に、現在の issue key と実装済み issue key の Linear チームプレフィックスが異なる場合にのみ使用してください。PR の証拠を使用する場合は、ヘルパーが古い実装済み ID に言及するコミットを検証できるよう、PR のコミットを含めます。クローズアウトコメントには、<CURRENT-ISSUE-ID> が <OLD-ISSUE-ID> から移動された、またはその ID のもとで実装されたこと、および実装、mainline、CI の証拠を古い ID に照らして手動で検証したことを記載する必要があります。

以下を使用して、最終的なマーク付きコメントと issue の説明ダッシュボードを検証します。

scripts/validate_marked_comments.ts --description <issue-description-file> <status-comment-file>

エージェントが利用できるローカルの JavaScript パッケージマネージャーまたはランタイムを使用してください。Bun は .ts スクリプトを直接実行できます。Node／npm／pnpm／yarn 環境では、tsx などの TypeScript ランナーを介して実行してください。

クローズ要件

課題を Done に移す前に、以下のすべてを証明してください。

• リンクされた PR がマージされている
• または、直接コミットの証拠に課題 ID が含まれている
• または、チームをまたいで移動した課題の場合、PR のコミット証拠または直接コミットの証拠に、以前に実装された課題 ID が含まれており、現在の課題 ID のチームプレフィックスが異なる
• または、スカッシュ／インポートによるリリースの証拠により、想定されるファイルパスとコンテンツが現在の main に存在することが証明されている
• または、親のトラッキング課題の場合、すべてのサブ課題が検証済みのクローズ証拠を伴って Done になっており、親のレビューゲートで親の要件が満たされていることが確認されている
• mainline に、マージコミット、課題 ID を含む直接コミット、同等のリモート mainline の証拠、想定されるリリースファイル／コンテンツの証拠、または（親のトラッキング課題の場合）サブ課題の検証済み mainline の証拠が含まれている
• CI が、マージ済み PR、マージコミット、課題 ID を含む直接コミット、またはリリース／main の証拠について完了し、成功している。親のトラッキング課題の場合は、各サブ課題の検証済み CI 証拠によってこれを満たします
• 最終的なダッシュボード／ステータスの証拠が、クローズと矛盾していない
• すべての llm-* ワークフローステートラベルと in-use クレームラベルが削除される
• 累積 sp-* ラベルが保持される

必須の証拠が不足している場合は、課題をクローズしないでください。証拠が不足している旨を投稿するか、REQUIRED_LINEAR_MUTATIONS を出力してください。

最終処理

クローズが成功した場合、以下を行う必要があります。

• 課題の説明にダッシュボードブロックがマークされている場合は、そのブロックを更新する
• 最終的な不変のマーク付きステータス／クローズコメントを 1 件投稿する。チーム移動後に以前に実装された課題 ID を使ってクローズした場合は両方の ID を含め、スカッシュ／インポートによるリリースの証拠を使ってクローズした場合は、検証済みのファイル／コンテンツおよびリリース／main の CI 証拠を含める
• Linear のステータスを Done に移す（クローズ用のマジックワードによってすでに移動済みの場合は何もしない）
• llm-refine、llm-ready、llm-active、llm-blocked、llm-review を削除する
• in-use クレームラベルを削除する
• sp-clarify、sp-plan、sp-tdd、sp-implement、sp-verify、sp-review などの累積 sp-* ラベルを保持する

クローズした課題がサブ課題の場合は、同じ最終処理で docs/workflow.md の「親課題とサブ課題のルール」を適用してください。未完了のサブ課題が残っている場合は、残りの兄弟課題の状態に合わせて、親課題の llm-* 状態とステータスを更新します。これが最後の未完了サブ課題だった場合は、親課題のレビューゲートを実行します。マージ済みのサブ課題の作業で親課題の要件と受け入れ基準がすべて満たされていることを検証し、満たされていれば親課題を llm-review および In Review に移して、親課題自体のクローズ処理を行います。不足が残っている場合は、親課題に llm-refine を適用し、不足点を記録します。

Linear MCP の書き込みツールが利用できない場合は、ラベル、ステータス、ダッシュボード、コメントを更新したと主張しないでください。親課題のロールアップ更新があればそれも含め、課題の説明、最終クローズコメント、ラベル、ステータスの変更を正確に記載した REQUIRED_LINEAR_MUTATIONS を出力してください。

ステップ完了時の引き継ぎ

クローズが完了したとき、またはブロックされたときは、変更内容、マージの証拠、CI の証拠、ダッシュボード／ステータスの証拠、現在の Linear のラベル／ステータス、推奨する次のステップを報告してください。

このクローズのステップについて追加することがあるか尋ねてください。ある場合は、クローズの証拠を確認するか、クローズの報告を更新して現在のステップを続けてください。ない場合は、次のワークフローステップ（通常は、課題がクローズされていることの確認、または残っている課題の調査を行う linear-status）に進むことを推奨してください。

追加事項についての質問に「いいえ」と回答された後、推奨する次のスキルに進むかどうかを尋ねてください。推奨する次のスキルを明示し、ユーザーの確認を待ってください。自動実行しないでください。

次の形式で回答してください。

• 現在のフェーズ
• 変更内容
• 証拠
• 不足している証拠
• 未解決のブロッカー
• 推奨する次のステップ
• 推奨する次のスキル
• 質問：次に進む前に追加することはありますか？
• 質問：推奨する次のスキルに進みますか？