triage

トリアージ

triage のエントリーランプを実行しています。バグ、小規模な修正、新しい接続点がなくインターフェースの変更を伴わない、単一コンポーネントに限定された変更に使用します。変更の規模が大きいと分かった場合は、architect にエスカレーションしてください。

ヘルパースクリプトの実行

このスキルには、専用の scripts/ ディレクトリにヘルパースクリプトが含まれています（この SKILL.md とともにインストールされます）。このスキルの絶対パスに SKILL_DIR を設定してください。このパスは、このファイルの末尾に このスキルのベースディレクトリ として示されています。次に、プロジェクトのルートディレクトリからスクリプトを実行します（スクリプトはプロジェクトの .changes/ と CONTEXT.md ファイルを操作します）。

SKILL_DIR="<absolute path to this skill's directory>"

以下のすべての node "$SKILL_DIR/scripts/..." コマンドは、この設定に依存します。packages/build/ は参照しないでください。このパスはツールキットの開発リポジトリにのみ存在し、インストール済みスキルには存在しません。

基本姿勢

references/challenge-protocol.md に記載されている建設的な検討姿勢を採用しますが、このワークフローは軽量に保ちます。トリアージでは、正式な AV-*、SV-*、RV-* レビューを実施せず、監査担当や検証担当の役割も起動せず、review-log.mjs も使用しません。選択が重要性の境界に達した場合に限り、ユーザーに質問してください。その場合、通常、その変更は architect が扱うべきです。慣例的で慣用的なローカル／プライベート／元に戻せる選択は、自動で決定してください。

前提条件

ステータスの確認、マニフェストの作成、CONTEXT.md の読み込み、コードのスキャンを行う前に、目的と観測可能な成果、影響範囲、制約と避けるべきこと、要件が明確になっているか、一部明確になっているか、まだ明確になっていないかを確認してください。ワークスペースを選択または作成した後、references/templates/change-brief.md.tmpl をもとに change-brief.md を作成します。

アクティブな変更を確認します。

node "$SKILL_DIR/scripts/change-status.mjs"

アクティブな変更がない場合は、新規作成します。

node "$SKILL_DIR/scripts/change-new.mjs" --title "<title>" --class small|bug [--language <lang>]

アクティブな manifest.yaml を読み込みます。manifest.language が設定されている場合は、idioms スキルを使って、チャレンジパスとリファクタリングパスに対応するパックを読み込みます。一致するパックがインストールされていない場合は、その旨を伝え、パックのガイダンスを推測するのではなく、リポジトリの言語規約とツールを使用してください。

フェーズ 1：分類

それ以外の作業を始める前に、次の質問に答えてください。

1. 単一のコンポーネントに限定されていますか？ 複数のコンポーネントに触れる場合、またはコンポーネント境界を越える場合は、architect にエスカレーションしてください。
2. 新しい接続点を導入しますか、または既存のインターフェースを変更しますか？ 該当する場合は、architect にエスカレーションしてください。
3. 厳格な接続点に触れますか？ 該当する場合、変更は厳格な契約の範囲内（契約を変更せず実装を変更する）ですか、それとも契約を変更しますか？契約を変更する場合は、architect にエスカレーションし、厳格な接続点の変更プロトコルを適用してください。
4. 修正内容は明確で、範囲が限定されていますか？ そうでない場合は、architect にエスカレーションしてください。

エスカレーションする場合：

"この変更は次の理由でトリアージの範囲を超えています：[理由]。代わりに architect セッションを開始します。"

--class feature を指定して新しいマニフェストを作成し、architect に進んでください。

フェーズ 2：コンテキストの確認

必要なものだけを読みます。

• コンポーネントの CONTEXT.md（存在する場合）
• 関連するソースファイル（コードベース全体ではありません）
• 変更が触れる厳格な接続点（契約を変更していないことを確認）

CONTEXT のうち、関連する Known-soft-spots に注意してください。修正が既知の弱点に触れており、より良い解決策がある場合は、それを提示します。ただし、スコープを拡大する前に明示的な承認を得てください。

フェーズ 3：検討と確認

焦点を絞った質問を1つか2つ行います。全面的な聞き取りにはせず、修正が適切であることを確認できる範囲にとどめます。

• 根本原因は何ですか？（症状だけではありません）
• これは適切な修正ですか、それともより深い問題に対する回避策ですか？
• 影響を受けるほかの呼び出し元や利用者はいますか？
• 慣用表現上の問題に触れる場合、idioms パックにもっとすっきりした方法はありますか？

フェーズ 4：簡易計画

完全な plan.md を作る必要がある場合を除き、短い計画をインラインで記述します。

## Triage Plan: <title>

Root cause: <one sentence>
Fix: <what you're doing>
Files: <target files>

Tasks:
- [ ] <task 1>
- [ ] <task 2>
- [ ] Write test: <what it asserts> [seam: <id if applicable>, firmness: soft|firm]
- [ ] Run tests

バグの場合は、修正する前に、バグを再現する失敗するテストを作成してください。これにより根本原因を確認し、再発を防止できます。

完全な変更ワークスペースを使用する場合は、.changes/active/<id>/plan.md に保存します。

Phase 5: 実装と簡易セルフチェック

タスクを実装します。その後、正式な調査・修正・検証サイクルではなく、実装者による簡単なセルフチェックを一度行います。

• 修正によって新たな負債が生じていませんか？
• もっとすっきり表現できる方法はありませんか？
• イディオム集で関連する項目を確認します。特に、安全でないコードやパニックを起こしやすいコード（例：I/O での Rust の .unwrap()／.expect()）、握りつぶされたエラー、肥大化したモジュールを確認します。

テストを実行し、すべてパスする必要があります。

修正の範囲が小規模で独立した変更を超える場合は、作業を中断し、完全な architect スパインまたは refactor スキルに回します。

Phase 6: ドキュメントの整合性確認

ドキュメントの承認前に、整合性確認と検証が必要です。関連する CONTEXT.md の対象すべてについて、以下を行います。

• 該当する CONTEXT.md のセクションを更新します。
• プロベナンスを再記録します。
• 検証を実行し、指摘事項をすべて解決します。

  node "$SKILL_DIR/scripts/context-verify.mjs" --path <context-file>
  

Phase 7: アーカイブ準備完了と検証済みアーカイブ

簡易セルフチェックとドキュメントの整合性確認後に、実装を承認してからドキュメントを承認します。これにより、直接のトリアージライフサイクルが archive-ready に移行します。

node "$SKILL_DIR/scripts/manifest-approval.mjs" --id <id> --approval implement --approve
node "$SKILL_DIR/scripts/manifest-approval.mjs" --id <id> --approval docs --approve

変更がアーカイブ準備完了になってから、検証済みアーカイブを作成します。

node "$SKILL_DIR/scripts/change-archive.mjs" --id <id>

キャンセルする場合は、manifest.yaml に具体的な archive.reason を記録し、現在のワークスペースを削除せずにアーカイブします。

エスカレーション条件（概要）

以下のいずれかに該当する場合は、architect にエスカレーションします。

• 複数のコンポーネントに触れる
• 継ぎ目を追加または削除する
• インターフェースを（わずかでも）変更する
• 強固な継ぎ目のコントラクトに触れる
• 修正に相応の範囲のリファクタリングが必要となる
• 根本原因分析で、より深いアーキテクチャ上の問題が明らかになる

トリアージにとどめることにこだわりすぎないでください。正当なエスカレーションは失敗ではなく、スコープを誠実に見極めた結果です。

参考ファイル

• references/challenge-protocol.md
• references/context-schema.md — CONTEXT.md を読む場合
• references/seam-and-test-taxonomy.md
• references/firm-change-protocol.md — 強固な継ぎ目が関係する場合
• idioms スキル — 言語が設定されている場合