Kjell Tore Guttormsen ab504bdf8c 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>

2026-04-30 17:18:47 +02:00

3.1 KiB

Raw Blame History

name	description	layer	cc_feature	source	concept	last_verified	ngram_overlap_score	review_status
subagents-reference	CC subagents — how the Task tool spawns isolated agent instances with scoped tools and context.	reference	subagents	https://docs.claude.com/en/docs/claude-code/sub-agents	task-tool-delegation	2026-04-18	null	approved

Subagents — Reference

Subagents are fresh Claude instances spawned via the Task tool. Each receives a task prompt, a tool subset, and no memory of the parent conversation except what the parent explicitly passes. They return a single final message to the parent.

Anatomy

A subagent has:

A name — either a built-in type (general-purpose, Explore, Plan) or a plugin-defined type (code-reviewer, test-runner, ...).
A system prompt — defined by the agent type. The parent cannot override it.
A tool set — subset of the parent's tools, as declared in the agent definition's frontmatter tools: field.
A task prompt — what the parent asks it to do. Self-contained; the subagent has no access to prior messages.
A model — either explicit in the agent definition (model: opus | sonnet | haiku) or inherited from the parent.

How to define a subagent

A plugin agent is a markdown file in agents/ with frontmatter:

---
name: code-reviewer
description: <when to invoke, include examples>
model: sonnet
tools: ["Read", "Grep", "Glob"]
---

<system prompt content>

The description field is how Claude decides when to spawn this subagent. Include concrete trigger examples.

How to invoke

Parent calls the Task / Agent tool with:

subagent_type — the agent's name
description — short label for logs
prompt — the self-contained task

Optional:

run_in_background: true — agent runs in the background; parent is notified on completion.
isolation: "worktree" — agent runs in a temporary git worktree (isolated copy of the repo).

Return protocol

Foreground agent: parent blocks until the agent returns. Return value is a single text message.
Background agent: parent continues. On completion, the harness injects a notification into the parent's next turn.

Isolation guarantees

No conversation history sharing. Each subagent starts cold.
Separate context window. A subagent can read large files without polluting the parent's context.
Separate tool permissions. A subagent with only Read tools cannot write files, even if the parent can.

Cost and latency

Every subagent call is a full model call with its own token budget.
Model choice matters: Sonnet is ~5× cheaper than Opus; Haiku is cheaper still but cannot be used (per project policy).
Parallel subagents: the parent can launch multiple in one message; the harness runs them concurrently. Total latency ≈ slowest agent.

Failure modes

Subagent hits context limit → partial or missing return.
Subagent runs in background and the parent conversation ends → result may be orphaned.
Subagent's return message hallucinates file paths → caller must verify.

3.1 KiB Raw Blame History Unescape Escape