Feature request: local components manager dashboard with inventory, safe uninstall, and uninstall history

Summary

Add a local components manager dashboard that starts a localhost server and lets users view and safely manage all Claude Code Templates components installed on their machine/project.

The CLI already supports installing individual components (--agent, --command, --mcp, --setting, --hook, --skill, --workflow) and has existing local dashboards such as analytics, plugins, and skills manager. A unified local manager would make installed components discoverable and reversible after installation.

Problem

After installing components, users currently do not have a single place to answer questions like:

• What Skills, Agents, Commands, MCPs, Hooks, Settings, Plugins, and Workflows are installed locally?
• Where was each component installed: project, local, user, enterprise, or plugin scope?
• Was this component installed by claude-code-templates or added manually?
• What files or config keys belong to this component?
• Can I safely uninstall it without damaging unrelated Claude Code configuration?
• Can I audit what was previously uninstalled?

This is especially important for MCPs, Hooks, and Settings because they are merged into config files rather than installed as isolated files.

Proposed solution

Add a new local dashboard command, for example:

npx claude-code-templates@latest --components
# or
npx claude-code-templates@latest --local-manager

The command would start a local server bound to 127.0.0.1 by default and show a unified inventory of installed:

• Skills
• Agents
• Commands
• MCPs
• Hooks
• Settings
• Plugins
• Workflows, if applicable

For each item, show metadata such as:

• component type
• name/id
• source path
• install scope: project, local, user, enterprise, plugin
• installed files and/or config keys
• known vs unknown provenance
• last modified time
• available actions

Safe uninstall support

The dashboard should support uninstalling components from the UI, with conservative behavior:

• show a preview of files/config keys that will be removed
• require confirmation before destructive actions
• back up affected files before mutation
• remove only files or config keys known to belong to the selected component
• avoid deleting unrelated manually edited config
• support dry-run logic internally

Simple file/directory removals could include:

• Agents: .claude/agents/<name>.md
• Commands: .claude/commands/<name>.md
• Skills: .claude/skills/<name>/
• Workflows: .claude/workflows/<name>.yaml

Config-based removals need extra care:

• MCPs: remove only specific mcpServers.<name> entries from .mcp.json
• Hooks: remove only matching hook entries and optional installed hook scripts
• Settings: remove only keys that were installed by the component when provenance is available

Installation manifest

To make future uninstalls safe, the CLI could record installs in a manifest, for example:

{
  "version": 1,
  "installed": [
    {
      "id": "development-team/frontend-developer",
      "type": "agent",
      "name": "frontend-developer",
      "source": "github",
      "installedAt": "2026-06-01T00:00:00.000Z",
      "scope": "project",
      "files": [".claude/agents/frontend-developer.md"],
      "configKeys": [],
      "installerVersion": "1.x.x"
    }
  ],
  "uninstallHistory": []
}

Possible manifest locations:

• project scope: .claude/claude-code-templates-manifest.json
• user/global scope: ~/.claude/claude-code-templates-manifest.json

Uninstall history

Uninstall operations should be logged instead of silently disappearing:

{
  "componentId": "development-team/frontend-developer",
  "type": "agent",
  "name": "frontend-developer",
  "uninstalledAt": "2026-06-01T00:00:00.000Z",
  "removedFiles": [".claude/agents/frontend-developer.md"],
  "modifiedConfigFiles": [],
  "backupPath": ".claude/backups/..."
}

This would help with auditing, debugging, and future restore workflows.

Legacy installs

For components installed before the manifest exists, the dashboard can still scan known Claude Code paths and mark provenance as unknown.

Suggested behavior for unknown provenance:

• allow simple file/directory uninstall with a stronger warning
• require extra confirmation for config-based removals
• optionally offer an "import into manifest" action

Security considerations

Because this feature exposes write operations through a local web UI, it should:

• bind to 127.0.0.1 by default
• avoid exposing destructive endpoints remotely
• require explicit confirmation for uninstall
• create backups before modifying config files
• avoid following arbitrary paths outside expected Claude configuration directories
• clearly distinguish known-provenance installs from scanned/manual items

Acceptance criteria

• A local dashboard lists Skills, Agents, Commands, MCPs, Hooks, Settings, Plugins, and relevant Workflows in one place
• Future installs are recorded in a local manifest with files/config keys and install scope
• Supported components can be safely uninstalled from the UI
• Uninstall operations are written to uninstall history
• Existing installs without manifest provenance are still shown as scanned/unknown
• Config files are backed up before modification

Why this fits the project

This builds on existing local dashboard patterns and current component installation support. It would make claude-code-templates feel more complete as a component manager, not only an installer, while reducing risk for users who experiment with many templates/components.