open/ktg-plugin-marketplace
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity Actions
ktg-plugin-marketplace/plugins/ultra-cc-architect/skills/cc-architect-catalog/plan-mode-reference.md
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

2.3 KiB
Raw Blame History

name description layer cc_feature source concept last_verified ngram_overlap_score review_status
plan-mode-reference CC plan mode — read-only planning phase before implementation, with explicit user approval gate. reference plan-mode https://docs.claude.com/en/docs/claude-code/plan-mode planning-before-execution 2026-04-18 null approved

Plan Mode — Reference

Plan mode is a built-in state where Claude operates read-only and produces an implementation plan instead of executing it. The user reviews the plan, then either approves it to transition to implementation or iterates.

State machine

  1. Plan mode entered — user triggers it (Shift+Tab twice, /plan, or harness-initiated) or Claude calls EnterPlanMode.
  2. Read-only operation — Claude can read files, search, run analysis. Writes, edits, and commits are blocked by the harness.
  3. Plan produced — Claude presents a plan via ExitPlanMode or equivalent.
  4. User reviews — accepts, rejects, or iterates.
  5. Exit — on acceptance, mode returns to normal (edits allowed).

What plan mode guarantees

  • No writes during the plan phase. Even if Claude tries, the harness denies write tools.
  • A structured handoff: the plan is a message the user sees before anything happens.

What plan mode does not guarantee

  • Plan quality. Plan mode is a gate, not a reviewer. A bad plan still passes if the user approves it.
  • Scope locking. After exit, Claude can do whatever the new prompts ask — plan mode is a phase, not a contract.

When to opt into plan mode

  • Tasks touching multiple files or modules where the order and file list matter.
  • Refactors where the first wrong edit is expensive to undo.
  • Unfamiliar codebases where planning surfaces missing context.

When to skip plan mode

  • Single-file trivial changes.
  • Tasks already specified by a detailed plan from another tool (e.g., an ultraplan-local plan.md) — planning twice is waste.

Relationship to /ultra* planning

  • /ultraplan-local produces a plan artifact that outlives the session. Plan mode produces an in-conversation plan that does not survive /clear.
  • They compose: use plan mode to sketch at session start, then run /ultraplan-local to get the durable, reviewable, machine-readable plan with manifests.