triage について
triage は、失敗した Shiplight の YAML テストを再現、診断、修正するスキルです。テストの意図を保ちながら、根拠に基づく最小限の修正を行い、アプリと仕様の不一致も報告します。
主な機能
- 01テスト失敗の再現と診断
- 02仕様、YAML、失敗時の証拠を確認
- 03根拠に基づく最小限の修正
- 04YAML を検証して対象を再実行
- 05修正内容と未解決事項を報告
活用シーン
- 01Shiplight のテスト実行失敗を調査
- 02デプロイや UI 変更後の回帰を追跡
- 03共通原因による関連する失敗を修正
- 04CI で可能な範囲の修正と結果報告
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/triageを入力して読み込まれたか確認します。
詳細
失敗するテストのトリアージ
このスキルは、失敗する Shiplight YAML テストを再現、診断、修正するために使用します。アプリケーションが壊れている場合、または現在の動作が仕様と食い違っている場合は、テストを書き換えて合わせるのではなく、その不一致を報告してください。
使用するタイミング
次の場合に /triage を使用してください。
- Shiplight のテスト実行が失敗している
- デプロイや UI の変更によって既存のテストが壊れた
- 複数のテストに共通する失敗原因が考えられる
- CI で、可能な範囲での修正と報告が必要
次の場合は /triage を使用しないでください。
- テストをゼロから新規作成する場合。
/create-yaml-testsを使用してください - 失敗するテストがなく、UI コードの変更を検証する場合。
/verifyを使用してください - テストが通っており、タスクが品質改善のみの場合
- プロダクトを意図的に再設計しており、テストを計画的に書き換える必要がある場合
必要なコンテキスト
YAML を編集する前に、次の内容を確認してください。
create-yaml-testsのリファレンスガイドproject-layout.md、updating-tests.md、test-implementation-guide.md、knowledge.mdを読む。- 失敗した領域、環境、認証、データ、ツールに関連する
knowledge/のメモを読む。 - 該当する仕様がある場合は、
specs/tests/の対応する仕様を読む。 shiplight://yaml-test-specとshiplight://schemas/action-entityを読む。
正とする情報
情報源が食い違う場合は、次の優先順位に従ってください。
- ユーザーによる明示的な指示
specs/tests/の機能仕様またはユーザージャーニー仕様- 既存の YAML テストの
goal、ステップのintent、VERIFYアサーション - 現在のアプリの動作
specs/context.mdとknowledge/のプロジェクトコンテキスト- エージェントのドキュメント
- エージェントの推論
現在のアプリの動作が仕様またはテストの目標と食い違う場合は、その不一致を報告してください。意図を現在の動作に合わせて、黙って書き換えないでください。
ワークフロー
- 再現する — 指定された対象を実行します。対象が指定されていない場合は、関連する範囲で最も狭いテストスイートを実行します。失敗が一時的なものに見える場合は、編集前に影響する最小の対象を一度再実行します。
- 把握する — ブラウザーを開いたりファイルを変更したりする前に、失敗の出力、関連する YAML、対応する仕様、関連テスト、共有テンプレート／関数／フックを確認します。
- 必要に応じて調査する — ログやファイルだけでは不十分な場合は、ブラウザーで実際のアプリを調査します。失敗の原因を特定するために必要な証拠（DOM、アクション、ロケーター、コンソールログ、ネットワークログ、スクリーンショット、録画など）を使用します。
- 最小限に修正する — 正しく修正できる範囲のうち、最小のものを変更します。対象は YAML、テンプレート、ヘルパー関数、認証設定、環境データ、仕様などです。共通の壊れた原因を共有していない限り、合格しているテストには触れないでください。
- 検証して再実行する —
validate_yaml_testで編集した YAML を検証し、変更した対象のうち最も範囲の狭いものを再実行します。まとめて修正した後は、元の対象を一度再実行します。 - 振り返る — セッションで今後も役立つ知見が得られた場合や、古くなった前提を訂正した場合は、仕様、
specs/context.md、またはknowledge/を更新します。
ガードレール
- 失敗が現在のブラウザーの動作に左右される場合は、表示される UI を推測しないでください。
- テストを通すことだけを目的に、アサーションを削除したり、必須ステップを省略したり、カバレッジを減らしたりしないでください。
- プロダクトの意図された動作が変わった場合は、YAML を更新する前に該当する仕様を更新してください。
- アプリが壊れている場合は、テスト変更で問題を隠さず、アプリの問題として報告してください。
- ユーザーの変更と無関係な作業を維持してください。
- 広範囲な書き換えより、対象を絞った修正を優先してください。
- 影響を受けるステップを編集する際は、ACTION ロケーターと VERIFY の
js:キャッシュを最新の状態に保ってください。ただし、無関係なキャッシュはむやみに変更しないでください。 - CI または非対話モードでは、ユーザーの入力待ちで処理を止めないでください。保守的に判断し、可能な範囲で修正し、不確実な点を記録してください。
よくある原因には、古いロケーター、ユーザーフローの変更、アサーションのずれ、認証の期限切れ、タイミング、共有テンプレート／フック、無効なパラメータデータ、環境の問題、実際のアプリのバグがあります。証拠に基づいて、正しい最小限の修正を判断してください。
報告
トリアージ後、次の内容を報告してください。
- 実行した対象コマンドと合否
- 変更したファイル
- 修正したテスト、スキップしたテスト、引き続き失敗しているテスト、またはすでに合格していたテスト
- 対象とした、または復旧した動作
- アプリと仕様の不一致、または未解決の阻害要因
- 更新したナレッジ、コンテキスト、または仕様
コメント
Markdown 対応