/planning-agent-systems

name: planning-agent-systems
description: Plans which agent system components to create or modify, producing a component plan for user confirmation. Use when called by brainstorming-workflows after workflow exploration is complete. Use when user asks to plan agent system components.

Planning Agent Systems

Overview

**Planning agent systems IS mapping workflows to components with explicit rationale.**

Read the analysis report and workflow summary, decide what to create/modify/delete, identify which writing-* skills to invoke, and get user confirmation before execution.

**Core principle:** Every component must trace back to a workflow need or a weakness fix. No speculative components.

Routing

**Pattern:** Chain **Handoff:** user-confirmation **Next:** `applying-agent-systems` **Chain:** main

Task Initialization (MANDATORY)

Follow [task initialization protocol](../../references/task-initialization.md).

**Tasks:** 1. Read inputs 2. Design architecture flowchart 3. Plan components (includes reuse check) 4. Produce component plan 5. Get user confirmation

Announce: "Created 5 tasks. Starting execution..."

Task 1: Read Inputs

**Goal:** Load analysis report (if available) and workflow summary.

**Read:**

• `.rcc/*-analysis.md` (most recent, if exists)
• `.rcc/*-workflows.md` (most recent, if exists)
• `.rcc/*-reflection.md` (most recent, if exists)

**Extract:**

• Weaknesses marked for fixing
• Workflows to support
• Conventions to enforce
• Component recommendations from workflow summary or reflection report
• Learnings and suggested components from reflection report (if available)

**Verification:** Have a clear list of requirements from both sources.

Task 2: Design Architecture Flowchart

**Goal:** Visualize the entire agent system topology before deciding individual components.

**Why this comes first:** Component lists hide dependency gaps and workflow disconnects. A flowchart forces you to see the whole picture — entry points, decision branches, data flow, and handoff points — before committing to any component.

**Important:** Read [references/anthropic-patterns.md](references/anthropic-patterns.md) for the six Anthropic workflow patterns, DOT flowchart conventions, and dependency graph template.

**Step 1 — Classify workflows into Anthropic patterns** using the reference table.

**Step 2 — Draw the architecture flowchart** in DOT format using the reference conventions.

**Step 3 — Build the dependency graph** from the flowchart, assigning phases by dependency depth.

**Step 4 — Check prior learnings** before architecture decisions:

Read past reflection reports (`.rcc/*-reflection.md`) and `.rcc/config.yml` `decisions_log` for known failure modes and prior decisions.

• Match each prior learning against the current design
• Adjust architecture to avoid repeating known failure modes
• Document how each relevant learning is addressed

**Step 5 — Identify the simplest viable subset:**

Ask: "What is the minimum set of components that delivers value?"

• Mark each component as **core** (must-have for any workflow to work) or **enhancement** (improves but not required)
• Phase 1 should contain ONLY core components
• Present the phased rollout to user for early feedback

**Verification:** Architecture flowchart produced showing all workflows, patterns identified, dependency graph built, phases assigned, prior learnings addressed.

Task 3: Plan Components

**Goal:** Decide action for each component type.

**Important:** Read [references/component-planning.md](references/component-planning.md) for the evaluation table, decision criteria, size constraints, and writing skill assignments.

**Use the dependency graph from Task 2** to determine execution order. Do NOT use a fixed order — let dependencies drive sequencing. Components in the same phase with no mutual dependencies can be built in parallel.

**Agent layer ordering — follow this sequence when planning agents:**

1. **Sonnet implementer first** — establish the core implementation agent before anything else. This is the foundation all other layers depend on.

**Implementer capability analysis (MANDATORY before moving on):** Based on what the implementer will do (from the planned workflows), identify what project-specific knowledge it needs that Claude Code does NOT already know:

| Question | If yes, plan this component | |----------|-----------------------------| | Are there non-standard conventions specific to this project/framework? | CLAUDE.md update or scoped rule | | Do file types need different conventions (e.g., API vs. domain model)? | Path-scoped rule per file type | | Should any quality constraint be enforced deterministically (not advisory)? | Hook with exit code 2 | | Are there project-specific gotchas Claude would get wrong without being told? | CLAUDE.md or rule |

**Exclude:** Standard language conventions, general best practices, anything a linter already enforces, anything Claude knows from training. Only plan components that add project-specific signal.

2. **Orchestrator second** — add only if dispatch complexity justifies a dedicated coordinator. If there is only one implementer doing a single job, a separate orchestrator adds overhead without value.

• Use **Haiku** when dispatch is simple: explicit task list, direct assignment, no ambiguity.
• Use **Sonnet** when decomposition requires reasoning: ambiguous requirements, multi-level decisions, dynamic routing.

3. **Opus quality gate / advisor third** — add only if (a) a revision loop exists and (b) the output will be mechanically executable by downstream Sonnet. Without both conditions, skip Opus.

**Safety baseline (MANDATORY check):** Every plan must include or explicitly waive the safety bypass prevention rules. These are baseline defaults, not project-specific additions:

| Rule | Scope | Source | |------|-------|--------| | `git-safety.md` | Global | [writing-rules/references/examples.md](../wr