canary-watch

canary-watch skill の概要

canary-watch は、リリース後やマージ後、依存関係の更新後に、本番 URL を監視して回帰を見つけるためのデプロイ後モニタリング skill です。canary-watch skill を使うのは、リリースが安全そうかを推測するだけの汎用プロンプトではなく、実環境で素早く繰り返し実行できる canary を必要とするときです。

アプリが正しく読み込めるか、主要 API が応答するか、重要な UI やコンテンツのシグナルが維持されているかを確認したいエンジニア、SRE、プロダクトチームに向いています。主な目的はシンプルで、より多くのユーザーに影響が広がる前に、早い段階で破損を検知してロールバックや調査につなげることです。

canary-watch で実際にチェックする内容

この skill は、HTTP ステータス、コンソールエラー、ネットワーク失敗、パフォーマンスの劣化、h1、nav、footer、CTA などの主要ページ要素の消失といった、実用的な回帰シグナルに焦点を当てます。そのため canary-watch は、特にリスクの高い変更の後に、単純な「サイトが落ちていないか」チェックよりも役立ちます。

canary-watch が最も活きる場面

canary-watch は、本番やステージングのスモークチェック、公開直後の監視、ベースライン比較、修正後の検証に使うのが最適です。対象 URL がすでに分かっていて、漠然としたデバッグではなく、しきい値付きの監視結果がほしい場合に特に向いています。

使わないほうがよいケース

深い原因分析、サービス横断のトレーシング、長期的な可観測性ダッシュボードが必要なら、canary-watch だけでは足りません。これは短い時間軸での監視と回帰検知に特化した skill であり、ログ基盤や APM スタックの代わりではありません。

canary-watch skill の使い方

ワークスペースに canary-watch をインストールする

canary-watch のインストールフローでは、リポジトリの install コマンドを使い、実運用で頼る前に skill がエージェント環境で利用可能か確認してください。プラットフォームに別の skill マネージャーがある場合でも、同じ skill slug である canary-watch をそのシステムに対応づけてください。

曖昧な目的を使えるプロンプトに変える

canary-watch の使い方は、URL、watch mode、成功条件を与えると最も効果を発揮します。弱い入力は「自分のサイトをチェックして」。強い入力は「https://app.example.com をデプロイ後 30 分監視し、新しいコンソールエラー、5xx の API レスポンス、nav と CTA 要素の欠落をアラートし、現在のベースラインと比較して」。

最初に読むべきファイル

まず SKILL.md を開き、その skill が参照しているリポジトリ文脈があれば続けて確認します。canary-watch では、SKILL.md にある usage と threshold logic が最も重要な情報源で、とくに watch modes、alert thresholds、skill が何を意味のある回帰とみなすかを確認してください。通常は、リポジトリを読み込みすぎなくても、その内容だけでワークフローを十分に調整できます。

適切な watch mode を選ぶ

一度だけのスモークテストなら quick check、時間を追って公開範囲を監視するなら sustained watch、ステージングと本番を比較したいなら diff mode を使います。canary-watch for Monitoring では、モード名そのもの以上に、interval、duration、comparison target を先に明示することが大切です。そうしないと、監視計画をエージェントに勝手に補完されてしまいます。

canary-watch skill の FAQ

canary-watch は本番専用ですか？

いいえ。canary-watch skill はステージングでも使えますし、むしろ危険な変更を本番展開する前に検証するには、ステージングのほうが安全なことが多いです。重要なのは、既知のベースラインと比較できる挙動を持つデプロイ済み URL があることです。

canary-watch は通常のプロンプトと何が違いますか？

通常のプロンプトでもチェックは依頼できますが、canary-watch の使い方は、明示的な watch mode、しきい値、回帰シグナルを軸に組み立てられています。そのため曖昧さが減り、継続配信を続けるか止めるかを判断したいときに、結果がより実用的になります。

使うのに専門知識は必要ですか？

いいえ。URL、監視時間帯、重視する失敗シグナルを指定できれば、初心者でも canary-watch を使えます。いちばんの失敗は「良好」の定義を曖昧にしすぎることで、それがノイズの多い結果や抜けのある結果につながります。

何を見逃しやすいですか？

canary-watch は、HTTP、コンソール、ネットワーク、ページ内容のシグナルに表れないバックエンド専用の障害にはあまり向いていません。また、履歴トレンドや複数サービスの相関が必要な場面では、完全なパフォーマンス監視やインシデント管理フローの代わりにはなりません。

canary-watch skill を改善する方法

ベースラインをより明確にする

品質を最も大きく上げるのは、canary-watch に「通常時」がどう見えるかを伝えることです。つまり、正確な URL、期待するページ状態、正常であるべき主要要素やエンドポイントです。ベースラインにノイズが多いと分かっているなら、そのことも明示してください。そうしないと、skill が無害な変化に過剰反応することがあります。

症状だけでなく、しきい値を指定する

「なんとなく遅いか見て」ではなく、「LCP が 4 秒を超えたらフラグ」「CLS が 0.1 を超えたら警告」「新しい 5xx レスポンスでアラート」といった具体的な上限を使ってください。canary-watch は、リリース判断に直結する測定可能な境界を与えたときに最も強く働きます。

1 回目の実行後にプロンプトを絞り込む

最初の canary-watch の出力が広すぎるなら、対象エンドポイントを減らす、要素を絞る、監視ウィンドウを短くするなどして範囲を狭めます。逆に問題を見逃したなら、失敗した具体的なユーザーパス、ページ状態、API を追加して、次回は正しい表面を確認できるようにしてください。

ちょっとした確認ではなく、リリースゲートとして使う

優れた canary-watch の使い方は、最終的に「ロールアウト継続」「一時停止」「調査」のいずれかの判断に落ち着きます。各実行をリリースのチェックポイントとして扱い、その結果を次のプロンプトに反映させることで、この skill はあなたの環境に合わせてより精密になります。