自動化監査オペレーション は何をしますか？
ユーザーが次のような質問をした場合に使用します：どの自動化が稼働しているか、どのジョブが壊れているか、どこに重複があるか、どのツールやコネクタが今実際に有用な作業をしているか。
これは監査ファーストのオペレータースキルです。何かを書き換える前に、証拠に基づくインベントリと、維持/統合/削除/次回修正の推奨セットを生成することが仕事です。
スキルスタック
必要に応じて、以下のECCネイティブスキルをワークフローに組み込んでください：
workspace-surface-audit：コネクタ、MCP、フック、アプリのインベントリ用knowledge-ops：監査でライブリポジトリの真実と永続的なコンテキストを調整する必要がある場合github-ops：回答がCI、スケジュールワークフロー、Issue、PRの自動化に依存する場合ecc-tools-cost-audit：実際の問題が、関連アプリリポジトリでのwebhookファンアウト、キューされたジョブ、または課金消費である場合research-ops：ローカルインベントリを現在のプラットフォームサポートや公開ドキュメントと比較する必要がある場合verification-loop：想定される回復に依存せず、修正後の状態を証明するため
使用タイミング
- ユーザーが「どんな自動化があるか」「何が稼働しているか」「何が壊れているか」「何が重複しているか」と尋ねたとき
- タスクがcronジョブ、GitHub Actions、ローカルフック、MCPサーバー、コネクタ、ラッパー、またはアプリ統合にまたがるとき
- ユーザーが別のエージェントシステムから何が移植されたか、ECC内でまだ再構築が必要なものを知りたいとき
- ワークスペースに同じことを実現する複数の方法が蓄積されており、ユーザーが一つの標準的な導管を望んでいるとき
ガードレール
- ユーザーが明示的に修正を依頼していない限り、読み取り専用で開始する
- 以下の状態を分離する：
- 設定済み
- 認証済み
- 最近確認済み
- 古いまたは破損
- 完全に欠落
- スキルや設定が参照しているからといって、ツールが稼働していると主張しない
- 証拠テーブルが存在するまで、重複する面を統合または削除しない
ワークフロー
1. 実際の面をインベントリする
理論化する前に、現在の稼働面を読み取る：
- リポジトリフックとローカルフックスクリプト
- GitHub Actionsとスケジュールワークフロー
- MCP設定と有効化されたサーバー
- コネクタまたはアプリにバックアップされた統合
- ラッパースクリプトとリポジトリ固有の自動化エントリポイント
それらを面ごとにグループ化する：
- ローカルランタイム
- リポジトリCI/自動化
- 接続された外部システム
- メッセージング/通知
- 課金/顧客オペレーション
- 研究/モニタリング
2. 各アイテムを稼働状態で分類する
表面化されたすべての自動化について、以下をマークする：
- 設定済み
- 認証済み
- 最近確認済み
- 古いまたは破損
- 欠落
次に、問題のタイプを分類する：
- アクティブな破損
- 認証停止
- 状態の陳腐化
- 重複または冗長性
- 機能の欠落
3. 証拠パスをトレースする
重要な主張には具体的なソースを添付する：
- ファイルパス
- ワークフロー実行
- フックログ
- 設定エントリ
- 最近のコマンド出力
- 正確な障害シグネチャ
現在の状態が曖昧な場合は、監査が完了したふりをせずに、その旨を直接伝える。
4. 維持/統合/削除/次回修正で終了する
重複しているか疑わしい各面について、以下のいずれかの指示を返す：
- 維持
- 統合
- 削除
- 次回修正
価値は、ノイズの多い自動化を一つの標準的なECC導管に集約することにあり、すべての履歴パスを保持することにはない。
出力形式
現在の面
- 自動化
- ソース
- 稼働状態
- 証拠
所見
- アクティブな破損
- 重複
- 状態の陳腐化
- 機能の欠落
推奨
- 維持
- 統合
- 削除
- 次回修正
次のECCアクション
- 強化すべき正確なスキル/フック/ワークフロー/アプリ導管
落とし穴
- ライブインベントリを読み取れる場合に、記憶から回答しない
- 「設定に存在する」を「動作している」と扱わない
- 壊れた高シグナルパスを名前指定する前に、低価値の冗長性を修正しない
- ユーザーが最初にインベントリを求めた場合、タスクをリポジトリの書き換えに拡大しない
検証
- 重要な主張はライブ証拠パスを引用する
- 表面化された各自動化は、明確な稼働状態カテゴリでラベル付けされる
- 最終推奨は、維持/統合/削除/次回修正を区別する