Concise Planning

Concise Planning

Goal

Turn a user request into a single, actionable plan with atomic steps.

Workflow

1. Scan Context

• Read README.md, docs, and relevant code files.
• Identify constraints (language, frameworks, tests).

2. Minimal Interaction

• Ask at most 1–2 questions and only if truly blocking.
• Make reasonable assumptions for non-blocking unknowns.

3. Generate Plan

Use the following structure:

• Approach: 1-3 sentences on what and why.
• Scope: Bullet points for "In" and "Out".
• Action Items: A list of 6-10 atomic, ordered tasks (Verb-first).
• Validation: At least one item for testing.

Plan Template

# Plan

<High-level approach>

## Scope

- In:
- Out:

## Action Items

[ ] <Step 1: Discovery>
[ ] <Step 2: Implementation>
[ ] <Step 3: Implementation>
[ ] <Step 4: Validation/Testing>
[ ] <Step 5: Rollout/Commit>

## Open Questions

- <Question 1 (max 3)>

Checklist Guidelines

• Atomic: Each step should be a single logical unit of work.
• Verb-first: "Add...", "Refactor...", "Verify...".
• Concrete: Name specific files or modules when possible.

Outputs & Deliverables

• Primary Output: A single plan.md following the Plan Template
• Secondary Output: Open questions and assumptions list
• Success Criteria: Plan has atomic action items and at most 3 blocking questions
• Quality Gate: Plan reviewed and approved by requester or implementer

Constraints

• Technical Constraints: Do not implement code in this step; produce a plan only.
• Scope Constraints: Plans should be limited to the requested scope; avoid speculative features.
• Governance Constraints: Align plan with project-context.md and spec.md if present.

Common Pitfalls

• Over-Planning: Creating 30+ atomic steps when 6-10 suffice. Keep it concise; details emerge during execution.
• Vague Action Items: "Implement feature" isn't actionable. "Add payment processing to checkout flow" is specific.
• Missing Validation Steps: A plan without testing/verification sets up for rework. Always include a validation checkpoint.
• Ignoring Dependencies: Listing steps in random order instead of respecting precedence. Steps must be executable in sequence.
• Scope Creep: Including "nice-to-haves" in the main plan. Use "Out of Scope" section to acknowledge but exclude them.
• Assuming All Context: Not reading existing code/docs leads to redundant or conflicting plans. Always scan context first.

Integration Points