Visual Plan

Agent-Native Plans

Agent-Native Plans is structured visual planning mode for coding agents. Build the plan you would normally write in Markdown, but as a scannable document with editable blocks mixed in: inline diagrams, code snippets, open questions, and an optional top visual review area (wireframe canvas, live prototype, or both in tabs). Architecture and backend plans stay document-only; UI and product plans start with the top canvas/prototype (the Visual Surface Choice section owns that rule).

/visual-plan is the packaged command and main entry point. Choose the review mode from the task: UI-first when the work is primarily product UI and review should start with screens, prototype-first when review should start with a functional live prototype, design-first when review needs full-fidelity branded screens, or visual-intake when the user explicitly wants a questionnaire before planning. When a Codex, Claude Code, Markdown, or pasted plan already exists, /visual-plan uses that source plan as the starting point and builds the review surface from it instead of starting over.

When To Use

Create or adapt a visual plan whenever the plan would be better as a reviewable artifact than a chat paragraph. This includes modest work such as a single UI surface with states, a small workflow, a before/after product change, or a component/API/data-shape decision that needs alignment, plus larger multi-file, ambiguous, long-running, risky, or UI-heavy work. Use it when architecture / data flow / UI direction / options / open questions would benefit from inline diagrams or structured blocks, when the user needs to react to a direction before you implement, or when an existing text plan needs a richer review surface.

Plan Discipline

• Gate thoughtfully. A visual plan is a richer review surface, not only a

tool for giant projects. Use it when the user needs to see, compare, comment on, or approve a direction before code, even for a modest UI/state/workflow change. Skip it for truly trivial, unambiguous work — typos, one-line fixes, a single well-specified function, anything whose diff you could describe in one sentence — and just make the change. Never pad a plan with filler and never ship a single-step plan.

• Research before you draft. Read the real files, actions, schema, and

patterns first; name actual files, symbols, and data shapes instead of inventing them. Check existing actions/ before proposing endpoints and prefer named client helpers over raw fetch. Delegate wide exploration to a sub-agent. Lead with reuse: for each step, name what it reuses — existing actions, schema, components, helpers — before what it adds, so the plan explains the genuinely new delta instead of redescribing what already exists.

• Decide the hard-to-reverse bets first. For non-trivial backend, data, or API

work, sketch where the feature is headed, then call out the decisions that are expensive to undo once data or callers depend on them — wire format, public ids, data-model shape, auth and ownership boundaries — and get those right in the plan even if most of the feature ships later. Then scope to the smallest first cut that proves the approach without foreclosing it, stating both what is in and what is explicitly deferred.

• Keep examples at the right altitude. When the user's idea is a broad

framework, product, or operating-model change, do not collapse it into the first concrete example, provider, or sync path they mention. Separate the core abstraction from motivating examples and app/provider adapters. Use examples to make the plan legible, but label them as examples unless they are the whole requested scope.

• Publish standalone plans. If the user pasted, referenced, or already has a

Codex / Claude Code / Markdown plan, treat it as source material, but rewrite the published plan as a clean standalone proposal. Preserve the source plan's useful intent and codebase facts, label inferred visuals as inferred, and avoid revision language such as "preserve the prior plan", "do not drop the old idea", "unlike the previous version", or "this revision changes...". A reader who never saw the chat or earlier drafts should understand the plan.

• Make the first read concrete. If the plan is meant to be shared with

someone outside the chat, or if the concept is abstract, lead near the top with one concrete product example before mode tables, architecture, or roadmaps. For UI-capable concepts, that usually means a top-canvas app state that shows the real user workflow in product terms. Do not rely on phrases that only make sense in conversation, and do not frame the plan as "not the old idea"; state the positive model directly.

• Planning is read-only. Make no source edits while building or reviewing the

plan. Start editing only after the user approves the direction.

• Clarify vs. assume. Do not ask how to build it — explore and present the

approach and options in the plan. Ask a clarifying question only when an ambiguity would change the design and you cannot resolve it from the code; use the host agent's normal ask-user-question flow and batch 2-4 high-leverage questions before finalizing. Do not call create-visual-questions for ordinary clarification or preflight; reserve it for the visual-intake mode when the user explicitly asks for a visual intake questionnaire. Otherwise state the assumption explicitly and proceed, and keep anything unresolved in the plan's single bottom question-form Open Questions block. For complex plans, do a final open-question pass before handoff: if a decision would affect architecture, scope, UX, data shape, or rollout, either decide it in the plan with rationale or put it in that bottom form with a recommended default.

• The plan is the approval gate. After surfacing it, ask the user to review

and approve before you write code, and name which files/areas the work touches. Presenting the plan and requesting sign-off is the approval step — do not ask a separate "does this look good?" question.

• The document is the source of truth, not the chat. When scope shifts,

update the plan with update-visual-plan rather than only changing course in chat, and make the updated document stand alone. Do not describe the update as a correction to an earlier draft inside the plan itself. Re-read the approved plan before major steps.

Create A Structured Agent-Native Plan — Never Inline

The deliverable is ALWAYS a structured Agent-Native Plan, not a chat-only plan. The hosted Plan MCP connector (plan server, or legacy agent-native-plans) is the default collaboration and commenting surface; it is not a reason to reject the planning pattern as an external dependency or rented layer. Plans are portable source artifacts (plan.mdx, optional canvas.mdx / prototype.mdx, JSON, and HTML export), and ownership-sensitive workflows can use local-files mode or a self-hosted/custom Plan app URL without abandoning the skill's review discipline. Do not advise the user to skip /visual-plan because the default surface is hosted; choose the right Plan mode for the user's ownership, privacy, sharing, and branding needs.

By default, create the plan via the Plan MCP connector and NEVER hand it over as inline chat content — no Markdown prose, ASCII sketch, table, or fenced wireframe. If the plan (or legacy agent-native-plans) tools are not visible, discover them through the host's tool_search first; if they are still missing, STOP and give the user the client-specific reconnect step rather than improvising an inline plan. Before publishing, or whenever a connector or auth error appears, READ references/connection.md in this skill directory — it is the single source of truth for the never-inline rule, connector discovery, and the per-client reconnect steps. Local-files privacy mode (after Tool Guidance) is the exception.

Core Workflow

This section describes the default hosted Plan MCP workflow. If AGENT_NATIVE_PLANS_MODE=local-files is set, or the user asks for fully local files/no hosted Plan writes, use Local-Files Privacy Mode instead; carry forward only the code-research and plan-composition guidance here.

1. Follow the host agent's normal planning flow: inspect the codebase, delegate

wide exploration when useful, gather the info needed, and ask native clarifying questions as needed before generating the plan. If a source plan already exists, gather its exact text from the user's paste, a referenced file, or recent visible agent context; do not invent source text.

1. Call get-plan-blocks for the authoritative block catalog — do not author

from memorized tags. Then call the mode-matched create tool: create-visual-plan for document-first plans (architecture, backend, data, refactor, API), create-ui-plan for UI-first plans, create-prototype-plan for prototype-first plans, create-plan-design for design-first plans, create-visual-questions only when the user explicitly asks for a visual intake questionnaire. When a source plan already exists, pass it as planText and preserve the original plan's useful intent while producing a standalone plan document, not a revision memo.

1. For UI/product plans, compose the top canvas first with the primary

wireframes and annotated states, then write the document with native blocks (see references/canvas.md and references/document-quality.md). For broad product architecture plans with a user-facing implication, add a concrete "what this looks like in the app" visual before the abstract architecture or mode tables. Keep the document close to the standalone Markdown plan the agent would normally output. If an existing plan was provided, carry forward the right facts and decisions without referring to the previous draft or explaining how this version differs. For non-visual plans, skip the top visual surface (Visual Surface Choice below owns the rule) and put diagram, data-model, api-endpoint, diff, file-tree, code, and annotated-code blocks directly next to the relevant prose. Wide document layout is renderer-owned and intentionally allowlisted: only literal code-review surfaces (diff, annotated-code) and tabs blocks with vertical orientation or diff-like children break out wider than prose. Keep api-endpoint, openapi-spec, data-model, json-explorer, wireframe, question, and custom-html blocks in normal document flow unless their own renderer says otherwise.

1. Surface the returned Plans link or inline MCP App and ask the user to review.

Always include the actual URL in chat so the next step is a click in CLI or other text-only hosts. When the host exposes an embedded browser/preview panel and a tool can open arbitrary URLs there, open the returned plan URL automatically for convenient review — a convenience and smoke test, never the only handoff or the access model. Plans should load out of the box for the local agent and local browser session; if a signed-in embedded browser cannot read a local plan that an anonymous/tool check can read, fix the app/action ownership or access path rather than patching one plan by hand. For high-stakes plans (architecture, backend, data, multi-file, or risky), also kick off the self-review pass in Self-Review Before Handoff while the user reads, instead of blocking the handoff on it.

1. For hosted plans, call get-plan-feedback before editing, after review,

after any long pause, and before the final response. Treat anchorDetails, resolver intent, recent review events, and any focused screenshots from browser handoff as the source of truth for exactly what changed and exactly what each comment points at.

1. For hosted plans, apply changes with update-visual-plan, preferring

targeted contentPatches. Treat the top-level content payload as a full replacement, not a merge; do not send a partial content object to add a canvas or one block. If a full replacement is unavoidable, first read the complete plan source/content, carry forward every existing block and visual surface, and verify the source/export afterward so the document body was not truncated. When the user wants source-control friendly edits, use patch-visual-plan-source against the MDX files instead of regenerating the plan.

1. For hosted plans, export with export-visual-plan only when the user wants a

shareable receipt or repo-check-in artifacts.

Self-Review Before Handoff

For high-stakes plans — architecture, backend, data-model, migration, multi-file, or otherwise risky work — run one adversarial self-review pass before treating the plan as final. Skip it for small, UI-only, or single-decision plans where the cost outweighs the value. Keep the pass cheap and non-blocking:

• Surface the plan first, review concurrently. Post the link and let the user

start reading, then run the review in parallel — never make the user wait on it.

• Review the written plan; do not re-research. Critique the plan text and its

own blocks. The grounding was already done while drafting, so the review checks the output instead of re-exploring the repo.

• Spawn one skeptical reviewer whose only job is to find what is weak, missing,

or wrong — not to praise. Point it at: hard-to-reverse decisions made implicitly or not at all (wire format, public ids, data-model shape, auth, ownership); steps not anchored in real files or symbols; a menu of options where the plan should commit to one; obvious missing decisions ("what happens when X?", "why not Y?"); and padding or single-step filler.

• Fix vs. ask. Apply clear-cut fixes yourself with update-visual-plan

contentPatches — vague non-goals, unanchored claims, an obvious missing decision. Route genuine judgment calls back to the user instead: add them to the bottom question-form Open Questions block or batch them into the normal ask-user-question flow. Do not silently decide them.

• Do not surprise the user mid-read. On a large plan, apply the patches before

the editor loads; otherwise note briefly that a self-review is running so the plan changing under them is expected. When you next respond, summarize what the review changed and what it surfaced for the user to decide.

Visual Surface Choice

Choose the surface before creating the plan or after reading the source plan. Do not add visual chrome by default:

For UI/product plans, the top canvas is usually the primary review surface. Put the first meaningful wireframes there, not buried as document-body blocks. Use multiple canvas artboards when states matter, such as the default view, an overflow menu or popover, a side panel, loading, or error. Put short annotations beside frames with targetId plus placement; keep implementation details, tradeoffs, file maps, data contracts, risks, and verification in the document body below the canvas.

When the user asks for a flow, storyboard, journey, wireframe, canvas, or "what this looks like", treat that as a canvas-first request. Make one artboard per user-visible state, connect only adjacent transitions, and use short canvas annotations for the product notes. Do not substitute a document-body diagram block for the requested storyboard just because HTML diagrams are faster to write; diagrams belong below the canvas for backend mechanics, architecture, or data-flow explanation.

Keep product wireframes and explanatory/meta diagrams separate. Start with pure screens that look like the app state under discussion, without callout prose or architecture notes embedded inside the UI. Put arrows, labels, contracts, data flow, and mode explanations in separate annotations, separate canvas diagrams, or the document

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: BuilderIO
• Source: BuilderIO/skills
• License: MIT
• Homepage: https://www.agent-native.com/

Install and usage instructions live in the source repository linked above.