refactor(marketplace): split cc-architect from ultraplan-local into its own plugin
Extract `/ultra-cc-architect-local` and `/ultra-skill-author-local` plus all 7 supporting agents, the `cc-architect-catalog` skill (13 files), the `ngram-overlap.mjs` IP-hygiene script, and the skill-factory test fixtures from `ultraplan-local` v2.4.0 into a new `ultra-cc-architect` plugin v0.1.0. Why: ultraplan-local had drifted into containing two distinct domains — a universal planning pipeline (brief → research → plan → execute) and a Claude-Code-specific architecture phase. Keeping them together forced users to inherit an unfinished CC-feature catalog (~11 seeds) when they only wanted the planning pipeline, and locked the catalog and the pipeline into the same release cadence. The architect was already optional and decoupled at the code level — only one filesystem touchpoint remained (auto-discovery of `architecture/overview.md`), which already handles absence gracefully. Plugin manifests: - ultraplan-local: 2.4.0 → 3.0.0 (description + keywords updated) - ultra-cc-architect: new at 0.1.0 (pre-release; catalog is thin, Fase 2/3 of skill-factory unbuilt, decision-layer empty, fallback list still needed) What stays in ultraplan-local: brief/research/plan/execute commands, all 19 planning agents, security hooks, plan auto-discovery of `architecture/overview.md` (filesystem-level contract, not code-level). What moved (28 files via git mv, R100 — full history preserved): - 2 commands, 8 agents, 1 skill catalog (13 files), 2 scripts, 8 fixtures Documentation updates: plugin CLAUDE.md and README.md for both plugins, root README.md (added ultra-cc-architect section, updated ultraplan-local section), root CLAUDE.md (added ultra-cc-architect to repo-struktur), marketplace.json (registered ultra-cc-architect), ultraplan-local CHANGELOG.md (v3.0.0 entry with migration guidance). Test verification: ngram-overlap.test.mjs passes 23/23 from new location. Memory updated: feedback_no_architect_until_v3.md now points at the new plugin and reframes the threshold around catalog maturity rather than an ultraplan-local milestone. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
parent
97c5c9d934
commit
ab504bdf8c
48 changed files with 627 additions and 177 deletions
|
|
@ -1,72 +0,0 @@
|
|||
---
|
||||
name: mcp-reference
|
||||
description: Model Context Protocol — external tools and resources exposed to Claude via MCP servers.
|
||||
layer: reference
|
||||
cc_feature: mcp
|
||||
source: https://docs.claude.com/en/docs/claude-code/mcp
|
||||
concept: mcp-tool-protocol
|
||||
last_verified: 2026-04-18
|
||||
ngram_overlap_score: null
|
||||
review_status: approved
|
||||
---
|
||||
|
||||
# MCP — Reference
|
||||
|
||||
Model Context Protocol (MCP) is the protocol Claude Code uses to talk
|
||||
to external tool servers. An MCP server advertises *tools* and
|
||||
*resources*; Claude Code surfaces them to Claude as callable tools.
|
||||
|
||||
## Architecture
|
||||
|
||||
- **MCP server** — a process (local or remote) that implements the
|
||||
protocol. Can be written in any language. Communicates over stdio,
|
||||
HTTP, or WebSocket.
|
||||
- **Transport** — stdio (local subprocess), SSE/HTTP (remote), or
|
||||
WebSocket. Stdio is the default for local servers.
|
||||
- **Tools** — callable functions the server exposes. Each has a name,
|
||||
description, and JSON schema for inputs.
|
||||
- **Resources** — readable entities the server exposes (files,
|
||||
database rows, API responses). Addressed by URI.
|
||||
- **Prompts** — optional; MCP can expose templated prompts.
|
||||
|
||||
## Configuration
|
||||
|
||||
MCP servers are declared in:
|
||||
|
||||
- `.mcp.json` — project-level MCP config.
|
||||
- `~/.claude.json` or equivalent — user-level.
|
||||
- Plugin-bundled — a plugin can ship its own MCP server.
|
||||
|
||||
Each entry specifies command, args, transport, and optional auth.
|
||||
|
||||
## Tool naming
|
||||
|
||||
Tools from MCP servers appear to Claude with a namespaced name:
|
||||
`mcp__<server-name>__<tool-name>`. This keeps names collision-free
|
||||
across servers.
|
||||
|
||||
## Permissions
|
||||
|
||||
- `allowed-tools` in settings or plugin frontmatter can include MCP
|
||||
tools by full name.
|
||||
- Some MCP servers require OAuth or API keys; those are configured in
|
||||
the server's own config, not Claude's.
|
||||
|
||||
## Common uses
|
||||
|
||||
- Exposing internal APIs to Claude without hand-wrapping them (one
|
||||
generic MCP server → many tools).
|
||||
- Cross-language tool servers (Python tool called from Claude Code
|
||||
running in Node).
|
||||
- Sandboxed access to external services with explicit scoping.
|
||||
|
||||
## Failure modes
|
||||
|
||||
- Server not running → tool calls fail; Claude sees an error string.
|
||||
- Server misbehaves → tool returns wrong schema; Claude may retry or
|
||||
hallucinate.
|
||||
- Authentication drift → 401s look like transient errors; diagnose by
|
||||
checking the server directly.
|
||||
- Security: an MCP server runs with the permissions of its own
|
||||
process. A malicious server is a supply-chain risk; audit before
|
||||
enabling.
|
||||
Loading…
Add table
Add a link
Reference in a new issue