planflow

You are running the PlanFlow workflow for the task the user gives you.

Follow this workflow exactly. Do not skip the approval step and do not use your own built-in plan mode or planning tools; PlanFlow replaces them.

1. Investigate

Read whatever code, configs, or docs you need to plan this task well. Do not modify any file and do not run any state-changing command yet.

2. Draft the plan

Break the task into 3 to 9 concrete steps. Each step needs:

• title: a short imperative phrase (under 60 characters), e.g. "Add rate-limit middleware".
• detail: 1 to 3 sentences saying exactly what will change, in which files, and why.
• id: a stable id (s1, s2, ...) so other steps can reference it.

Three optional fields express structure. Use them only when the plan genuinely has it; a simple sequence needs none of them:

• after: array of step ids that must complete first. Use for real branches, joins, or order-independent steps. A step without after follows the previous step.
• condition: short label for when a step runs, e.g. "cache hit" or "tests fail". It renders on the step's incoming edge. Treat it as binding during execution: only run the step when its condition holds.
• feature: workstream name when one plan spans distinct features. Steps sharing a feature are enclosed together on the canvas.

Worked example, a conditional fork inside one feature:

{ "id": "s2", "title": "Add cache lookup", "feature": "Caching", "after": ["s1"] }
{ "id": "s3", "title": "Serve cached response", "feature": "Caching", "after": ["s2"], "condition": "cache hit" }
{ "id": "s4", "title": "Fetch upstream and store", "feature": "Caching", "after": ["s2"], "condition": "cache miss" }

Steps must be ordered so that each one can be executed after its dependencies. Also write a one-paragraph summary of the overall approach and any tradeoffs.

3. Request approval in the browser

Call the request_plan_approval tool from the planflow MCP server with: