自動化監査運用

ユーザーが、どの自動化が実行されているか、どのタスクが失敗しているか、どこに重複があるか、またはどのツールとコネクタが実際に機能しているかについて質問するときは、このスキルを使用してください。

これは監査優先型の運用スキルです。その目的は、コンテンツを書き直す前に、証拠に裏付けされたインベントリと、保持/マージ/削除/次のステップの修正に関する推奨事項セットを生成することです。

スキルスタック

関連する場合、以下のECC標準スキルをワークフローに組み込みます：

• workspace-surface-audit - コネクタ、MCP、フック、およびアプリのインベントリ用
• knowledge-ops - 監査がライブリポジトリの実際の状態を永続的なコンテキストと照合する必要がある場合
• github-ops - 回答がCI、スケジュール実行ワークフロー、イシュー、または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作業
- 強化が必要な特定のスキル/フック/ワークフロー/アプリチャネル

一般的な落とし穴

• ライブインベントリを読むことができるときは、記憶から答えない
• 「構成に存在する」を「機能している」とみなさない
• 低価値の冗長性を修正する前に、障害の高シグナルパスを指摘しない
• ユーザーが最初にインベントリを要求した場合、タスクをリポジトリ書き直しに拡大しない

検証

• 重要なクレームはライブ証拠パスを参照する必要がある
• 検出された各自動化には、明確なライブステータスカテゴリーをラベル付けする必要がある
• 最終的な推奨事項は、保持 / マージ / 削除 / 次のステップで修正を区別する必要がある