everything-claude-code/docs/ja-JP/skills/workspace-surface-audit/SKILL.md

---
name: workspace-surface-audit
description: アクティブなリポジトリ、MCPサーバー、プラグイン、コネクター、環境サーフェス、ツールのセットアップを監査し、最も価値の高いECCネイティブスキル、フック、エージェント、オペレーターワークフローを推奨する。ユーザーがClaude Codeのセットアップを支援してほしい場合や、環境で実際に何が使えるかを理解したい場合に使用する。
origin: ECC
---

# ワークスペースサーフェス監査

読み取り専用の監査スキル。「このワークスペースとマシンが現在実際に何をできるか、次に何を追加または有効化すべきか？」という質問に答えるために使用する。

これはセットアップ監査プラグインに対するECCネイティブの回答である。ユーザーが明示的にフォローアップの実装を要求しない限り、ファイルを変更しない。

## 使用する場面

* ユーザーが「Claude Codeをセットアップする」「自動化を推奨する」「どのプラグインまたはMCPを使うべきか？」または「何が足りないか？」と言う
* スキル、フック、コネクターをさらにインストールする前にマシンやリポジトリを監査する
* 公式マーケットプラグインとECCネイティブのカバレッジを比較する
* ワークフローレイヤーの欠落を見つけるために `.env`、`.mcp.json`、プラグイン設定、または接続されたアプリのサーフェスをレビューする
* 機能がスキル、フック、エージェント、MCP、または外部コネクターのどれであるべきかを決定する

## 交渉不可能なルール

* シークレット値を決して印刷しない。プロバイダー名、機能名、ファイルパス、キーまたは設定が存在するかどうかのみを表示する。
* ECCがそのサーフェスを合理的に所有できる場合は、一般的な「別のプラグインをインストール」という推奨よりECCネイティブワークフローを優先する。
* 外部プラグインをベースラインとインスピレーションとして扱い、権威ある製品境界としてではない。
* 3つのことを明確に区別する：
  * 現在利用可能なもの
  * 利用可能だがECCのカプセル化が不十分なもの
  * 利用不可能で新しい統合が必要なもの

## 監査の入力

質問に答えるために必要なファイルと設定のみを確認する：

1. リポジトリサーフェス
   * `package.json`、ロックファイル、言語マーカー、フレームワーク設定、`README.md`
   * `.mcp.json`、`.lsp.json`、`.claude/settings*.json`、`.codex/*`
   * `AGENTS.md`、`CLAUDE.md`、インストールマニフェスト、フック設定
2. 環境サーフェス
   * アクティブなリポジトリと明らかに隣接するECCワークスペース内の `.env*` ファイル
   * キー名のみを表示する（`STRIPE_API_KEY`、`TWILIO_AUTH_TOKEN`、`FAL_KEY` など）
3. 接続されたツールサーフェス
   * インストール済みプラグイン、有効化されたコネクター、MCPサーバー、LSP、アプリ統合
4. ECCサーフェス
   * 要件をカバーする既存のスキル、コマンド、フック、エージェント、インストールモジュール

## 監査プロセス

### フェーズ1：既存のものを棚卸しする

簡潔なインベントリを生成する：

* アクティブなツールチェーンのターゲット
* インストール済みプラグインと接続されたアプリ
* 設定済みのMCPサーバー
* 設定済みのLSPサーバー
* キー名で示唆される環境ベースのサービス
* ワークスペースに関連する既存のECCスキル

サーフェスが生の形式でしか存在しない場合は指摘する。例：

* 「Stripeは接続されたアプリで利用可能だが、ECCには課金操作スキルがない」
* 「Google Driveは接続されているが、ECCにはGoogle Workspaceネイティブの操作ワークフローがない」

### フェーズ2：公式およびインストール済みサーフェスとベンチマーク比較する

ワークスペースを以下と比較する：

* セットアップ、レビュー、ドキュメント、デザイン、またはワークフロー品質と重複する公式Claudeプラグイン
* ClaudeまたはCodexにローカルインストールされたプラグイン
* ユーザーが現在接続しているアプリのサーフェス

名前だけを列挙しない。各比較に対して以下を答える：

1. それらが実際に何をするか
2. ECCが同等の機能をすでに持っているか
3. ECCが生の形式のみを持っているか
4. ECCがそのワークフローを完全に欠いているか

### フェーズ3：ギャップをECCの決定に変換する

各実際のギャップについて、適切なECCネイティブの形式を推奨する：

| ギャップの種類 | 優先するECC形式 |
|----------|---------------------|
| 繰り返し可能な操作ワークフロー | スキル |
| 自動実行または副作用 | フック |
| 特殊な委任役割 | エージェント |
| 外部ツールブリッジ | MCPサーバーまたはコネクター |
| インストール/オンボーディングガイダンス | セットアップまたは監査スキル |

ニーズが運用的であってインフラストラクチャ的でない場合は、デフォルトで既存のツールをオーケストレーションするユーザー向けスキルを使用する。

## 出力フォーマット

この順序で5つのセクションを返す：

1. **現在のサーフェス**
   * 現在利用可能なもの
2. **同等の機能**
   * ECCがベースラインに一致または超えている場所
3. **生の形式のみのギャップ**
   * ツールは存在するが、ECCには簡潔な操作スキルがない
4. **欠けている統合**
   * まだ利用できない機能
5. **上位3-5の次のステップ**
   * 影響度順の具体的なECCネイティブな追加

## 推奨ルール

* 各カテゴリにつき最大1-2つの最も価値の高いアイデアを推奨する。
* 明確なユーザー意図とビジネス価値を持つスキルを優先する：
  * セットアップ監査
  * 課金/顧客運用
  * Issue/プロジェクト運用
  * Google Workspace運用
  * デプロイ/運用コントロール
* コネクターが企業固有の場合、それが実際に利用可能またはユーザーのワークフローに明らかに有用な場合のみ推奨する。
* ECCがすでに強力な生の形式を持っている場合は、まったく新しいサブシステムを発明するのではなくカプセル化スキルを提案する。

## 良い結果

* ユーザーが接続されているもの、欠けているもの、ECCが次に持つべきものをすぐに確認できる。
* 推奨事項は再発見なしにリポジトリで実装できるほど具体的。
* 最終的な回答はAPIブランドではなくワークフローを中心に整理されている。