Additional Concepts : Holding Area, Settings Fragments, and Project Templates

[ckelsoe]

Great job on this project! CCO is exactly the tool this ecosystem was missing. Being able to see everything in one place and move things between scopes has already saved me hours of manual JSON editing. This proposal is meant to build on that foundation — three-phased enhancements that each deliver standalone value.

---

Phase 1: Holding Area Scope

The foundation. A dedicated, inert scope for parking artifacts you want to keep but don't want active.

The problem

Moving an artifact out of a project today means:

• Moving it to Global scope (now it's active everywhere — not what you wanted)
• Moving it to another project (now it's active there instead)
• Deleting it (gone forever, hope you remember how it was configured)

There's no way to say: "Keep this, but don't load it anywhere right now."

The solution

A new scope called Holding at ~/.claude/holding/. It appears as its own section in the CCO dashboard alongside Global and Project scopes. Items in holding are not loaded by Claude Code — they're inert storage. A personal library, not an active scope.

Supported artifact types

Type	Storage location	Notes
Skills	~/.claude/holding/skills/<name>/SKILL.md	Full skill directory
MCP Servers	~/.claude/holding/.mcp.json	JSON entry with all config (type, url, headers, args)
Commands	~/.claude/holding/commands/<name>.md	Command markdown files
Plugins	~/.claude/holding/plugins/<name>/	Plugin directories

Other artifact types (memories, rules, agents) remain in Global/Project scopes only.

Copy and Move

The key differentiator: the holding area supports copy, not just move.

Deploying from holding to a project:

Action	Behavior
Copy to project (default)	Independent copy created in the target project. Holding original preserved.
Move to project	Transferred out of holding into the project.

Ingesting from a project into holding:

Action	Behavior
Move to holding	Removed from project, placed in holding.
Copy to holding	Project copy stays active, backup/template created in holding.

Example workflow

1. Configure an MCP server with auth headers in Project A
2. Copy it to holding — now you have a safe master copy
3. Delete it from Project A when you're done there
4. Six months later, copy it from holding into Project B — no reconfiguration needed

Implementation notes

Scanner (scanner.mjs):

• New scope: id: "holding", type: "holding", name: "Holding Area"
• Scan ~/.claude/holding/ subdirectories for each supported type
• Visual indicator on items (tag: "holding") for UI styling

Mover (mover.mjs):

• New copyItem() function — mirrors moveItem() but skips the delete-from-source step
• resolveHoldingDir() functions for each artifact type
• validateMove() rejects unsupported types moving to holding

UI (app.js):

• Holding area as a dedicated dashboard section
• Drag-and-drop in/out works like other scopes
• Dragging OUT of holding prompts "Copy" (default) or "Move"
• Distinct visual treatment (muted color, archive icon, or "template" badge)

What the holding area is NOT

• Not a backup system — it's a manually curated library
• Not synced or versioned — local flat files like everything else in ~/.claude/
• Not a replacement for Global — Global items are active everywhere; Holding items are active nowhere

---

Phase 2: Settings Fragments

Extends holding with reusable configuration snippets that merge into project settings.

Depends on: Phase 1 (uses the holding area for storage)

The problem

Some settings are project-specific but repetitive. Configuring planStorage to use a local .plans/ folder is useful across many projects, but you have to manually edit each project's .claude/settings.json. There's no way to save a setting once and stamp it wherever you need it.

The solution

Named JSON fragments stored in holding that can be merged into any project's settings.json on demand.

Storage format

~/.claude/holding/settings-fragments/
├── plans-local-folder.json
├── strict-permissions.json
└── custom-hooks-bundle.json

Each fragment:

{
  "name": "Local plans folder",
  "description": "Store plans in project .plans/ directory instead of ~/.claude/projects/",
  "fragment": {
    "planStorage": {
      "type": "project",
      "path": ".plans"
    }
  }
}

Operations

Action	Behavior
Apply to project	Deep-merges the fragment into the target project's .claude/settings.json. Creates the file if needed. Original preserved.
Preview	Shows a diff of what the merge would produce before applying.
Remove from project	Strips the fragment's keys from the project's settings (undo).

Why fragments, not full settings files

• Fragments are additive — they merge, they don't replace
• A project can have multiple fragments applied (e.g., "local plans" + "strict permissions")
• Each fragment is small and single-purpose — easy to understand at a glance
• Optional: the holding area tracks which fragments are applied where

Example fragments

Fragment	What it configures
plans-local-folder	planStorage.type: "project", planStorage.path: ".plans"
strict-tool-permissions	permissions.allow: [], permissions.deny: ["Bash(*)", "Write(*)"]
auto-compact-aggressive	autoCompact: true, autoCompactThreshold: 60
custom-model-defaults	model: "claude-sonnet-4-6", smallModel: "claude-haiku-4-5"
hook-bundle-linting	hooks.preToolCall: [{ "command": "eslint ...", "blocking": true }]

---

Phase 3: Project Templates

Extends holding with named bundles that deploy a full project setup in one click.

Depends on: Phase 1 (artifacts to bundle), optionally Phase 2 (settings fragments in bundles)

The problem

Even with a holding area full of great configs, setting up a new project means manually copying 5-10 items one at a time. Every React project needs the same set of skills, MCP servers, and settings. Every Node API project needs a different set. The selection is repetitive and error-prone.

The solution

Named templates that reference items in the holding area. Pick a template, pick a target project, one click — everything gets copied in.

Storage format

~/.claude/holding/templates/
├── react-project.json
├── node-api-project.json
└── security-audit.json

Each template:

{
  "name": "React Project",
  "description": "Standard setup for React frontend projects",
  "items": [
    { "type": "skill", "name": "frontend-design" },
    { "type": "skill", "name": "webapp-testing" },
    { "type": "mcp", "name": "Playwright" },
    { "type": "mcp", "name": "Pencil" },
    { "type": "command", "name": "component-scaffold" },
    { "type": "settings-fragment", "name": "strict-permissions" },
    { "type": "settings-fragment", "name": "plans-local-folder" },
    { "type": "plugin", "name": "eslint-integration" }
  ]
}

UI workflow

1. Create — In holding, check boxes next to items → "Save as Template" → name it
2. Apply — Select a project → "Apply Template" → pick template → preview → confirm
3. Edit — Add/remove items, rename, update description
4. Report — After applying, shows what was copied and flags conflicts ("Skill X already exists — skipped")

Dashboard mockup

┌─────────────────────────────────────────────────────┐
│  HOLDING AREA                                       │
├─────────────────────────────────────────────────────┤
│  Templates:                                         │
│  ┌──────────────┐ ┌──────────────┐ ┌─────────────┐  │
│  │ React Project│ │ Node API     │ │ Security    │  │
│  │ 7 items      │ │ 5 items      │ │ Audit       │  │
│  │ [Apply v]    │ │ [Apply v]    │ │ 4 items     │  │
│  └──────────────┘ └──────────────┘ │ [Apply v]   │  │
│                                    └─────────────┘  │
│  Items:                                             │
│  [ ] skill/frontend-design                          │
│  [ ] skill/webapp-testing                           │
│  [ ] mcp/Playwright                                 │
│  [ ] mcp/Pencil                                     │
│  [ ] command/component-scaffold                     │
│  [ ] settings/strict-permissions                    │
│  [ ] settings/plans-local-folder                    │
│  [ ] plugin/eslint-integration                      │
│                     [Save Selection as Template]    │
└─────────────────────────────────────────────────────┘

Behavior

• Templates always copy from holding (never move) — holding is the source of truth
• Missing items are flagged and skipped during apply
• Templates are lightweight references (name + type), not duplicates of artifacts
• Applying is idempotent — existing items in the target project are skipped with a notice

---

Full directory structure (all phases)

~/.claude/cco-holding/
├── .mcp.json                    # Phase 1: MCP server templates
├── skills/                      # Phase 1: Skill directories
│   ├── my-custom-skill/
│   │   └── SKILL.md
│   └── another-skill/
│       └── SKILL.md
├── commands/                    # Phase 1: Command files
│   └── my-command.md
├── plugins/                     # Phase 1: Plugin directories
│   └── my-plugin/
│       └── plugin files...
├── settings-fragments/          # Phase 2: Settings snippets
│   ├── plans-local-folder.json
│   ├── strict-permissions.json
│   └── custom-hooks-bundle.json
└── templates/                   # Phase 3: Project bundles
    ├── react-project.json
    ├── node-api-project.json
    └── security-audit.json

[ithiria894]

Thanks for the detailed proposal — the three-phase structure is well thought out and clearly a lot of work went into this. Really appreciate you thinking this deeply about where CCO could go.

I want to push back on the Phase 1 premise though, because I think the gap is narrower than it appears.

MCP servers and plugins already have disabled

MCP servers support "disabled": true in their config (.mcp.json / .claude.json). When disabled, Claude Code doesn't register the server's tools into the tool list — the config stays in the file but the tools don't appear and don't consume context tokens (~3100 tokens per server for tool schemas).

Importantly, MCP servers are on-demand by design — the server process only starts when you actually call one of its tools. So disabled doesn't mean "don't start the server" (it wouldn't start anyway until called). It means "don't register the tools at all." The config entry is preserved, the server is invisible to Claude, and you can re-enable it anytime by removing the flag.

Plugins similarly support a disabled field.

So for these two artifact types, the "keep but don't load" use case is already solved — no need for a separate scope.

The real gap: skills and commands

Skills and commands don't have a disable mechanism — if the file exists in the right directory, Claude Code loads it. That's a real gap.

But this is an upstream question for Anthropic (Claude Code itself), not something CCO can solve. CCO is a read/organize layer — we scan what's on disk and let you move it between scopes. We don't control Claude Code's loading behavior. If Anthropic adds a disabled convention for skills/commands in the future (e.g., a frontmatter flag or a naming convention like SKILL.md.disabled), CCO would surface it automatically.

Why I'm hesitant about a holding scope

Introducing a new scope (holding area, copy vs move semantics, new UI section) is significant added complexity. And it would only benefit the artifact types that don't already have disabled — which is skills and commands. That's a narrow gap to justify a whole new architectural concept.

I'd rather wait for one of:

• More users hitting this pain point
• Anthropic adding upstream disable support for skills/commands
• A compelling use case I haven't considered

Phases 2 and 3

Settings fragments is an interesting idea, but the merge logic (conflicts, key ordering, undo/rollback) has a lot of edge cases that would need careful design. Project templates depend on Phase 1. I'd want to see organic demand before committing to either.

Your bug reports on #11 and #12 already made a real impact — the fixes shipped in v0.10.3, and #17 (path resolution) just shipped today in v0.10.4. Keep the ideas coming.

[ckelsoe]

Hi, Thanks for your reply, and I understand your point of view. My desire for the holding concept is to give me a place to stash MCP Servers I use occasionally, without them being live on any project. My current workaround is to create a project and add those MCP servers to it. I do this so I do not have to reconfigure every time I need to use that MCP.

[ithiria894]

That said — this is just how I'm seeing it right now, and I could be missing something. Is there a use case you're hitting where the disabled toggle doesn't cover what you need? Or a scenario where you specifically need the config moved out of the project directory entirely, rather than just toggled off in place?

Curious to hear your perspective — you've clearly spent more time thinking about the workflows here than I have.