Menu
インシデント発生時に自律的に対応するメタスキルです。 初動対応から復旧、事後分析までを体系的に実行し、再発防止を強化します。 Trigger: インシデント, 障害, 緊急対応, トラブル, 本番エラー, デグレ, 互換性破壊, バグ
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
agentops のオフライン記憶整理 (consolidation) 機能。会話 transcript は読まず、 既存の memory entry を「精緻化のみ」する。新しい記憶が獲得されたセッションでだけ Stop hook から自動発火する (fingerprint trigger gate)。手動実行は /dream。 Trigger: dreaming, memory consolidation, 記憶整理, refine memory, dream, memory dedup, /dream
AI 生成(vibecoding)成果物に潜む「それっぽい虚偽」を、固定された検査カタログ(検査ID・手順・ 合格基準つき)で系統的に検出する監査規格。主張面を列挙し、各主張面に対応する検査を 機械的に適用し、カバレッジマトリクスに全セルの実施状態を記録する。 内部整合(テスト全パス・schema valid・CI green)は証拠として認めない。 Trigger: 虚偽検出, ハリボテ検出, vibecoding 監査, 本物か確認, それっぽい嘘, fabrication audit, AI生成コード 検証, 捏造チェック.
Builds a harness: a meta-skill that defines specialist agents and generates the skills they use. Trigger when the user (1) asks to 'build/set up/construct a harness', (2) asks for 'harness design' or 'harness engineering', (3) wants a harness-based automation system for a new domain/project, (4) wants to restructure or extend an existing harness, or (5) asks to inspect, audit, sync, or maintain an existing harness (agents/skills drift, status check).
dev tool / OSS が「刺さるか(PMF)」をエンジニアリング観点で監査するオーケストレーター。 3 specialist agent (ttfv-auditor / trust-calibrator / wedge-scoper) をチームで起動し、 初回体験(TTFV)・出力の信頼(false-positive economics)・scope の鋭さ(wedge over engine)を 並行監査して、合成 PMF readiness スコアと優先度付き改善提案を1つのレポートに統合する。 Trigger: PMF 監査, PMF audit, dev tool 採用, なぜ自分のOSSが採用されない, ローンチ前監査, TTFV, time to first value, false positive, 誤検知, 信頼設計, wedge, scope 設計, this tool isn't getting adopted, audit my OSS before launch, 再監査, re-audit, 改善後の再評価. CLI/library/dev tool/security tool の repo を渡された採用観点の監査依頼で発火する。 単なるコードレビューやバグ探し、一般的な品質監査では発火しない(それらは別 skill)。
security / correctness tool(linter, scanner, verifier)の出力が信頼を獲得・維持できる設計かを 監査する方法論。false-positive economics、Indeterminate verdict、audit-first rollout、 suppression の使い勝手、FP feedback loop を採点する。trust-calibrator agent が使用。 Trigger: 信頼設計 監査, false positive 監査, FP economics, verdict 設計, audit-first, suppression, linter 疲労.
dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル.
| name | incident-handling |
| description | インシデント発生時に自律的に対応するメタスキルです。 初動対応から復旧、事後分析までを体系的に実行し、再発防止を強化します。 Trigger: インシデント, 障害, 緊急対応, トラブル, 本番エラー, デグレ, 互換性破壊, バグ |
| user-invocable | false |
インシデント対応を構造化し、被害最小化・復旧時間短縮・再発防止を実現する。
| 観点 | 状況 |
|---|---|
| コンポーネント | API Gateway → Lambda統合 |
| 影響ユーザー | モバイルアプリユーザー |
| 機能喪失度 | ユーザー関連機能が完全停止 |
| SEVレベル | SEV1（主要機能停止） |
| 層 | 問い | 回答 |
|---|---|---|
| 表層 | なぜクラッシュ？ | ヘルスチェック失敗 |
| 中層 | なぜ失敗？ | 起動が遅い |
| 深層 | なぜ遅い？ | RDS接続タイムアウト |
| 根本 | SG設定ミス | ECS→RDS間の通信が遮断 |
| 戦略 | 適用場面 | リスク |
|---|---|---|
| ロールバック | 即時復旧が必要、前バージョンが安定 | データ不整合の可能性 |
| ホットフィックス | 問題が明確で修正が小さい | 急いでさらにバグを入れる |
| 機能フラグ無効化 | 新機能起因、既存機能は正常 | 一部ユーザーへの影響継続 |
| 互換レイヤー追加 | 段階的移行が必要 | 複雑性増加 |
| 旧（v1） | 新（v2） | 互換対応 |
|---|---|---|
| GET /users/{id} | GET /v2/users/{id} | v1パス維持 |
| POST /orders | POST /v2/orders | リクエスト形式変換 |
以下のいずれかに該当する場合、即座にロールバック：
単一原因ではなく、複数条件の組み合わせでインシデントが発生することがある。
状況: 本番環境でLambda関数が断続的にタイムアウトする 複合パターンの分析： 1. VPC内Lambda（コールドスタートが遅い） 2. RDS Proxyなし（コネクション枯渇リスク） 3. 同時実行数制限（デフォルト1000）単独では問題ないが、トラフィック増加時に3つが組み合わさると障害になる。
| 条件 | 単独リスク | 複合リスク |
|---|---|---|
| VPC内Lambda | 低（コールドスタート遅延） | ↓ |
| RDS Proxyなし | 中（コネクション管理） | ↓ |
| 同時実行数制限 | 低（通常は十分） | 高（トラフィック増時に障害） |
| 順序 | イベント |
|---|---|
| 1 | CloudFormationスタック更新実施 |
| 2 | CloudWatchアラーム発報 |
| 3 | 原因調査開始 |
| 4 | セキュリティグループ設定ミスを特定 |
| 5 | 設定修正完了 |
| 6 | サービス復旧確認 |
CloudFormationテンプレートのセキュリティグループ設定に誤りがあった。
| 対策 | 担当 | 優先度 |
|---|---|---|
| CFnテンプレートのレビュープロセス強化 | インフラチーム | 高 |
| ECSタスク失敗アラートの追加 | SREチーム | 高 |
| ロールバック手順書の作成 | インフラチーム | 中 |
インシデント対応で行った重要な意思決定は ./docs/adr に記録する。
# ADR-XXXX: [インシデント]への対応方針
## ステータス
採用
## コンテキスト
[何が起きたか、影響範囲]
## 決定
[選択した復旧戦略]
## 理由
- [なぜこの戦略を選んだか]
- [他の選択肢を選ばなかった理由]
## 結果
- 残存リスク: [あれば]
- 技術的負債: [発生した場合]
| タイミング | 適用するフェーズ |
|---|---|
| 障害検知時 | 1. 初動対応 |
| 原因調査中 | 2. 障害調査 |
| 対応方針決定時 | 3. 復旧戦略選択 |
| 復旧作業中 | 4. 段階的復旧 |
| 復旧完了後 | 6. 事後分析 |
| 振る舞い | 問題 | 代わりに |
|---|---|---|
| 症状だけ治す | 再発する | 根本原因まで掘り下げる |
| 影響範囲を確認せず修正 | 二次被害 | 最初に影響範囲を可視化 |
| ロールバック手順なしでデプロイ | 復旧が遅れる | 事前にロールバック計画 |
| ポストモーテムをスキップ | 同じ失敗を繰り返す | 必ず事後分析を実施 |
| 犯人探し | 心理的安全性低下 | システム改善にフォーカス |