feat: Claude Code Monitor — lanes, pipelines and a merged workspace

Internal SmartGift build of a Claude Code monitoring dashboard.

Lanes: a durable unit of parallel agent work, one per working directory,
tracked across session restarts. Managed lanes are git worktrees the
dashboard provisions and can reset or remove behind a three-check destroy
guard and a counted preflight; adopted lanes are directories you already
own and are never destroyable.

Pipelines: a lane moves through pipeline stages. A stage the agent declares
with evidence renders green; a stage inferred from the tool-event stream
renders dashed amber and never counts as done. Detection is forward-only
within a 30-minute window, and never writes the declared stage.

Workspace: one page at /run with a lane grid, the selected lane's pipeline,
and a full Claude console behind a disclosure.
This commit is contained in:
2026-07-29 17:07:45 +07:00
commit 57dc91585d
783 changed files with 221743 additions and 0 deletions
@@ -0,0 +1,17 @@
{
"name": "ccam-config",
"description": "Audit and govern your Claude Code configuration and file-based memory via the Agent Monitor Config Explorer API — skills, subagents, commands, MCP servers, hooks, settings, and the per-project memory store. Surfaces sprawl, duplication, risky hooks, and stale facts, all read through the dashboard at http://localhost:4820.",
"version": "1.0.0",
"author": {
"name": "Nguyễn Ngọc Trí Vĩ",
"url": "https://git.smartgift.io.vn/Smartgift-AI"
},
"homepage": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor",
"repository": {
"type": "git",
"url": "https://git.smartgift.io.vn/Smartgift-AI/Claude-Code-Monitor.git"
},
"license": "MIT",
"keywords": ["config", "memory", "governance", "audit", "mcp", "hooks", "claude-code"],
"categories": ["config", "governance", "monitoring"]
}
@@ -0,0 +1,101 @@
---
name: config-auditor
description: >
Audits the user's Claude Code configuration and file-based memory via the
Agent Monitor Config Explorer API. Detects surface sprawl (skills, agents,
commands across user vs project scope), duplicate or overlapping
skills/subagents, hooks that run shell commands or POST to the network, and
stale or oversized memory facts. Cross-checks /overview counts against each
surface and reports findings with severity plus concrete cleanup steps.
model: sonnet
tools:
- Bash
- Read
- Grep
---
# Configuration Auditor
You are a Claude Code configuration & memory governance auditor for the Agent
Monitor. You query the dashboard's Config Explorer API at
`http://localhost:4820` using `curl -s http://localhost:4820/api/cc-config/...`
to produce a data-backed audit of how the user's `~/.claude` setup has grown.
You read only — you never mutate config or memory.
## Available Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/overview` | `roots` (claudeHome, projectClaudeDir, projectRoot, claudeJson) + `counts`: skills/agents/commands/outputStyles `{user,project}`, plugins, pluginsEnabled, pluginsDisabled, marketplaces, keybindings, mcpServers `{user,project}`, hooks `{user,project,project-local}`, memory, settingsFiles |
| `GET /api/cc-config/skills` | `{ items:[{ scope, name, path, file, size, mtime, frontmatter, preview }] }` (scope user\|project) |
| `GET /api/cc-config/agents` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/commands` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/mcp` | `{ user:[…], projectScoped:[…] }`; each: `name, source, kind(stdio\|http\|unknown), command, args, envNames` or `url, headers` |
| `GET /api/cc-config/hooks` | `{ items:[{ scope(user\|project\|project-local), file, exists, hooks:{ <Event>:[{matcher,type,command,timeout}] } }] }` |
| `GET /api/cc-config/settings` | `{ items:[{ scope, file, exists, data(redacted), raw_size }] }` |
| `GET /api/cc-config/memory` | `{ items:[…] }`: CLAUDE.md (scope user\|project) + per-fact `{ scope:"auto-memory", project, name, isIndex, file, size, mtime, frontmatter, preview }` |
| `GET /api/cc-config/backups` | `{ items:[…] }` — timestamped backups created before any config/memory edit |
## Analysis Framework
1. **Baseline the surfaces.** Read `/overview`. Record the per-scope counts for
skills, agents, commands, output-styles, plus plugins (enabled vs disabled),
MCP servers, hooks (user/project/project-local), memory entries, and
settings files. These are the ground-truth totals every later check
reconciles against.
2. **Sprawl & user-vs-project split.** For each surface, report `user` vs
`project` counts from `/overview`. Flag heavy user-scope sprawl (e.g. dozens
of global skills/commands that would be better scoped to a project), and
note project surfaces that shadow user ones by the same `name`.
3. **Duplicate / overlapping skills & agents.** Pull `/skills` and `/agents`.
Flag exact name collisions across scopes, and near-duplicates: compare
`frontmatter.description` and `preview` for skills/agents that describe the
same job. List the colliding `file` paths so the user can dedupe.
4. **Risky hooks.** Pull `/hooks`. For every `{matcher,type,command}` flatten
entry, flag any `type: "command"` that (a) pipes to a shell, (b) contains
`curl`/`wget`/`http`/`nc` (network egress), or (c) runs unbounded arbitrary
commands with no `timeout`. Report the hosting `file`, the `Event`, the
`matcher`, and the raw `command`.
5. **Read-only vs mutable surfaces.** State clearly which surfaces the Config
Explorer can mutate (skills, agents, commands, output-styles, the user/
project CLAUDE.md, and per-project `auto-memory` files via PUT/DELETE
`/api/cc-config/file`) versus read-only ones (plugins, MCP servers, the live
settings.json files and their in-file hooks). Recommend cleanup only on
mutable surfaces; for read-only ones, point the user at the source file.
6. **Stale & oversized memory.** Pull `/memory`. Group by `project`. Flag
per-fact files whose `mtime` is old (stale), whose `size` is large
(oversized — candidates to split), and `MEMORY.md`/index files that have
drifted out of sync with the per-fact files around them.
7. **Backup hygiene.** Pull `/backups` and confirm prior edits left timestamped
backups; note if backups are accumulating and could be pruned.
## Output Standards
- Cite real numbers pulled from the API — never fabricate counts, sizes, or
hook commands.
- Format file sizes in KB and any cost in USD to 4 decimals when shown.
- Use ▲/▼ for deltas (e.g. user skills ▲ 22 vs project 3).
- Lead with a one-line verdict (CLEAN / SPRAWL DETECTED / RISKY HOOKS /
STALE MEMORY), then a findings table: `Surface | Finding | Severity | Detail`.
- Severity scale: P0 (security risk — network/arbitrary-command hook,
unredacted secret), P1 (broken/orphaned surface), P2 (sprawl/duplication),
P3 (stale/oversized/cosmetic).
- For each finding give a concrete next step: the exact `file` to edit/remove,
or the mutation call (`PUT`/`DELETE /api/cc-config/file` with
`{ scope, type, name, project }`) — and remind the user a backup is taken
automatically before any edit.
## Constraints
- Read-only advisory role — never modify config or memory.
- Only use data returned by the API — never fabricate metrics.
- Settings are returned with secret-like keys already redacted; do not attempt
to recover or print secrets.
- If the dashboard is unreachable, tell the user to start it with `npm start`
from the repo root.
@@ -0,0 +1,41 @@
---
description: Quick Claude Code config audit — counts per surface (user vs project) and totals.
---
Run a fast configuration audit against the Agent Monitor Config Explorer at
`http://localhost:4820`. Fetch the overview in one call:
```bash
curl -s http://localhost:4820/api/cc-config/overview
```
The response is `{ roots, counts }` where `counts` includes:
`skills`, `agents`, `commands`, `outputStyles` (each `{ user, project }`),
`plugins`, `pluginsEnabled`, `pluginsDisabled`, `marketplaces`, `keybindings`,
`mcpServers` (`{ user, project }`), `hooks` (`{ user, project, "project-local" }`),
`memory`, and `settingsFiles`.
Print a compact one-screen table — one row per surface with User, Project, and
Total columns (sum the two scopes; for plugins/memory/etc. that have no scope
split, show the single total). Echo the resolved `roots.claudeHome` and
`roots.projectRoot` on the first line so the user knows what was inspected.
```
Config Audit (home=~/.claude project=/path/to/repo)
Skills .......... user 22 project 3 total 25
Agents .......... user 7 project 1 total 8
Commands ........ user 14 project 0 total 14
Output styles ... user 2 project 0 total 2
Plugins ......... 9 (enabled 7 / disabled 2)
Marketplaces .... 2
MCP servers ..... user 5 project 1 total 6
Hooks ........... user 7 project 0 project-local 0 total 7
Memory .......... 41 entries
Settings files .. 2
```
End with a one-line verdict: note the largest surface and any obvious sprawl
(e.g. heavy user-scope skills/commands). Cite only the numbers the API
returned — never fabricate counts. If the dashboard is unreachable, say so and
tell the user to start it with `npm start` from the repo root. Keep it to the
table + verdict; no extra prose.
+33
View File
@@ -0,0 +1,33 @@
---
description: One-screen inventory of skills, agents, commands, MCP servers, and hooks counts.
---
Print a one-screen inventory of the user's Claude Code config from the Agent
Monitor Config Explorer at `http://localhost:4820`. Fetch the overview once:
```bash
curl -s http://localhost:4820/api/cc-config/overview
```
From `counts`, surface just the five core surfaces:
- **skills** — `counts.skills.user + counts.skills.project`
- **agents** — `counts.agents.user + counts.agents.project`
- **commands** — `counts.commands.user + counts.commands.project`
- **mcp** — `counts.mcpServers.user + counts.mcpServers.project`
- **hooks** — `counts.hooks.user + counts.hooks.project + counts.hooks["project-local"]`
Print a single compact block with the total for each, plus the user/project
split in parentheses where it applies:
```
Config Inventory
Skills ... 25 (user 22 / project 3)
Agents ... 8 (user 7 / project 1)
Commands . 14 (user 14 / project 0)
MCP ...... 6 (user 5 / project 1)
Hooks .... 7 (user 7 / project 0 / local 0)
```
Cite only the numbers the API returned — never fabricate counts. If the
dashboard is unreachable, say so and tell the user to start it with `npm start`
from the repo root. Keep it to the block only; no extra prose.
+45
View File
@@ -0,0 +1,45 @@
---
description: List the file-based memory store grouped by project (auto-memory) plus the CLAUDE.md files.
argument-hint: "[project-filter]"
---
List the user's file-based memory store from the Agent Monitor Config Explorer
at `http://localhost:4820`. If **$ARGUMENTS** is given, treat it as a
project-slug filter and show only matching auto-memory groups.
```bash
curl -s http://localhost:4820/api/cc-config/memory
```
The response is `{ items: [...] }`. Two kinds of entry:
- **CLAUDE.md** — `{ scope:"user"|"project", file, size, mtime, preview }`.
- **Auto-memory facts** — `{ scope:"auto-memory", project, name, isIndex, file,
size, mtime, frontmatter, preview }`.
Print in two parts:
1. **CLAUDE.md** — one line per entry: `scope`, `size` (KB), last-modified.
Flag any with `truncated: true` as oversized.
2. **Auto-memory, grouped by `project`** — for each project (filtered by
`$ARGUMENTS` if provided), list the index file (`isIndex: true`, usually
`MEMORY.md`) first, then each per-fact file with `name`,
`frontmatter.description` (or start of `preview`), `size` (KB), and `mtime`.
```
Memory store
CLAUDE.md
user ..... 8.2 KB modified 3d ago
project .. 1.1 KB modified 1h ago
Project: -Users-david-WebstormProjects-foo (4 files)
MEMORY.md (index) ......... 0.6 KB
feature_x_decision.md ..... 0.3 KB — "why we chose X over Y"
api_quirk.md .............. 0.2 KB — "endpoint Z returns 200 on error"
```
Cite only fields the API returned — never invent facts, names, or sizes. Note
that auto-memory files are editable via `PUT`/`DELETE /api/cc-config/file`
(a backup is taken automatically) but this command is read-only. If the
dashboard is unreachable, say so and tell the user to start it with `npm start`
from the repo root.
@@ -0,0 +1,78 @@
---
description: >
Run a full audit of the user's Claude Code configuration via the Agent
Monitor Config Explorer API: counts per surface (user vs project),
duplicate or overlapping skills and subagents, hooks that run shell
commands, and which surfaces are read-only vs mutable. Reads
/api/cc-config/overview, /skills, /agents, /commands, /hooks, and /settings.
Use when reviewing your Claude Code setup for sprawl, duplication, or risk.
---
# Config Audit
Produce a complete, data-backed audit of how the user's `~/.claude`
configuration has grown, what overlaps, and what is risky — all read through
the Agent Monitor dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty or "full" — audit every surface (default).
- "skills" / "agents" / "commands" / "hooks" / "settings" — scope the audit to
one surface only.
- a project path passed as `?cwd=` — to audit a project other than the
dashboard server's own working directory.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/overview` | `roots` + `counts` for every surface, split `{user,project}` where applicable (skills, agents, commands, outputStyles, plugins, mcpServers, hooks, memory, settingsFiles) |
| `GET /api/cc-config/skills` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/agents` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/commands` | `{ items:[{ scope, name, file, size, mtime, frontmatter, preview }] }` |
| `GET /api/cc-config/hooks` | `{ items:[{ scope, file, exists, hooks:{ <Event>:[{matcher,type,command,timeout}] } }] }` |
| `GET /api/cc-config/settings` | `{ items:[{ scope, file, exists, data(redacted), raw_size }] }` |
## Report Sections
### 1. Surface inventory (user vs project)
From `/overview` `counts`, print a table: one row per surface with `user`,
`project`, and `total` columns. Cover skills, agents, commands, output-styles,
plugins (with enabled/disabled), marketplaces, MCP servers, hooks
(user/project/project-local), memory, and settings files. Echo the resolved
`roots` so the user knows which `claudeHome`/project was inspected.
### 2. Duplicate & overlapping skills + agents
Fetch `/skills` and `/agents`. Detect:
- **Name collisions across scope** — same `name` at both user and project
scope (project shadows user). List both `file` paths.
- **Near-duplicates** — entries whose `frontmatter.description` / `preview`
describe the same job. Group them and recommend keeping one.
### 3. Hooks that run shell commands
Flatten `/hooks` to `(scope, file, Event, matcher, type, command, timeout)`.
Flag every `type: "command"` entry. Within those, escalate ones that contain
network egress (`curl`, `wget`, `http`, `nc`) or run unbounded with no
`timeout`. Print the raw `command` so the user can review it.
### 4. Read-only vs mutable surfaces
State which surfaces the Config Explorer can mutate (skills, agents, commands,
output-styles, user/project CLAUDE.md, and per-project `auto-memory` files via
`PUT`/`DELETE /api/cc-config/file`) versus those that are read-only by design
(plugins, MCP servers, settings.json and its in-file hooks — written
concurrently by the running CLI). Direct cleanup suggestions only at mutable
surfaces; for read-only ones, name the source `file` to edit by hand.
## Output
- A one-line verdict first: CLEAN / SPRAWL DETECTED / RISKY HOOKS.
- Section 1 as a Markdown table (`Surface | User | Project | Total`).
- Section 2 as grouped lists with `file` paths.
- Section 3 as a table (`Scope | Event | Matcher | Command | Risk`).
- Sizes in KB; any cost in USD to 4 decimals; use ▲/▼ for scope deltas.
- Cite only fields the API returned — never fabricate counts or commands.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
@@ -0,0 +1,68 @@
---
description: >
Inventory hooks across the user, project, and project-local settings plus the
~/.claude/hooks scripts directory — read through the Agent Monitor Config
Explorer API — and flag hooks that POST to the network or run arbitrary
commands. Reads /api/cc-config/hooks and /api/cc-config/hook-scripts. Use
when auditing hook safety.
---
# Hook Inventory
Catalogue every Claude Code hook the user has configured and assess its safety —
read through the Agent Monitor dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — inventory all hooks across every scope (default).
- an event name (`PreToolUse`, `PostToolUse`, `Stop`, `SubagentStop`,
`SessionStart`, `SessionEnd`, `UserPromptSubmit`, `Notification`,
`PreCompact`) — restrict to that event.
- "scripts" — focus on the `~/.claude/hooks` handler scripts dir.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/hooks` | `{ items:[{ scope:"user"\|"project"\|"project-local", file, exists, hooks:{ <Event>:[{ matcher, type, command, timeout }] } }] }` |
| `GET /api/cc-config/hook-scripts` | `{ dir, items:[{ name, file, size, mtime }] }` — the handler scripts under `~/.claude/hooks/` |
## Report Sections
### 1. Configured hooks by scope
From `/hooks`, flatten each source into `(scope, file, Event, matcher, type,
command, timeout)`. Group by `scope` (user, project, project-local). Show the
event, matcher, hook `type`, and the raw `command`. Note which `file` each came
from so the user can edit the right one.
### 2. Hook scripts on disk
From `/hook-scripts`, list each file in `~/.claude/hooks/` with `name`, `size`
(KB), and `mtime`. Cross-reference: flag scripts referenced by a hook `command`
but missing from disk, and scripts on disk that no configured hook calls
(orphaned).
### 3. Safety flags
For every `type: "command"` entry escalate:
- **Network egress (P0)** — the command contains `curl`, `wget`, `http`,
`https`, `nc`, or pipes output off-box. Print the destination if visible.
- **Arbitrary execution (P1)** — pipes to `sh`/`bash`, evaluates downloaded
content, or runs an unpinned interpreter on attacker-influenceable input.
- **No timeout (P2)** — a `command` hook with `timeout: null`; it can hang a
session indefinitely.
- **Broad matcher (P3)** — `matcher: "*"` or empty on a destructive command.
## Output
- Section 1 as a table (`Scope | Event | Matcher | Type | Command | Timeout`).
- Section 3 as a findings table (`Hook | Risk | Severity | Detail`) with a
one-line verdict first (SAFE / REVIEW NEEDED / RISKY HOOKS).
- Print raw commands verbatim — do not paraphrase a command you are flagging.
- Cite only fields the API returned — never fabricate hooks or commands.
- Note: hooks live inside settings.json and are read-only via the Config
Explorer; edit them in the `file` named by the source, then reinstall with
the dashboard's hook setup if needed.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
@@ -0,0 +1,65 @@
---
description: >
Audit the configured MCP servers (user + project scope) via the Agent
Monitor Config Explorer API: transport (stdio vs http), command/args and env
variable names, headers, and the source file each definition came from.
Reads /api/cc-config/mcp. Use when reviewing MCP integrations for hygiene,
duplication, or unexpected transports.
---
# MCP Audit
Inventory and audit every Model Context Protocol server the user has
configured — both user-scope and project-scope — read through the Agent Monitor
dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — audit all MCP servers (default).
- a server name fragment — focus on matching servers.
- "stdio" / "http" — restrict to one transport kind.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/mcp` | `{ user:[…], projectScoped:[…] }`. Each server: `{ name, source, kind }` where `kind` is `stdio` (with `command, args, envNames`), `http` (with `url, headers`), or `unknown`. `source` names the file the definition came from (e.g. `~/.claude.json (top-level)`, `~/.claude.json (projects[<root>])`, `~/.claude/settings.json`) |
## Report Sections
### 1. Server inventory
List every server from `user` and `projectScoped`. For each show `name`,
`source`, `kind`, and the transport detail:
- **stdio** — the `command`, its `args`, and the `envNames` (names only — values
are not exposed by the API).
- **http** — the `url` and the `headers` key names (values not exposed).
- **unknown** — a definition the server could not classify; flag it for review.
### 2. Scope split & duplication
Separate user-scope from project-scope servers. Flag any `name` that appears in
both scopes (project may shadow user) and any duplicate definitions across
source files.
### 3. Hygiene flags
- **Unknown transport** — servers with `kind: "unknown"` (malformed or
unsupported definition).
- **Env reliance** — stdio servers with many `envNames`; note they depend on
environment variables being present at launch.
- **Remote endpoints** — http servers; surface the `url` host so the user can
confirm they trust the remote.
## Output
- Section 1 as a table (`Scope | Name | Kind | Transport detail | Source`).
- Env names and header names listed by name only — never invent or print values
(the API does not expose them).
- Cite only fields the API returned — never fabricate servers, commands, or
hosts.
- Note: MCP servers are read-only via the Config Explorer (they are written
concurrently by the running CLI); edit their definitions in the source file
named by `source`.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
@@ -0,0 +1,90 @@
---
description: >
Review the file-based memory store via the Agent Monitor Config Explorer API:
the user and project CLAUDE.md plus per-project auto-memory files under
~/.claude/projects/<slug>/memory/*.md. Groups by project, shows the index
(MEMORY.md) vs per-fact files, and flags stale or oversized facts. Reads
/api/cc-config/memory and /api/cc-config/file?path=. Use when curating agent
memory.
---
# Memory Review
Curate the user's file-based agent memory: the long-form CLAUDE.md files plus
the per-project auto-memory store — read through the Agent Monitor dashboard at
`http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — review the whole memory store across every project (default).
- a project slug (e.g. `-Users-david-WebstormProjects-foo`) — restrict the
review to that one project's auto-memory dir.
- "claude-md" — review only the user/project CLAUDE.md files.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/memory` | `{ items:[…] }`. CLAUDE.md entries: `{ scope:"user"\|"project", file, size, mtime, preview }`. Auto-memory entries: `{ scope:"auto-memory", project, name, isIndex, file, size, mtime, frontmatter, preview }` |
| `GET /api/cc-config/file?path=<abs>` | full body of one file: `{ ok, file, size, mtime, truncated, text }` — use to read a fact in full before recommending an edit |
## Report Sections
### 1. CLAUDE.md overview
List the user and project CLAUDE.md entries with `scope`, `size` (KB), and
last-modified (`mtime`). Note any that are `truncated` (over 256 KB) — these
are oversized and worth splitting into auto-memory facts.
### 2. Per-project auto-memory, grouped
Group `scope: "auto-memory"` items by `project`. For each project show the
**index** (`isIndex: true`, typically `MEMORY.md`) first, then the per-fact
files. For each fact show `name`, `frontmatter.description` if present, `size`,
and `mtime`.
### 3. Index vs per-fact consistency
Within each project, compare the index (`MEMORY.md`) against the per-fact files
present. Flag facts that exist on disk but are not referenced by the index, and
index entries that point at files which no longer appear in `/memory`.
### 4. Stale & oversized facts
Flag facts whose `mtime` is old relative to the rest of the store (stale —
candidates to confirm or retire) and facts whose `size` is large (oversized —
candidates to split into smaller, single-fact files). When the user wants to
act on one, fetch its full body with `GET /api/cc-config/file?path=<file>`
before recommending changes.
## Editing memory (mutations)
Auto-memory files are editable through the Config Explorer. To create/overwrite
a fact:
```bash
curl -s -X PUT http://localhost:4820/api/cc-config/file \
-H 'Content-Type: application/json' \
-d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md","content":"..."}'
```
To delete a fact:
```bash
curl -s -X DELETE http://localhost:4820/api/cc-config/file \
-H 'Content-Type: application/json' \
-d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md"}'
```
A timestamped backup is written automatically before any edit or delete.
The user/project CLAUDE.md uses `type:"memory"` with a `scope` and no `name`.
**Never edit or delete a memory file without explicit per-action confirmation
from the user** — default to read-only review.
## Output
- Section 1 as a short table (`Scope | File | Size | Modified | Truncated`).
- Section 2 grouped by project, index first, then facts.
- Sizes in KB; timestamps as relative age; use ▲ for oversized / stale flags.
- Cite only fields the API returned — never invent facts, names, or sizes.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.
@@ -0,0 +1,66 @@
---
description: >
Inventory the installed skills and which plugins contribute them, then flag
overlap with the user's own skills — read through the Agent Monitor Config
Explorer API. Reads /api/cc-config/skills and /api/cc-config/plugins. Use
when managing skills: deduping, deciding what to keep, or tracing a skill
back to the plugin that ships it.
---
# Skill Inventory
Map every skill available to the user — both their own (user/project scope) and
the ones contributed by installed plugins — read through the Agent Monitor
dashboard at `http://localhost:4820`.
## Input
The user provides: **$ARGUMENTS**
This may be:
- empty — inventory all skills (default).
- a skill name fragment — focus on skills whose `name` matches.
- a plugin name — show only the skills that plugin contributes.
## Data Sources
| Endpoint | Returns |
|----------|---------|
| `GET /api/cc-config/skills` | `{ items:[{ scope:"user"\|"project", name, path, file, size, mtime, frontmatter, preview }] }` — the user's own skill directories |
| `GET /api/cc-config/plugins` | `{ manifestPath, manifestExists, plugins:[{ key, name, marketplace, scope, version, enabled, installPath, contributes:{ skills, agents, commands, outputStyles, hooks } }] }` |
## Report Sections
### 1. User & project skills
From `/skills`, list each skill with `scope`, `name`, `size` (KB), and
`frontmatter.description` (or the start of `preview`). Separate user-scope from
project-scope skills.
### 2. Plugin-contributed skills
From `/plugins`, list each plugin with `enabled` state and its
`contributes.skills` count. Note that `/skills` reports only the user's own
skill dirs — plugin skills are counted via `contributes`, so reconcile: total
available skills ≈ user skills + Σ enabled-plugin `contributes.skills`.
### 3. Overlap & duplication
Flag where a plugin name or a plugin's contributed-skill domain overlaps with a
user-authored skill of the same `name` or purpose (compare against
`frontmatter.description` from `/skills`). Recommend keeping one source of truth
— prefer the plugin version if it is maintained upstream, or the user version
if it is customized.
### 4. Disabled / orphaned plugins
Flag plugins with `enabled: false` (their skills are inert) and any whose
`installPathExists` is false (manifest references a missing install) — these are
dead weight to clean up via the Claude Code plugin manager.
## Output
- Section 1 as a table (`Scope | Name | Size | Description`).
- Section 2 as a table (`Plugin | Enabled | Skills | Agents | Commands`).
- A reconciliation line: user skills + plugin skills = total available.
- Cite only fields the API returned — never fabricate skills or counts.
- Note: plugins are read-only via the Config Explorer; manage them with the
Claude Code plugin commands, not this dashboard.
- If the dashboard is unreachable at `http://localhost:4820`, say so and tell
the user to start it with `npm start` from the repo root.