visual-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

Agent-Native Plans 是面向编码Agent的结构化可视化规划模式。构建你通常用Markdown编写的计划，但将其转化为可扫描的文档，其中混合了可编辑模块：嵌入式图表、代码片段、开放式问题，以及可选的顶部可视化评审区域（线框图画布、交互式原型，或两者在标签页中展示）。架构和后端计划仅保留文档形式；UI和产品计划从顶部画布/原型开始（该规则由「可视化界面选择」部分定义）。

/visual-plan

是打包后的命令和主入口。根据任务选择评审模式：当工作主要是产品UI且评审应从界面开始时选择UI优先模式；当评审应从功能性交互式原型开始时选择原型优先模式；当评审需要高保真品牌化界面时选择设计优先模式；当用户明确希望在规划前填写问卷时选择可视化收集模式。如果已有Codex、Claude Code、Markdown或粘贴的计划，

/visual-plan

会将该源计划作为起点，基于它构建评审界面，而非从头开始。

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.

每当计划作为可评审工件比聊天段落更合适时，创建或调整可视化计划。这包括适度的工作，如带有状态的单个UI界面、小型工作流、产品变更前后对比，或需要达成一致的组件/API/数据结构决策，以及更大规模的多文件、模糊、长期、高风险或UI密集型工作。当架构/数据流/UI方向/选项/开放式问题能从嵌入式图表或结构化模块中受益时，当用户需要在你实现前对方向做出反馈时，或当现有文本计划需要更丰富的评审界面时，使用它。

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
```
from
```
/visual-plan
```
. 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.

审慎使用：可视化计划是更丰富的评审界面，而非仅用于大型项目的工具。当用户需要在编码前查看、比较、评论或批准某个方向时，即使是适度的UI/状态/工作流变更，也要使用它。对于真正琐碎、明确的工作——拼写错误、单行修复、单个明确指定的函数、任何能用一句话描述差异的内容——直接进行修改即可。切勿在计划中添加冗余内容，也不要交付单步骤计划。
先调研再起草：先阅读真实文件、操作、模式和架构；使用实际的文件、符号和数据结构名称，而非凭空捏造。在提议端点前先检查现有的
```
actions/
```
，优先使用命名客户端助手而非原始fetch请求。将大范围探索委托给子Agent。以复用为导向：对于每个步骤，先说明复用的内容——现有操作、模式、组件、助手——再说明新增内容，这样计划就能解释真正的新增部分，而非重复描述已存在的内容。
先确定难以逆转的决策：对于非琐碎的后端、数据或API工作，先勾勒功能的发展方向，然后指出一旦数据或调用方依赖就难以撤销的决策—— wire格式、公共ID、数据模型结构、认证和所有权边界——并在计划中确保这些决策正确，即使大部分功能稍后才交付。然后将范围限定在最小的初始版本，既能验证方法又不排除后续可能性，同时明确说明包含和推迟的内容。
示例要恰当：当用户的想法是宽泛的框架、产品或运营模式变更时，不要将其简化为他们提到的第一个具体示例、提供商或同步路径。将核心抽象与示例和应用/提供商适配器分开。用示例让计划更易懂，但要将其标记为示例，除非它们是整个请求范围。
发布独立计划：如果用户粘贴、引用或已有Codex/Claude Code/Markdown计划，将其视为源材料，但将发布的计划重写为清晰的独立提案。保留源计划的有用意图和代码库事实，将推断的可视化内容标记为推断内容，避免使用诸如“保留先前计划”“不要放弃旧想法”“与之前版本不同”或“本次修订更改了...”之类的修订语言。即使从未看过聊天或早期草稿的读者也应该能理解该计划。
首次阅读要具体：如果计划要与聊天外的人共享，或者概念较为抽象，请在模式表、架构或路线图之前，在靠近顶部的位置给出一个具体的产品示例。对于支持UI的概念，这通常意味着顶部画布应用状态要以产品术语展示真实的用户工作流。不要依赖仅在对话中有意义的短语，也不要将计划表述为“不是旧想法”；直接陈述积极的模型。
规划是只读的：在构建或评审计划时不要编辑源代码。只有在用户批准方向后才开始编辑。
澄清而非假设：不要询问如何构建——在计划中探索并展示方法和选项。只有当歧义会改变设计且你无法从代码中解决时，才提出澄清问题；使用宿主Agent的常规询问用户问题流程，在定稿前批量提出2-4个高价值问题。不要从
```
/visual-plan
```
调用
```
create-visual-questions
```
。否则要明确陈述假设并继续，将任何未解决的问题放在计划底部的单个
```
question-form
```
开放式问题模块中。对于复杂计划，在交付前进行最终的开放式问题检查：如果某个决策会影响架构、范围、UX、数据结构或部署，要么在计划中给出决策理由，要么将其放入底部表单并提供推荐默认值。
计划是审批关口：展示计划后，请用户在编写代码前进行评审和批准，并说明工作涉及的文件/区域。展示计划并请求签字确认就是审批步骤——不要单独问“看起来不错吗？”。
文档是唯一真相来源，而非聊天：当范围变更时，使用
```
update-visual-plan
```
更新计划，而非仅在聊天中改变方向，并使更新后的文档保持独立。不要在计划内部将更新描述为对早期草稿的修正。在主要步骤前重新阅读已批准的计划。

Create A Structured Agent-Native Plan — Never Inline

创建结构化Agent-Native计划——切勿内嵌

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. NEVER hand the plan over as inline chat content — no Markdown prose, ASCII sketch, table, or fenced wireframe. If the connector's tools are missing, do NOT fall back to inline output: the usual cause is a connector that did not finish connecting this session (it registers zero tools), not auth. Stop and give the user the exact restore step for their current client: in Codex/Codex Desktop run

npx -y @agent-native/core@latest reconnect https://plan.agent-native.com --client codex

and start a new Codex session; in Claude Code run

/mcp

and choose Authenticate/Reconnect (or run the same reconnect command with

--client claude-code

and restart Claude). Auth is stored per client config/session, so one client's reconnect does not make another running client load tools. Never reinstall from scratch just to fix auth. Publish once the tool is reachable. Local-files privacy mode (after Tool Guidance) is the exception.

交付成果始终是结构化Agent-Native计划，而非仅存在于聊天中的计划。托管的Plan MCP连接器（

plan

服务器，或旧版

agent-native-plans

）是默认的协作和评论界面；不能将其作为外部依赖或租用层而拒绝使用该规划模式。计划是可移植的源工件（

plan.mdx

、可选的

canvas.mdx

prototype.mdx

、JSON和HTML导出文件），对所有权敏感的工作流可以使用本地文件模式或自托管/自定义Plan应用URL，而无需放弃该技能的评审准则。不要因为默认界面是托管的就建议用户跳过

/visual-plan

；应根据用户的所有权、隐私、共享和品牌需求选择合适的Plan模式。

默认情况下，通过Plan MCP连接器创建计划。切勿将计划作为内嵌聊天内容交付——不要使用Markdown散文、ASCII草图、表格或 fenced线框图。如果连接器工具缺失，不要回退到内嵌输出：通常原因是连接器未完成本次会话的连接（它注册了零工具），而非认证问题。停止操作并向用户提供其当前客户端的确切恢复步骤：在Codex/Codex Desktop中运行

npx -y @agent-native/core@latest reconnect https://plan.agent-native.com --client codex

并启动新的Codex会话；在Claude Code中运行

/mcp

并选择Authenticate/Reconnect（或运行相同的重新连接命令并加上

--client claude-code

，然后重启Claude）。认证存储在每个客户端配置/会话中，因此一个客户端的重新连接不会使另一个运行中的客户端加载工具。切勿仅为修复认证而从头重新安装。工具可用后再发布计划。本地文件隐私模式（遵循工具指南）是例外情况。

Core Workflow

核心工作流

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.
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.
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.
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.
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.
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.
Export with
```
export-visual-plan
```
only when the user wants a shareable receipt or repo-check-in artifacts.

遵循宿主Agent的常规规划流程：检查代码库，必要时委托大范围探索，收集所需信息，并在生成计划前根据需要提出原生澄清问题。如果已有源计划，从用户的粘贴内容、引用文件或最近可见的Agent上下文中收集其确切文本；不要凭空编造源文本。
调用
```
get-plan-blocks
```
获取权威模块目录——不要凭记忆创作。然后调用匹配模式的创建工具：
```
create-visual-plan
```
用于文档优先计划（架构、后端、数据、重构、API），
```
create-ui-plan
```
用于UI优先计划，
```
create-prototype-plan
```
用于原型优先计划，
```
create-plan-design
```
用于设计优先计划，仅当用户明确要求可视化收集问卷时才使用
```
create-visual-questions
```
。如果已有源计划，将其作为
```
planText
```
传递，在生成独立计划文档时保留原始计划的有用意图，而非修订备忘录。
对于UI/产品计划，先使用主要线框图和带注释的状态构建顶部画布，然后使用原生模块编写文档（参见
```
references/canvas.md
```
和
```
references/document-quality.md
```
）。对于涉及用户界面的广泛产品架构计划，在抽象架构或模式表之前添加一个具体的“应用中的实际效果”可视化内容。使文档贴近Agent通常输出的独立Markdown计划。如果提供了现有计划，保留正确的事实和决策，不要提及先前草稿或解释此版本与之前版本的差异。对于非可视化计划，跳过顶部可视化界面（由下面的「可视化界面选择」规则定义），直接将
```
diagram
```
、
```
data-model
```
、
```
api-endpoint
```
、
```
diff
```
、
```
file-tree
```
、
```
code
```
和
```
annotated-code
```
模块放在相关文本旁边。
展示返回的Plans链接或内嵌MCP应用，并请用户进行评审。始终在聊天中包含实际URL，以便在CLI或其他纯文本主机中下一步操作是点击。当主机提供嵌入式浏览器/预览面板且工具可以打开任意URL时，自动打开返回的计划URL以方便评审——这是一种便利和冒烟测试，绝不是唯一的交付方式或访问模型。计划应在本地Agent和本地浏览器会话中开箱即用；如果已登录的嵌入式浏览器无法读取匿名/工具检查可以读取的本地计划，请修复应用/操作所有权或访问路径，而非手动修改单个计划。对于高风险计划（架构、后端、数据、多文件或有风险的工作），在用户阅读时同时启动「交付前自我评审」中的自我评审流程，而非在交付时等待评审完成。
在编辑前、评审后、任何长时间停顿后以及最终响应前调用
```
get-plan-feedback
```
。将
```
anchorDetails
```
、解析器意图、最近的评审事件以及浏览器交付的任何聚焦截图作为准确了解变更内容和每条评论指向的唯一真相来源。
使用
```
update-visual-plan
```
应用更改，优先使用针对性的
```
contentPatches
```
。将顶级
```
content
```
payload视为完整替换，而非合并；不要发送部分
```
content
```
对象来添加画布或单个模块。如果必须进行完整替换，请先读取完整的计划源/内容，保留所有现有模块和可视化界面，然后验证源/导出内容，确保文档主体未被截断。当用户需要对源代码控制友好的编辑时，使用
```
patch-visual-plan-source
```
针对MDX文件进行操作，而非重新生成计划。
仅当用户需要可共享的回执或代码库检入工件时，才使用
```
export-visual-plan
```
进行导出。

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.

对于高风险计划——架构、后端、数据模型、迁移、多文件或其他有风险的工作——在将计划视为最终版本前运行一次对抗性自我评审。对于小型、仅UI或单决策计划，当成本超过价值时可以跳过。保持评审低成本且非阻塞：

先展示计划，并行评审：发布链接让用户开始阅读，然后并行运行评审——切勿让用户等待。
评审书面计划；不要重新调研：评审计划文本及其模块。起草时已经完成了基础工作，因此评审是检查输出而非重新探索代码库。
生成一个持怀疑态度的评审者：其唯一工作是找出薄弱、缺失或错误的内容——而非表扬。重点关注：隐式或未做出的难以逆转的决策（wire格式、公共ID、数据模型结构、认证、所有权）；未锚定到真实文件或符号的步骤；计划应承诺选择一个选项的菜单；明显缺失的决策（“当X发生时会怎样？”“为什么不选Y？”）；以及冗余或单步骤填充内容。
修复还是询问：使用
```
update-visual-plan
```
的
```
contentPatches
```
自行应用明确的修复——模糊的非目标、无锚定的声明、明显缺失的决策。将真正的判断问题反馈给用户：将其添加到底部的
```
question-form
```
开放式问题模块中，或批量放入常规的询问用户问题流程中。切勿默默做出决定。
不要在用户阅读时意外修改：对于大型计划，在编辑器加载前应用补丁；否则简要说明正在进行自我评审，以便用户预期计划会发生变化。下次回复时，总结评审更改的内容以及需要用户决定的事项。

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.

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 body.

When the plan touches an existing app, inspect the current shell/components before drawing. The first artboard should look like the real app at the same density: existing sidebars, toolbar placement, overflow menus, app chrome, and framework agent chrome stay in their real places. Model secondary surfaces as separate states, such as a top-right overflow popover, sheet, panel, loading state, or separate AgentSidebar, rather than inventing a permanent inspector or folding framework chrome into the product UI.

No visual surface for architecture-only, backend-only, data migration, copy-only, or otherwise non-visual plans. Do not use the top canvas for architecture diagrams, dependency maps, file plans, API contracts, or data-flow-only reviews. Use a strong document with local inline diagrams only when relationships need a visual explanation, usually one spatial diagram per recommendation or decision. Prefer grouped regions, layers, quadrants, matrices, or before/after panels over a single-axis chain unless the relationship is truly sequential.
Canvas only for one static screen, a before/after comparison, a component state, a small popover, or a visual direction that does not require clicking. Put those wireframes in
```
content.canvas
```
and omit
```
content.prototype
```
.
Canvas + prototype for multi-step UI flows, onboarding, wizards, review/approval flows, navigation changes, or anything where the reviewer needs to operate the behavior. Keep the static wireframes in
```
content.canvas
```
, add the aligned functional prototype in
```
content.prototype
```
, and rely on the top visual tabs to switch between them.
Prototype-first when the user asks to operate the UI or when interaction is the main question. Use
```
create-prototype-plan
```
, which still preserves static mocks where useful.

For mixed canvas + prototype plans, reuse the same real labels, app statuses, and screen ids across both surfaces. The canvas is the inspectable static reference; the prototype is the interactive version of that same flow, not a separate design direction.

在创建计划或阅读源计划后选择界面。默认情况下不要添加可视化装饰：

对于UI/产品计划，顶部画布通常是主要评审界面。将第一个有意义的线框图放在那里，不要埋在文档主体模块中。当状态重要时使用多个画布画板，例如默认视图、溢出菜单或弹出框、侧边面板、加载或错误状态。使用

targetId

加

placement

在框架旁边添加简短注释；将实现细节、权衡、文件映射、数据契约、风险和验证放在画布下方的文档主体中。

将产品线框图和解释/元图分开。从看起来像讨论中的应用状态的纯界面开始，不要在UI中嵌入标注文本或架构说明。将箭头、标签、契约、数据流和模式说明放在单独的注释、单独的画布图表或文档主体中。

当计划涉及现有应用时，在绘制前检查当前框架/组件。第一个画板应看起来像真实应用，密度相同：现有侧边栏、工具栏位置、溢出菜单、应用导航栏和框架Agent导航栏保持在实际位置。将次要界面建模为单独的状态，例如右上角溢出弹出框、表单、面板、加载状态或单独的AgentSidebar，而非发明永久检查器或将框架导航栏融入产品UI。

无可视化界面：仅适用于架构、后端、数据迁移、仅文案或其他非可视化计划。不要将架构图、依赖图、文件计划、API契约或仅数据流评审放在顶部画布中。仅当关系需要可视化解释时，才使用带有本地嵌入式图表的强文档，通常每个建议或决策对应一个空间图。除非关系确实是顺序的，否则优先使用分组区域、层、象限、矩阵或前后面板，而非单轴链。
仅画布：适用于单个静态界面、前后对比、组件状态、小型弹出框或不需要点击的可视化方向。将这些线框图放在
```
content.canvas
```
中，省略
```
content.prototype
```
。
画布+原型：适用于多步骤UI流程、入职引导、向导、评审/批准流程、导航变更或任何评审者需要操作行为的场景。将静态线框图放在
```
content.canvas
```
中，在
```
content.prototype
```
中添加对齐的功能性原型，并依靠顶部可视化标签页在两者之间切换。
原型优先：当用户要求操作UI或交互是主要问题时使用。使用
```
create-prototype-plan
```
，它仍会在有用的地方保留静态模拟图。

对于混合画布+原型计划，在两个界面中重用相同的真实标签、应用状态和界面ID。画布是可检查的静态参考；原型是同一流程的交互式版本，而非单独的设计方向。

Wireframe quality — read

references/wireframe.md

线框图质量——阅读

references/wireframe.md

UI recap/plan wireframes must meet a strict quality bar — full-width chrome, pinned bottom bars, real product content, before/after comparability, the right

surface

preset,

--wf-*

tokens instead of hex, and no

<html>

<style>

/font tags. Before authoring ANY wireframe /

<Screen>

WireframeBlock

, READ

references/wireframe.md

in this skill directory — it is the single source of truth for HTML wireframe quality, shared word for word with

/visual-plan

and

/visual-recap

. Do not author wireframes from memory.

UI回顾/计划线框图必须达到严格的质量标准——全宽导航栏、固定底部栏、真实产品内容、可对比的前后版本、正确的

surface

预设、使用

--wf-*

令牌而非十六进制颜色，且无

<html>

<style>

/字体标签。在创建任何线框图/

<Screen>

WireframeBlock

之前，请阅读此技能目录中的

references/wireframe.md

——它是HTML线框图质量的唯一权威来源，与

/visual-plan

和

/visual-recap

完全共享。切勿凭记忆创作线框图。

Canvas — read

references/canvas.md

画布——阅读

references/canvas.md

The canvas is the single source of truth for static UI mockups: the

surface

locks each artboard's footprint, mixed surfaces lay out in lanes, annotations are plain-text designer notes anchored by

targetId

placement

, and edits are surgical

contentPatches

. Before authoring or editing ANY canvas, artboard, or annotation, READ

references/canvas.md

in this skill directory — it is the single source of truth for canvas/artboard mechanics. Do not author canvas layouts from memory.

画布是静态UI模拟图的唯一真相来源：

surface

锁定每个画板的布局，混合界面在通道中排列，注释是通过

targetId

placement

锚定的纯文本设计师笔记，编辑是精准的

contentPatches

。在创建或编辑任何画布、画板或注释之前，请阅读此技能目录中的

references/canvas.md

——它是画布/画板机制的唯一权威来源。切勿凭记忆创作画布布局。

Document quality — read

references/document-quality.md

文档质量——阅读

references/document-quality.md

The document is a serious technical plan, not marketing: outcome-first, prose-first, self-contained, built from the right native blocks, with open questions in a single bottom

question-form

and a pre-handoff visual check. Before authoring the plan document, READ

references/document-quality.md

in this skill directory — it is the single source of truth for the document quality bar. Do not write the document from memory.

文档是严肃的技术计划，而非营销内容：以结果为导向、以文本为主、独立完整、由正确的原生模块构建，开放式问题放在单个底部

question-form

中，并在交付前进行可视化检查。在创建计划文档之前，请阅读此技能目录中的

references/document-quality.md

——它是文档质量标准的唯一权威来源。切勿凭记忆编写文档。

Good vs. bad exemplar — read

references/exemplar.md

优劣示例——阅读

references/exemplar.md

For a worked example of the bar — a great UI-first plan and

/visual-plan

, plus the anti-patterns to avoid — READ

references/exemplar.md

in this skill directory before authoring a plan.

要了解标准的实际示例——优秀的UI优先计划和

/visual-plan

，以及要避免的反模式——在创建计划前阅读此技能目录中的

references/exemplar.md

。

Tool Guidance

工具指南

```
create-visual-plan
```
: start one structured visual plan per agent task/run, or import an existing text plan by passing
```
planText
```
;
```
content
```
may include no visual surface, canvas only, or canvas + prototype.
```
create-ui-plan
```
: start a UI-first plan when the work is primarily product UI.
```
create-prototype-plan
```
: start a prototype-first plan with a functional top review surface.
```
create-plan-design
```
: start a full-fidelity branded Design-tab plan with an optional matching Prototype tab.
```
convert-visual-plan-to-prototype
```
: convert an existing HTML wireframe canvas into a prototype plan.
```
create-visual-questions
```
: use only when the user explicitly asks for a visual intake questionnaire, not as
```
/visual-plan
```
preflight.
```
update-visual-plan
```
: revise content, status, or comments with targeted
```
contentPatches
```
(see Core Workflow step 6).
```
read-visual-plan-source
```
: read the normalized plan as
```
plan.mdx
```
, optional
```
canvas.mdx
```
, optional
```
.plan-state.json
```
, and JSON.
```
patch-visual-plan-source
```
: apply granular MDX AST patches by stable block, artboard, annotation, component, or wireframe-node id.
```
import-visual-plan-source
```
: create or replace a plan from an MDX folder.
```
get-visual-plan
```
: read the current structured plan, exported HTML, and annotations; it also returns the MDX folder for source workflows.
```
get-plan-feedback
```
: read unconsumed human feedback. Use it frequently; it returns grouped threads, exact anchor details, expected resolver, and recent review-event payloads so agents can act only on the comments meant for them.
```
get-plan-blocks
```
: resolve block tags before authoring — do not memorize tags; call this first to get the authoritative tag names, required fields, and prop shapes from the live block registry.
```
export-visual-plan
```
: export HTML, Markdown fallback, structured JSON, and MDX files for repo check-in.

When the user critiques a plan's look or structure, fix the renderer or this skill — never hand-edit one stored plan. Turn feedback into better guidance.

```
create-visual-plan
```
：为每个Agent任务/运行启动一个结构化可视化计划，或通过传递
```
planText
```
导入现有文本计划；
```
content
```
可以不包含可视化界面、仅包含画布，或包含画布+原型。
```
create-ui-plan
```
：当工作主要是产品UI时启动UI优先计划。
```
create-prototype-plan
```
：启动带有功能性顶部评审界面的原型优先计划。
```
create-plan-design
```
：启动带有可选匹配原型标签页的高保真品牌化设计标签页计划。
```
convert-visual-plan-to-prototype
```
：将现有HTML线框图画布转换为原型计划。
```
create-visual-questions
```
：仅当用户明确要求可视化收集问卷时使用，而非作为
```
/visual-plan
```
的预检步骤。
```
update-visual-plan
```
：使用针对性的
```
contentPatches
```
修改内容、状态或评论（参见核心工作流步骤6）。
```
read-visual-plan-source
```
：将规范化计划读取为
```
plan.mdx
```
、可选的
```
canvas.mdx
```
、可选的
```
.plan-state.json
```
和JSON格式。
```
patch-visual-plan-source
```
：通过稳定模块、画板、注释、组件或线框图节点ID应用精细的MDX AST补丁。
```
import-visual-plan-source
```
：从MDX文件夹创建或替换计划。
```
get-visual-plan
```
：读取当前结构化计划、导出的HTML和注释；它还返回MDX文件夹用于源工作流。
```
get-plan-feedback
```
：读取未处理的人工反馈。经常使用它；它返回分组线程、准确的锚点详情、预期解析器和最近的评审事件payload，以便Agent仅对针对他们的评论采取行动。
```
get-plan-blocks
```
：在创作前解析模块标签——不要记忆标签；先调用此工具从实时模块注册表获取权威标签名称、必填字段和属性形状。
```
export-visual-plan
```
：导出HTML、Markdown备用格式、结构化JSON和MDX文件用于代码库检入。

当用户批评计划的外观或结构时，修复渲染器或此技能——切勿手动编辑单个存储的计划。将反馈转化为更好的指南。

Local-Files Privacy Mode

本地文件隐私模式

Use local-files privacy mode when the user explicitly asks for no DB writes, no hosted Plan database writes, no Plan MCP publish, fully local files, offline/private planning, repo-owned/source-controlled planning artifacts, or when

AGENT_NATIVE_PLANS_MODE=local-files

is set. Also use it when a user or repo policy says a plan must stay under their own brand, domain, source control, or infrastructure. In this mode the plan data must never be sent to the Plan MCP server or Plan app action surface. Schema-only block catalog lookup is allowed because it sends no plan content: use the MCP

get-plan-blocks

tool if it is already available, or run

npx @agent-native/core@latest plan blocks --out plan-blocks.md

and read that file before authoring MDX.

The local-files contract is:

Read source context from local files and shell commands only.
Fetch/read the block catalog before writing structured MDX. The
```
plan blocks
```
command calls the public no-auth
```
get-plan-blocks
```
route and writes only registry metadata to disk; use
```
--format schema
```
if exact nested fields are needed. If network access is unavailable, use the bundled references and rely on
```
plan local check
```
/
```
plan local serve
```
to catch invalid tags. For
```
checklist
```
and
```
question-form
```
, copy the catalog examples verbatim: checklist items need
```
id
```
and
```
label
```
; question-form questions need
```
id
```
,
```
title
```
, and
```
mode
```
; and each option needs
```
id
```
and
```
label
```
.
```
plan local check
```
validates these required fields against the renderer schema.
Write the plan as a local MDX folder: use
```
plans/<slug>/
```
when the user wants the artifact checked into the repo, or use a repo-ignored/temporary folder such as
```
.agent-native/plans/<slug>/
```
or
```
/tmp/agent-native-plans/<slug>/
```
when it should not be checked in. The folder contains
```
plan.mdx
```
, optional
```
canvas.mdx
```
, optional
```
prototype.mdx
```
, and optional
```
.plan-state.json
```
.
Run
```
npx @agent-native/core@latest plan local check --dir plans/<slug>
```
before serving, then run
```
npx @agent-native/core@latest plan local serve --dir plans/<slug> --kind plan --open
```
. Report the returned local bridge URL from stdout or
```
plans/<slug>/.plan-url
```
. Treat
```
.plan-url
```
as a local token file and do not commit it. The URL opens the hosted Plan UI but reads from the localhost bridge on this machine, so it is not shareable across machines. On macOS,
```
--open
```
prefers Chromium browsers; if Safari opens, switch to Chrome/Chromium because Safari can block the hosted HTTPS page from fetching the HTTP localhost bridge. If the Plan app itself is running locally with the same
```
PLAN_LOCAL_DIR
```
, the
```
/local-plans/<slug>
```
route is also valid.
For headless verification, run
```
npx @agent-native/core@latest plan local verify --dir plans/<slug> --kind plan
```
. It starts the bridge, checks the private-network preflight and JSON payload, prints diagnostics, and exits. If the browser hangs on "Loading plan", fetch the
```
bridgeUrl
```
from the verify/serve JSON to read the concrete validation error.

Do not call

create-visual-plan

create-ui-plan

create-prototype-plan

create-plan-design

import-visual-plan-source

update-visual-plan

patch-visual-plan-source

get-plan-feedback

export-visual-plan

, or any hosted Plan tool for that plan except the schema-only block catalog lookup above.

Treat feedback as file or chat feedback: update the MDX files directly, rerun the local bridge command, and summarize the new local bridge URL. Hosted comments, sharing, history, and publish/export receipts are unavailable until the user explicitly opts into publishing.

Local-files mode prevents plan content from going to the Agent-Native Plan database. It does not by itself make the coding agent's language model local; for that stronger privacy boundary, the host agent/model must also be local or otherwise approved by the user.

当用户明确要求不写入数据库、不写入托管Plan数据库、不发布到Plan MCP、完全使用本地文件、离线/私有规划、代码库拥有/源代码控制的规划工件，或设置了

AGENT_NATIVE_PLANS_MODE=local-files

时，使用本地文件隐私模式。当用户或代码库策略要求计划必须在其自有品牌、域名、源代码控制或基础设施下时，也使用此模式。在此模式下，计划数据绝不能发送到Plan MCP服务器或Plan应用操作界面。仅允许仅模式的模块目录查找，因为它不发送计划内容：如果已可用，使用MCP

get-plan-blocks

工具，或运行

npx @agent-native/core@latest plan blocks --out plan-blocks.md

并在创作MDX前读取该文件。

本地文件协议：

仅从本地文件和shell命令读取源上下文。
在编写结构化MDX前获取/读取模块目录。
```
plan blocks
```
命令调用公共无认证
```
get-plan-blocks
```
路由，并仅将注册表元数据写入磁盘；如果需要精确的嵌套字段，使用
```
--format schema
```
。如果无法访问网络，使用捆绑的参考文件，并依靠
```
plan local check
```
/
```
plan local serve
```
捕获无效标签。对于
```
checklist
```
和
```
question-form
```
，逐字复制目录示例：清单项需要
```
id
```
和
```
label
```
；问题表单问题需要
```
id
```
、
```
title
```
和
```
mode
```
；每个选项需要
```
id
```
和
```
label
```
。
```
plan local check
```
会根据渲染器模式验证这些必填字段。
将计划写入本地MDX文件夹：当用户希望将工件检入代码库时使用
```
plans/<slug>/
```
，或使用代码库忽略/临时文件夹如
```
.agent-native/plans/<slug>/
```
或
```
/tmp/agent-native-plans/<slug>/
```
，当不应检入时。文件夹包含
```
plan.mdx
```
、可选的
```
canvas.mdx
```
、可选的
```
prototype.mdx
```
和可选的
```
.plan-state.json
```
。
在服务前运行
```
npx @agent-native/core@latest plan local check --dir plans/<slug>
```
，然后运行
```
npx @agent-native/core@latest plan local serve --dir plans/<slug> --kind plan --open
```
。报告stdout或
```
plans/<slug>/.plan-url
```
中返回的本地桥接URL。将
```
.plan-url
```
视为本地令牌文件，不要提交它。该URL会打开托管Plan UI，但从本地机器的localhost桥接读取，因此无法跨机器共享。在macOS上，
```
--open
```
优先使用Chromium浏览器；如果打开了Safari，请切换到Chrome/Chromium，因为Safari可能会阻止托管HTTPS页面获取HTTP localhost桥接。如果Plan应用本身在本地运行且使用相同的
```
PLAN_LOCAL_DIR
```
，则
```
/local-plans/<slug>
```
路由也有效。
对于无头验证，运行
```
npx @agent-native/core@latest plan local verify --dir plans/<slug> --kind plan
```
。它启动桥接，检查私有网络预检和JSON payload，打印诊断信息并退出。如果浏览器在“加载计划”时挂起，从verify/serve JSON中获取
```
bridgeUrl
```
以读取具体的验证错误。

切勿为该计划调用

create-visual-plan

、

create-ui-plan

、

create-prototype-plan

、

create-plan-design

、

import-visual-plan-source

、

update-visual-plan

、

patch-visual-plan-source

、

get-plan-feedback

、

export-visual-plan

或任何托管Plan工具，除了上面提到的仅模式的模块目录查找。

将反馈视为文件或聊天反馈：直接更新MDX文件，重新运行本地桥接命令，并总结新的本地桥接URL。托管评论、共享、历史记录和发布/导出回执在用户明确选择发布前不可用。

本地文件模式可防止计划内容进入Agent-Native Plan数据库。它本身不会使编码Agent的语言模型本地化；要实现更强的隐私边界，宿主Agent/模型也必须是本地化的，或经用户批准。

Interpreting comment anchors

评论锚点解读

get-plan-feedback

returns rich anchors — read them before acting on any comment.

Coordinate frames.
```
targetX
```
/
```
targetY
```
are percentages within the element named by
```
targetSelector
```
/
```
targetKind
```
. Bare
```
x
```
/
```
y
```
are percentages of the whole plan document.
```
canvasX
```
/
```
canvasY
```
are raw board-world pixels on the design canvas (board size given when available).
Wireframe pins. Anchors on wireframes include
```
targetNodeId
```
and
```
targetNodePath
```
(e.g.
```
card > list > listItem "Acme Inc"
```
) identifying the exact kit node. Use
```
targetNodeId
```
directly with wireframe node patch ops; use
```
data-design-id
```
values from design artboards with
```
update-design-element-style
```
. Prefer the node id/path over raw coordinates; fall back to coordinates plus the focused screenshot (red ring marks the exact point) only when no node id is present.
Text quotes. Resolve
```
textQuote
```
against current prose using
```
contextBefore
```
/
```
contextAfter
```
for disambiguation. If
```
ambiguous: true
```
, ask the user — do not guess which occurrence is meant.
Detached comments.
```
get-plan-feedback
```
flags threads whose quoted text no longer exists as
```
detached
```
(in
```
detachedThreads
```
). Reconcile these against rewritten content — never silently drop them.
Routing.
```
resolutionTarget
```
is the only routing signal: act on
```
agent
```
, treat
```
human
```
as context only.
```
@mentions
```
are people to notify, never a routing signal.
Two-axis state. Mark every ingested comment as consumed (
```
consumedCommentIds
```
on
```
update-visual-plan
```
). Set
```
status=resolved
```
only on agent-targeted comments you actually addressed; leave human-targeted comments open.

get-plan-feedback

返回丰富的锚点——在对任何评论采取行动前先阅读它们。

坐标系：
```
targetX
```
/
```
targetY
```
是
```
targetSelector
```
/
```
targetKind
```
指定元素内的百分比。裸
```
x
```
/
```
y
```
是整个计划文档的百分比。
```
canvasX
```
/
```
canvasY
```
是设计画布上的原始板世界像素（板大小在可用时提供）。
线框图锚点：线框图上的锚点包含
```
targetNodeId
```
和
```
targetNodePath
```
（例如
```
card > list > listItem "Acme Inc"
```
），用于标识确切的套件节点。将
```
targetNodeId
```
直接用于线框图节点补丁操作；将设计画板中的
```
data-design-id
```
值与
```
update-design-element-style
```
一起使用。优先使用节点ID/路径而非原始坐标；仅当没有节点ID时才回退到坐标加聚焦截图（红圈标记确切点）。
文本引用：使用
```
contextBefore
```
/
```
contextAfter
```
消除歧义，将
```
textQuote
```
与当前文本匹配。如果
```
ambiguous: true
```
，询问用户——不要猜测指的是哪个实例。
分离的评论：
```
get-plan-feedback
```
将引用文本不再存在的线程标记为
```
detached
```
（在
```
detachedThreads
```
中）。将这些与重写的内容协调——切勿默默删除它们。
路由：
```
resolutionTarget
```
是唯一的路由信号：对
```
agent
```
采取行动，将
```
human
```
仅视为上下文。
```
@mentions
```
是要通知的人，而非路由信号。
双轴状态：将每个摄入的评论标记为已处理（
```
update-visual-plan
```
上的
```
consumedCommentIds
```
）。仅在实际处理了针对Agent的评论时设置
```
status=resolved
```
；保持针对人类的评论为打开状态。

Visibility & Sharing

可见性与共享

Use

set-resource-visibility

to change who can see a plan (e.g. public, login, or org-scoped). Use

share-resource

to grant specific users or roles access by email or role. Gate visibility before sharing any plan that covers unreleased or private work — default to the narrowest scope that meets the review need.

使用

set-resource-visibility

更改谁可以查看计划（例如公开、登录或组织范围）。使用

share-resource

通过电子邮件或角色授予特定用户或角色访问权限。在共享任何包含未发布或私有工作的计划前设置可见性——默认选择满足评审需求的最窄范围。

Setup & Authentication

设置与认证

There are two ways into Plans.

Coding agent (CLI). Install once with the Agent-Native CLI. The command installs the Plans skills, registers the hosted Plans MCP connector, and runs auth/setup for the selected local client(s) in the same step (a one-time browser sign-in at setup — this is intended), so the first tool call in that client does not hit an OAuth wall:

bash

npx @agent-native/core@latest skills add visual-plan

After that,

/visual-plan

and

/visual-recap

are the two installed slash commands. The other planning modes (

create-ui-plan

create-prototype-plan

create-plan-design

create-visual-questions

) are MCP tools reachable from

/visual-plan

, not separate slash commands. Pass

--no-connect

to register the connector without authenticating, then run

npx @agent-native/core@latest connect https://plan.agent-native.com --client all

whenever you are ready, or choose a narrower

--client

. Auth and MCP tool loading are per client config/session.

Browser (people you share with). Open the Plans editor and create & edit with no sign-up — you work as a guest. Sign in only when you want to save or share; signing in claims the plans you made as a guest into your account.

Sharing and commenting require an account: public/shared plans are viewable by anyone with the link, but commenting on them needs an agent-native account.

For fully offline, no-account use, run the Plans app locally and sync plans to your repo as MDX. This local mode is a separate advanced path, not the default hosted flow.

If a Plans tool returns

needs auth

Unauthorized

, or

Session terminated

, do not keep retrying the tool. Stop and give the user the reconnect step for the client they are using: Codex/Codex Desktop should run

npx -y @agent-native/core@latest reconnect https://plan.agent-native.com --client codex

and start a new Codex session; Claude Code should run

/mcp

and choose Authenticate/Reconnect for the plan connector, or run the reconnect command with

--client claude-code

and restart Claude. To refresh every local client config that already has the Plan entry, use

--client all

, then restart/reload each client. Reconnect re-authenticates WITHOUT reinstalling and finds the entry by URL regardless of connector name. Never reinstall from scratch just to fix auth. Continue once the connector is available.

Hosted default: connect

https://plan.agent-native.com/_agent-native/mcp

. Do not put shared secrets in skill files.

有两种方式进入Plans。

编码Agent（CLI）：使用Agent-Native CLI安装一次。该命令会安装Plans技能、注册托管Plans MCP连接器，并在同一步骤中为选定的本地客户端运行认证/设置（设置时需要一次性浏览器登录——这是预期的），因此该客户端中的第一个工具调用不会遇到OAuth墙：

bash

npx @agent-native/core@latest skills add visual-plan

之后，

/visual-plan

和

/visual-recap

是两个已安装的斜杠命令。其他规划模式（

create-ui-plan

、

create-prototype-plan

、

create-plan-design

、

create-visual-questions

）是可从

/visual-plan

访问的MCP工具，而非单独的斜杠命令。传递

--no-connect

以注册连接器而不进行认证，然后在准备好时运行

npx @agent-native/core@latest connect https://plan.agent-native.com --client all

，或选择更窄的

--client

。认证和MCP工具加载是按客户端配置/会话进行的。

浏览器（你共享的人）：打开Plans编辑器，无需注册即可创建和编辑——以访客身份工作。仅当你想要保存或共享时才登录；登录会将你作为访客创建的计划归入你的账户。

共享和评论需要账户：公开/共享计划可被任何有链接的人查看，但评论需要agent-native账户。

对于完全离线、无账户使用，可在本地运行Plans应用并将计划同步到你的代码库作为MDX文件。这种本地模式是单独的高级路径，而非默认的托管流程。

如果Plans工具返回

needs auth

、

Unauthorized

或

Session terminated

，不要继续重试该工具。停止操作并向用户提供其使用的客户端的重新连接步骤：Codex/Codex Desktop应运行

npx -y @agent-native/core@latest reconnect https://plan.agent-native.com --client codex

并启动新的Codex会话；Claude Code应运行

/mcp

并选择plan连接器的Authenticate/Reconnect，或运行带有

--client claude-code

的重新连接命令并重启Claude。要刷新所有已包含Plan条目的本地客户端配置，使用

--client all

，然后重启/重新加载每个客户端。重新连接会重新认证而无需重新安装，并通过URL查找条目，无论连接器名称如何。切勿仅为修复认证而从头重新安装。连接器可用后继续操作。

托管默认值：连接

https://plan.agent-native.com/_agent-native/mcp

。不要在技能文件中放入共享密钥。

visual-plan

Original

Translation

Agent-Native Plans

Agent-Native Plans

When To Use

使用场景

Plan Discipline

规划准则

Create A Structured Agent-Native Plan — Never Inline

创建结构化Agent-Native计划——切勿内嵌

Core Workflow

核心工作流

Self-Review Before Handoff

交付前的自我评审

Visual Surface Choice

可视化界面选择

Wireframe quality — read
`references/wireframe.md`

线框图质量——阅读
`references/wireframe.md`

Canvas — read
`references/canvas.md`

画布——阅读
`references/canvas.md`

Document quality — read
`references/document-quality.md`

文档质量——阅读
`references/document-quality.md`

Good vs. bad exemplar — read
`references/exemplar.md`

优劣示例——阅读
`references/exemplar.md`

Tool Guidance

工具指南

Local-Files Privacy Mode

本地文件隐私模式

Interpreting comment anchors

评论锚点解读

Visibility & Sharing

可见性与共享

Setup & Authentication

设置与认证

visual-plan

Original

Translation

Agent-Native Plans

Agent-Native Plans

When To Use

使用场景

Plan Discipline

规划准则

Create A Structured Agent-Native Plan — Never Inline

创建结构化Agent-Native计划——切勿内嵌

Core Workflow

核心工作流

Self-Review Before Handoff

交付前的自我评审

Visual Surface Choice

可视化界面选择

Wireframe quality — read references/wireframe.md

线框图质量——阅读references/wireframe.md

Canvas — read references/canvas.md

画布——阅读references/canvas.md

Document quality — read references/document-quality.md

文档质量——阅读references/document-quality.md

Good vs. bad exemplar — read references/exemplar.md

优劣示例——阅读references/exemplar.md

Tool Guidance

工具指南

Local-Files Privacy Mode

本地文件隐私模式

Interpreting comment anchors

评论锚点解读

Visibility & Sharing

可见性与共享

Setup & Authentication

设置与认证

Wireframe quality — read
`references/wireframe.md`

线框图质量——阅读
`references/wireframe.md`

Canvas — read
`references/canvas.md`

画布——阅读
`references/canvas.md`

Document quality — read
`references/document-quality.md`

文档质量——阅读
`references/document-quality.md`

Good vs. bad exemplar — read
`references/exemplar.md`

优劣示例——阅读
`references/exemplar.md`