Planning Agent Systems

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.

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 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 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:

Pair with reflecting skill's safety_bypass event detection for prevent-detect-learn loop. If the user already has equivalent global rules in ~/.claude/rules/, note them in the plan as "inherited — no project-level duplicate needed". If the user waives safety rules, record the justification explicitly.

Verification: Each planned component has a traced rationale and assigned writing-* skill. Agent layers follow the ordering above. Implementer capability analysis completed. Safety baseline resolved (planned, inherited, or explicitly waived). No conflicts identified.

Task 4: Produce Component Plan

Goal: Write structured plan to .rcc/{timestamp}-plan.md.

Important: Read references/plan-template.md for the full plan format including architecture flowchart, pattern mapping, dependency graph, and component sections.

Verification: Plan written with complete execution order and traceability.

Task 5: Get User Confirmation

Goal: Present plan and get explicit approval.

Present the FULL plan to user. Show: architecture flowchart, pattern mapping, dependency graph with phases, each component's purpose and content, weakness fixes, core/enhancement classification, and estimated scope per phase.

Anti-pattern: Listing component names without explaining what they do is NOT presenting.

Ask: "Does this plan look good? Ready to start building components?"

Handoff: After user confirms → invoke applying-agent-systems skill, pass plan path

Verification: User has reviewed the full plan and explicitly approved.

Red Flags - STOP

These thoughts mean you're rationalizing. STOP and reconsider:

• "Skip the flowchart"
• "Create everything"
• "Skip traceability"
• "Skip confirmation"
• "Skip reuse check"
• "One big rule"
• "Fixed order is fine"

Common Rationalizations

References

• references/anthropic-patterns.md — Six Anthropic workflow patterns, DOT conventions, dependency graph template
• references/component-planning.md — Evaluation table, decision criteria, size constraints, writing skills
• references/plan-template.md — Full component plan document format