What It Does

Takes a batch of tickets and produces concrete implementation plans with confidence ratings by spawning parallel planning agents. Planning only. No implementation.

The Pattern

The workflow separates planning from execution. Before any code gets written, every ticket gets a verified plan with clear confidence levels and identified unknowns.

Step 1: Collect candidates. Pull tickets from a queue (e.g., "Ready To Go" status). Fetch full details for each, not just titles. Truncated descriptions cause bad plans.

Step 2: Filter exclusions. Remove tickets that shouldn't be auto-planned: compliance work, regulatory changes, anything requiring legal review. Scan titles and descriptions for exclusion keywords.

Step 3: Spawn parallel planners. One planning agent per ticket, all running simultaneously. Each agent gets:

• The full ticket description
• Access to the target codebase (read-only)
• A structured planning prompt requiring specific outputs

The planning prompt requires:

1. Verify exact files and locations in the repo (don't guess)
2. Identify specific code sections requiring changes
3. Define new functions/methods/classes with example signatures
4. List dependencies and import updates needed
5. Flag side effects and architectural impacts
6. Call out unknowns and blockers

Step 4: Rate confidence. Each plan gets a confidence score:

• High: Exact files verified, dependencies clear, no product ambiguity
• Medium: 1-2 unknowns remain (config, external system, or product rule)
• Low: Missing entry points, unclear ownership, or external dependencies dominate

Step 5: Synthesize. Compile results into a table: Ticket, Plan Summary, Confidence, Known Unknowns. For anything below High confidence, state exactly what information would raise it.

Concurrency management matters. Keep a cap on simultaneous agents (6 is a practical limit). Close planning agents before spawning worker agents. If you need more throughput, batch: 6 planners, close, 6 more.

Key Decisions

Read-only planners. Planning agents only read the codebase. They never write files. This makes them safe to run in parallel without coordination concerns.

Confidence drives decisions. High-confidence tickets can go straight to automated implementation. Medium needs one clarification. Low needs human input before any code gets written.

Full ticket details, not summaries. Always fetch the complete ticket body, not the truncated list view. Planner quality correlates directly with input quality.

Explicit verification. Planners must prove they found the actual files and code locations, not just guess based on naming conventions. This catches mismatches between ticket descriptions and codebase reality.

When to Use It

• Scoping a sprint or batch of work before committing to implementation
• Assessing how many tickets could realistically be automated
• Building implementation specs that multiple developers (or agents) can execute independently
• Identifying blockers and unknowns before they surface during coding