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:
@@ -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.
|
||||
Reference in New Issue
Block a user