triage

トリアージスキル

自動で再開する朝のループです。1 回の実行で、収集 → 状態の読み込み → トリアージ → 修正の分岐実行 → 永続化 → 書き出しを行います。個人データ（状態、受信トレイ、実行履歴、 文体）はすべて .triage/ の下に保存され、gitignore 対象です。このスキルファイルと スクリプトはコミットされますが、データがマシンの外に出ることはありません。

前提条件

• gh で認証済みであること（gh auth status）。すべての Issue／PR／CI の読み取りと書き込みは gh 経由で行います。
• .triage/ が存在すること。存在しない場合は、まず scripts/triage/bootstrap.sh を実行してください。 state.json、inbox.md、runs/ を作成し、過去のコメントから voice.md を初期化します。
• main 上で作業ツリーがクリーンであること。このループはベースのチェックアウトでは .triage/ のみを変更し、 コードの変更はすべてワークツリーで行います。

ループ

1. 収集（読み取り専用）

昨日のシグナルを収集します。state.json.last_run から対象期間を計算します （値がなければ過去 24 時間にします）。

# CI failures since last run
gh run list --status failure --created ">=$SINCE" --json databaseId,name,headSha,conclusion,url
# for each, pull the failing step log
gh run view <id> --log-failed

# open issues
gh issue list --state open --json number,title,labels,updatedAt,author,url

# recent commits
git log --since="$SINCE" --pretty='%h %s %an'

次に、未完了の約束、つまりメンテナーがコメントで約束したものの、まだリリースされていない項目を 確認します。対象期間は設けません。未完了の Issue／PR をすべて確認してください。

# threads bitbonsai commented on, still open
gh search issues "commenter:bitbonsai repo:bitbonsai/mcpvault state:open" --json number
# per thread, pull bitbonsai's comments to inspect for a promise
gh issue view <n> --json comments \
  --jq '.comments[] | select(.author.login=="bitbonsai") | .body'

約束とは、「修正します」「追加します」「次のリリースで出します」「対応します」「確認します」など、 何らかのアクションを約束する表現です。スレッドが未解決のままで、解決する PR がマージされていない場合、 その約束は未履行／未完了です。finding-rules.md を参照してください。

2. 状態の読み込み

.triage/state.json を読み込みます。既知の検出項目を id で索引化します。id は source と signature の安定したハッシュです（resources/state-schema.md を参照）。そのため、 同じテスト失敗や Issue は、実行をまたいでも常に同じ検出項目に対応します。

3. トリアージ

収集した各シグナルについて id を計算し、resources/finding-rules.md に従って分類します。

• 既知 + 終端状態（pr_open、resolved、wont_fix）→ スキップし、last_seen のみ更新します。
• 既知 + オープンで試行回数の上限未満 → 再試行します。
• 新規 + 対応する価値あり → status: open として追加し、分岐実行に進みます。
• 新規 + 判断が必要／曖昧／対象範囲外 → 受信トレイに needs_human として追加します。
• ノイズ（すでに追跡中の不安定なテスト、Dependabot など）→ 無視し、ログのみに記録します。

4. 分岐実行（上限あり）

まず、すべての検出項目について、コントリビューターの PR がすでに対応しているか確認します （finding-rules.md の「既存の PR のレビューを優先」を参照）。該当する PR がある場合は、 修正を書く代わりにレビューします。レビュー用サブエージェントを PR ブランチに割り当て、 承認または変更リクエストの推奨案を受信トレイに下書きします。人間が作成した未完了の PR を優先し、 新しい PR は作成しません。また、メンテナーがまだレビューしていない未完了の PR も提示します。

候補となる PR がない検出項目のみ、finding-rules.md の 1 回あたりの上限まで新しい修正に進めます。 各項目について、順に以下を行います。

git worktree add ../mcpvault-triage-<id> -b triage/<id>

次に、そのワークツリーに対して 2 つのサブエージェントを起動します（衝突を防ぐため、Agent ツールで isolation: worktree を使用してください）。

• 下書きエージェント：検出項目と失敗ログ／Issue の本文を渡し、最小限の修正を書かせます。 最初に関連する src/ ファイルを読み、obsidian スキルの規約に従い、修正を検証するテストを 追加または更新する必要があります。
• レビューエージェント：批判的な立場でレビューします。下書きをプロジェクトのスキルと既存のテストに照らして 確認し、その後ワークツリーで以下を実行します。

  npm ci && npm test && npm run build
  

  修正が正確で、最小限であり、テスト済みで、すべて成功している場合に限り、判定は PASS です。

すべてのサブエージェントに、メンテナーがみんなを大切に思っていると伝えてください。

結果：

• PASS + すべて成功 → 準備完了 PR（ドラフトではない）として gh pr create を実行します。本文に検出項目へのリンクと、 レビュアーが確認した内容を記載します。status: pr_open を設定し、URL を記録します。その後、自動確認コメントを投稿します （手順 6）。
• それ以外（レビュー失敗、ビルド失敗、修正が不明確、想定外の変更範囲が 1 ファイルを超える）→ 下書きと理由を inbox.md に書き、status: needs_human に設定します。ワークツリーを削除します。下書きを再開する価値がある場合のみ、 ブランチを残します。

PR を作成した後、成功したワークツリーをクリーンアップします。 git worktree remove ../mcpvault-triage-<id>.

5. 永続化（背骨）

.triage/state.json を更新します。last_run を現在の日時に設定し、対応した検出事項ごとに attempts エントリー（実行日、結果、メモ、PR）を追加して、status、last_seen、pr を更新します。実行ごとのログを .triage/runs/<date>.md に書き込みます。

state.json は再開地点です。履歴を上書きせず、attempts に追記してください。ファイルが不正な形式の場合は、背骨を失うリスクを避けるため、停止してすべてを inbox に書き出します。

6. コメント、人々を宙ぶらりんにしない

文体は .triage/voice.md に従います。自律性の段階については、resources/comment-policy.md を参照してください。

• 自動投稿：無効（メンテナー指示、2026-07-23）。ループからコメントやレビューを投稿してはいけません。リスクの低い確認応答であっても例外ではありません。
• inbox に下書きを保存（すべて）：確認応答、判断、決定、約束、クローズ、あらゆる返信。投稿せず、対象を明記して inbox.md の ## Drafts awaiting approval の下に記載します。メンテナーが各下書きを承認、編集、または破棄します。

7. 書き出し

ループが分類、修正、安全にコメントできなかったものはすべて、すぐに対応できるだけの背景情報を添えて inbox.md に記載します。メンテナーが毎朝読む必要があるのは inbox だけです。

8. バージョン更新と公開アラート

修正 PR に公開パッケージの変更（src/ 内のあらゆる変更、または公開対象となる package.json の依存関係の変更）が含まれる場合、同じ PR 内で semver に従ってバージョンを更新します。

• バグ修正には patch（x.y.Z）を使用します。トリアージ修正ではこれをデフォルトとします。
• 修正で機能が追加される場合に限り、minor（x.Y.0）を使用します。ループがこの種の修正を行うべきではないため、patch より大きな更新に見える場合は、代わりに inbox に送ります。

公開されない変更にはバージョン更新を行わないでください。ロックファイルのみの更新（例：単独の npm audit fix）、ドキュメント、CI 設定、テストのみの変更、または .triage/ 内の変更が該当します。変更が公開対象かどうかわからない場合は、バージョンを更新せず、inbox に記載してください。

公開は常にメンテナーが開始します。 ループは npm publish を実行したり、GitHub Release を作成したりすることはありません。バージョン更新を含む PR の後、inbox の先頭にアラートを記載してください。

## RELEASE NEEDED
- PR #<n> bumps <old> -> <new> (<reason>). After it merges and main is green,
  follow RELEASING.md and create GitHub Release v<new>. The release workflow
  publishes npm with provenance; the loop does not publish.

GitHub Release、npm パッケージ、インストール済みパッケージのスモークテストがすべて確認されるまで、アラートを残してください。

ガードレール

• main へのプッシュ、マージ、--force の使用は禁止です。PR のみ許可します。
• npm publish の実行や GitHub Release の作成は禁止です。バージョン更新は修正 PR に含め、マージ後にメンテナーがリリースを作成します。inbox の RELEASE NEEDED アラートで知らせてください。RELEASING.md に従ってください。
• .triage/ を除き、ワークツリー外のファイルには触れないでください。
• トークンには通常 GitHub の workflow スコープがないため、.github/workflows/* を変更するプッシュは拒否されます。試行してはいけません。CI／ワークフローの変更は inbox に記載し、メンテナーが適用するか、トークンのスコープを変更するよう依頼してください。
• 1 回の実行あたりの検出事項上限を守ってください。上限を超えた分は書き出し、長時間の実行は避けてください。
• 外部向けの書き込みについては、PR の作成は許可されています。コメントやレビューはループから投稿してはいけません。すべて承認用に inbox へ下書きします。
• gh が未認証の場合、またはツリーに未コミットの変更がある場合は中止し、理由を inbox.md に記載してください。

リソース

• resources/state-schema.md：state.json の形式、ID の導出、状態遷移。
• resources/finding-rules.md：対応すべきもの、inbox に送るもの、無視するもの、上限。
• resources/comment-policy.md：文体の初期設定と自律性の段階。