project-health-check

プロジェクトのヘルスチェック

このプロジェクトの定期ヘルスチェックを、順番に実行してください。各チェックは独立しています。完了できない場合（ツールが見つからない、コマンドが失敗する、アクセスが拒否されるなど）は、何が問題だったかを報告して次のチェックに進んでください。1つのチェックの失敗によって、残りのチェックを中止してはいけません。最後に、すべてのチェックを網羅した短い概要を投稿してください。

入力

これらはスキルの呼び出し時に提供されます。ハードコードしないでください。

• Linear チーム（チェック 3 で必須）— バックログをトリアージするチームの名前またはキー（例：PXLのようなチームキー）。指定されておらず、プロジェクトから明確に推定できない場合は、1回だけ質問してください。
• チケット日付のしきい値（任意）— この日付より前に作成されたチケットは無視します。指定されていない場合、しきい値は適用しません。

チェック 1 — main ブランチをリモートと同期

メインのワークツリー（フィーチャーワークツリーではありません）で、ローカルのmainブランチをorigin/mainに早送りのみで同期してください。現在ワークツリーがどのブランチにあるか、または変更が未コミットかどうかにかかわらず、必ず実行してください。未コミットの変更があるフィーチャーブランチ上のワークツリーは通常の状態であり、スキップする理由にはなりません。進行中の作業を妨げない方法は、作業を退避し、同期してから、すべてを元の状態に戻すことです。処理を中止することではありません。開始時と同じブランチ上にあり、同じ変更が復元されたワークツリーは、妨げられていません。

安全かつ常に元に戻せる作業手順は次のとおりです。

1. ワークツリーの開始状態を記録します。後で元に戻せるよう、現在のブランチと未コミットの作業があるかどうかを確認してください。
2. 作業ツリーが dirty の場合は、進行中の作業を退避します。これにより、mainをクリーンな状態でチェックアウトできます。未追跡ファイルも含めて退避するなど、元に戻せる方法を使ってください。何も失われてはいけません。
3. mainに移動して、origin/mainへ早送りします。mainに分岐があり早送りできない場合は、変更を加えず、分岐していることを記録してください。その後も復元の手順を最後まで実行し、ワークツリーを開始時の状態に戻してください。
4. ワークツリーを開始時の状態に戻します。開始時のブランチに戻り、退避した作業を再適用してください。

通常、作業は問題なく再適用されます。ワークツリーがmain上で始まった場合、変更は新たに早送りされたmainの上に再適用されるため、上流側で同じファイルが変更されていると競合が発生することがあります。**自動で解決するのは、非常に単純で、解決方法に疑いの余地がない競合だけにしてください。**それ以外の複雑な競合や、適切な解決方法に確信が持てない場合は、作業を止めてユーザーに相談してください。退避した作業はそのまま安全に保管し、競合の内容を伝えてください。未コミットの変更に対して、リスクのある編集を行ってはいけません。

ガードレール：

• 早送りのみです。mainを強制操作、リセット、リベースしてはいけません。分岐している場合は報告して次に進んでください。
• ワークツリーは開始時と同じブランチ上で終わり、同じ変更が存在している必要があります。ブランチに戻り、作業を再適用することは必須であり、任意ではありません。退避した作業をきれいに復元できなかった場合でも、決して破棄してはいけません。
• 成功した場合は、mainが進んだかどうか（進んだ場合はその SHA）と、作業を退避して復元したのか、またはmain以外のブランチに戻ったのかを記録し、最終概要を具体的な内容にしてください。

チェック 2 — インストール済みスキルを更新する

1. インストール済みのプロジェクトスキルをすべて、対話なしで最新バージョンに更新します：npx skills update --project --yes。各スキルのソースが自動的に解決され、.agents/skills 内のスキルファイル（およびスキルのロックファイル）がその場で更新されます。
2. 更新によってスキルファイルまたはロックファイルに変更があったかどうかを確認します（該当パスのバージョン管理ステータスなどを使用）。
   • 変更がない場合：「スキルはすでに最新です」と記録して、次に進みます。
   • 変更がある場合：それらの変更だけを含む独立した PR を作成します。タイトルは chore: refresh installed skills、本文には更新されたスキルを列挙します。これは通常の PRです。ship のスタック PR ワークフローには通さないでください。その後、最終報告に更新されたスキルの一覧と PR のリンクを記載します。
3. この PR は、チェック 3 の機能開発とは完全に分離してください。ブランチと PR は別々にし、コミットを共有しないでください。

チェック 3 — チケットのトリアージと ship

指定された Linear チームの未完了チケットを確認し、次に取り組むのに適したチケットを選んでから、ship スキルに引き渡します。

チケットを決定する前に競合を確認してください。次の条件に該当する候補は除外します。

• 未完了の作業を指す依存関係または Blocked by 関係がある。
• 現在 In Progress／In Review の別の Linear issue とスコープが重複している。
• 未完了の PR と重複している。ただし、非アクティブな PR は除きます。非アクティブとは、約 14 日間コミットがない状態です。非アクティブな PR は放棄されたものとみなし、競合には含めません。
• 作成日が、指定されている場合は日付の締め切りより前である。

作業を始める前に、必ず提案を提示し、ユーザーから明示的な承認を得るまで待ってください。自分の判断でチケットを ship に渡してはいけません。選択が明白に思えても同様です。推奨する次のチケットとその理由を一行で示し、代替候補を 3～5 件、一行ずつ要約して提示したら、そこで止めてください。実行可能な適切なチケットがない場合は、その旨を伝えてship をスキップし、無理に選ばないでください。

ユーザーがチケットを明示的に選択または承認した場合に限り、そのチケットを ship スキルに引き渡し、それ以降は同スキルのワークフロー（worktree、スタック、レビュー、マージ）に従います。それ以降の承認ゲートはすべて ship が管理します。

要約

すべてのチェックを網羅した簡潔な報告で締めくくります。

• チェック 1 — main を同期済み（更新された場合は新しい SHA を記載）または「すでに最新です」。作業ツリーが機能ブランチ上にあった、または汚れていた場合は、変更を stash し、main を同期して、ブランチと変更を復元したことを記載します。stash の復元時にユーザー対応が必要な競合が残った場合は、その旨を明記します。あるいは、分岐の状況や、それ以外に同期を妨げた原因を報告します。
• チェック 2 — スキルを更新済み（更新されたスキルの一覧と PR のリンクを記載）または「すでに最新です」。あるいは、更新を妨げた原因を記載します。
• チェック 3 — 選択されたチケットと現在の ship の状況、または選択待ちの候補、または「実行可能なチケットはありません」、あるいは進行を妨げた原因を記載します。
• ユーザーの対応が必要な事項。