ワークスペースサーフェス監査
「このワークスペースとマシンは今、実際に何ができて、次に何を追加または有効化すべきか?」という質問に答えるための読み取り専用監査スキル。
これはECCネイティブのセットアップ監査プラグインの答えです。ユーザーが明示的にフォローアップの実装を求めない限り、ファイルを変更しません。
使用するタイミング
- ユーザーが「Claude Codeをセットアップして」「自動化を推奨して」「どのプラグインやMCPを使うべき?」「何が足りない?」と言った場合
- さらにスキル、フック、コネクタをインストールする前にマシンやリポジトリを監査する場合
- 公式マーケットプレイスのプラグインとECCネイティブのカバレッジを比較する場合
.env、.mcp.json、プラグイン設定、接続済みアプリサーフェスをレビューして、不足しているワークフローレイヤーを見つける場合- 機能をスキル、フック、エージェント、MCP、外部コネクタのどれとして実装すべきか判断する場合
絶対のルール
- 秘密の値を決して出力しない。プロバイダー名、機能名、ファイルパス、キーや設定が存在するかどうかのみを明らかにする。
- ECCがその表面を妥当に所有できる場合、汎用的な「別のプラグインをインストール」というアドバイスよりもECCネイティブのワークフローを優先する。
- 外部プラグインはベンチマークやインスピレーションとして扱い、権威ある製品境界とはみなさない。
- 次の3つを明確に区別する:
- すでに利用可能
- 利用可能だがECCで適切にラップされていない
- 利用不可であり、新しい統合が必要
監査の入力
質問に適切に答えるために必要なファイルと設定のみを検査します。
- リポジトリの表面
package.json、ロックファイル、言語マーカー、フレームワーク設定、README.md.mcp.json、.lsp.json、.claude/settings*.json、.codex/*AGENTS.md、CLAUDE.md、インストールマニフェスト、フック設定
- 環境の表面
- アクティブリポジトリおよび明らかに関連するECCワークスペース内の
.env*ファイル STRIPE_API_KEY、TWILIO_AUTH_TOKEN、FAL_KEYなどのキー名のみを明らかにする
- アクティブリポジトリおよび明らかに関連するECCワークスペース内の
- 接続ツールの表面
- インストール済みプラグイン、有効なコネクタ、MCPサーバー、LSP、アプリ統合
- ECCの表面
- すでにニーズをカバーしている既存のスキル、コマンド、フック、エージェント、インストールモジュール
監査プロセス
フェーズ1:存在するものの一覧
簡潔な一覧を作成します:
- アクティブなハーネスターゲット
- インストール済みプラグインと接続済みアプリ
- 設定済みMCPサーバー
- 設定済みLSPサーバー
- キー名から推測される環境変数バックエンドサービス
- ワークスペースに関連する既存のECCスキル
表面がプリミティブとしてのみ存在する場合は、それを明示します。例:
- 「Stripeは接続済みアプリ経由で利用可能ですが、ECCには請求オペレータースキルがありません」
- 「Google Driveは接続されていますが、ECCネイティブのGoogle Workspaceオペレーターワークフローはありません」
フェーズ2:公式およびインストール済み表面とのベンチマーク
ワークスペースを以下と比較します:
- セットアップ、レビュー、ドキュメント、デザイン、ワークフロー品質に関連する公式Claudeプラグイン
- ClaudeまたはCodexにローカルインストールされたプラグイン
- ユーザーが現在接続しているアプリサーフェス
単に名前を列挙するだけではありません。各比較に対して、次の質問に答えます:
- それらが実際に何をするか
- ECCがすでに同等の機能を持っているか
- ECCがプリミティブしか持っていないか
- ECCがワークフロー全体を欠いているか
フェーズ3:ギャップをECCの決定に変換する
すべての実際のギャップに対して、適切なECCネイティブ形状を推奨します:
| ギャップの種類 | 推奨されるECC形状 |
|---|---|
| 繰り返し可能なオペレーターワークフロー | スキル |
| 自動的な適用または副作用 | フック |
| 特化された委任ロール | エージェント |
| 外部ツールブリッジ | MCPサーバーまたはコネクタ |
| インストール/ブートストラップガイダンス | セットアップまたは監査スキル |
ニーズがインフラストラクチャ的ではなく運用上のものである場合、既存のツールをオーケストレーションするユーザー向けスキルをデフォルトとします。
出力形式
次の5つのセクションをこの順序で返します:
- 現在の表面
- 今すぐ使用可能なもの
- 同等性
- ECCがすでにベンチマークと同等またはそれを上回っている部分
- プリミティブのみのギャップ
- ツールは存在するが、ECCにクリーンなオペレータースキルがない部分
- 不足している統合
- まだ利用できない機能
- 上位3~5の次のアクション
- 具体的なECCネイティブの追加項目。インパクト順に並べる
推奨ルール
- カテゴリごとに、最も価値の高い1~2のアイデアのみを推奨する。
- ユーザーの意図が明確でビジネス価値のあるスキルを優先する:
- セットアップ監査
- 請求/カスタマーオペレーション
- 課題/プログラムオペレーション
- Google Workspaceオペレーション
- デプロイメント/運用制御
- コネクタが企業固有のものである場合は、それが本当に利用可能でユーザーのワークフローに明らかに役立つ場合にのみ推奨する。
- ECCがすでに強力なプリミティブを持っている場合は、まったく新しいサブシステムを発明するのではなく、ラッパースキルを提案する。
良い結果
- ユーザーは何が接続されていて、何が不足していて、次にECCが何を所有すべきかを即座に把握できる。
- 推奨事項は、追加の調査パスなしでリポジトリに実装できるほど具体的である。
- 最終的な回答は、APIブランドではなくワークフローを中心に整理されている。