需要把文本计划变成可评审的可视化计划时，用…

当架构、后端、数据、API、重构或 UI/产品方向需要在写代码前被查看、比较、评论和批准时，创建结构化视觉计划。

适用场景

解决思路

1. 用 `/visual-plan` 作为打包命令和主入口；根据任务选择评审模式：UI-first 用于主要是产品 UI 且评审从屏幕开始，prototype-first 用于应从功能 live prototype 开始，design-first 用于需要全保真品牌屏幕，visual-intake 用于用户明确想在规划前填问卷。
2. 已有 Codex、Claude Code、Markdown 或粘贴计划时，`/visual-plan` 将该源计划作为起点，并据此构建评审面，而不是重新开始。
3. 当计划作为可评审工件比聊天段落更好时，创建或改写视觉计划；包括单个带状态的 UI 表面、小工作流、前后产品变更、需要对齐的组件/API/数据形状决策，以及更大、多文件、模糊、长运行、有风险或 UI 密集工作。
4. 当架构/数据流/UI 方向/选项/开放问题受益于内联图或结构化块、用户需要在实现前对方向作出反应、或已有文本计划需要更丰富评审面时，使用结构化视觉计划。
5. 审慎设门：视觉计划是更丰富的评审面，不只是巨型项目工具；当用户需要在代码前看到、比较、评论或批准方向时使用，即使只是中等 UI/状态/工作流变更；跳过真正琐碎、无歧义工作；不要用填充物凑计划；不要交付单步计划。
6. 起草前先调研：先读真实文件、actions、schema 和模式；命名实际文件、符号和数据形状，不要发明；提出 endpoint 前检查现有 `actions/`，优先命名客户端 helper 而非 raw fetch；把广泛探索委托给子代理。
7. 以复用为先：每一步先命名复用什么——现有 actions、schema、组件、helper——再说新增什么，使计划解释真正新增的 delta，而不是重述已存在内容。
8. 先决定难以逆转的赌注：对非平凡后端、数据或 API 工作，先勾勒功能方向，然后指出一旦数据或调用方依赖就昂贵难撤的决策——wire format、public ids、data-model shape、auth 和 ownership 边界——并在计划中先做对这些，即使大部分功能后发。
9. 将范围缩小到最小首个切片，证明方法且不封死；在计划中说明包含什么和明确推迟什么。
10. 保持示例在正确高度：当用户想法是宽泛框架、产品或运营模式变化，不要折叠成他们提到的第一个具体示例、provider 或 sync path；把核心抽象与激励示例和 app/provider 适配器分开；用示例让计划清晰，但除非示例就是全部请求范围，否则标注为示例。
11. 发布独立计划：如果用户粘贴、引用或已有 Codex/Claude Code/Markdown 计划，把它当源材料，但把发布的计划重写为干净独立提案；保留源计划有用意图和代码库事实，把推断的视觉标注为 inferred，避免修订语言如 preserve the prior plan、do not drop the old idea、unlike the previous version、this revision changes...；没看过聊天或早期草稿的读者应能理解计划。
12. 让首次阅读具体：如果计划要分享给聊天外的人，或概念抽象，在模式表、架构或路线图之前，在靠近顶部先给一个具体产品示例；对 UI-capable 概念，通常是一个顶部 canvas 应用状态，展示真实用户工作流；不要依赖只在对话中有意义的短语，不要以「不是旧想法」框架计划；直接陈述正向模型。
13. 规划只读：构建或评审计划时不编辑源码；用户批准方向后才开始编辑。
14. 澄清 vs 假设：不要问如何构建——在计划中探索并呈现方法和选项；只有当歧义会改变设计且无法从代码解决时才问澄清问题；使用宿主 agent 正常 ask-user-question 流程，最终确定前批量 2-4 个高杠杆问题。
15. 不要为普通澄清或 preflight 调用 `create-visual-questions`；仅当用户明确要求 visual-intake questionnaire 时保留给 visual-intake 模式；否则明确陈述假设并继续。
16. 把未解决项放进计划底部单一 `question-form` Open Questions 块；对复杂计划，交接前做最终开放问题 pass：如果决策会影响架构、范围、UX、数据形状或 rollout，要么在计划中带理由决定，要么放进底部表单并给推荐默认。
17. 计划是批准门：展示后，请用户在写代码前评审并批准，并指出工作触及哪些文件/区域；展示计划并请求签核就是批准步骤——不要单独问 does this look good?。
18. 文档是真相源，不是聊天：范围变化时，用 `update-visual-plan` 更新计划而不是只在聊天中转向，并让更新文档独立；不要在计划本身把更新描述为对早期草稿的更正；重大步骤前重读已批准计划。
19. 交付物始终是结构化 Agent-Native Plan，不是仅聊天计划；托管 Plan MCP connector（`plan` server 或 legacy `agent-native-plans`）是默认协作和评论面；不要因为默认面是托管就建议跳过 `/visual-plan`；根据用户所有权、隐私、共享、品牌需求选择正确 Plan 模式。
20. 默认通过 Plan MCP connector 创建计划，绝不可作为内联聊天内容交付——不要 Markdown 散文、ASCII 草图、表格或围栏线框图。
21. 如果 `plan`（或 legacy `agent-native-plans`）工具不可见，先通过宿主 `tool_search` 发现；如果仍缺失，停止并给用户客户端特定 reconnect 步骤，而不是临时做内联计划。
22. 发布前或连接器/认证错误出现时，阅读 skill 目录 `references/connection.md`；它是 never-inline 规则、connector discovery 和 per-client reconnect 步骤的单一真相源；local-files privacy mode 是例外。
23. 若 `AGENT_NATIVE_PLANS_MODE=local-files` 或用户要求完全本地文件/无托管 Plan 写入，改用 Local-Files Privacy Mode，仅沿用代码研究和计划撰写指导。
24. Core Workflow 步骤 1：遵循宿主 agent 正常规划流程：检查代码库，必要时委托广泛探索，收集所需信息，生成计划前按需问原生澄清问题；如果已有源计划，从用户粘贴、引用文件或最近可见 agent 上下文获取其准确文本；不要发明源文本。
25. Core Workflow 步骤 2：调用 `get-plan-blocks` 获取权威块目录——不要凭记忆标签创作；然后调用模式匹配的创建工具：`create-visual-plan` 用于文档优先计划（架构、后端、数据、重构、API），`create-ui-plan` 用于 UI-first，`create-prototype-plan` 用于 prototype-first，`create-plan-design` 用于 design-first，`create-visual-questions` 仅在用户明确要求视觉 intake questionnaire；已有源计划时，作为 `planText` 传入，保留原计划有用意图，同时产出独立计划文档，不是修订备忘录。
26. Core Workflow 步骤 3：UI/产品计划，先组合顶部 canvas 与主要 wireframes 和 annotated states，然后用原生块写文档（见 `references/canvas.md` 和 `references/document-quality.md`）；对带用户可见影响的大型产品架构计划，在抽象架构或模式表之前加一个具体「在应用中是什么样」视觉；让文档接近 agent 通常输出的独立 Markdown 计划；如果提供了已有计划，传承正确事实和决策，不引用前稿或解释版本差异；非视觉计划跳过顶部视觉面，把 `diagram`、`data-model`、`api-endpoint`、`diff`、`file-tree`、`code`、`annotated-code` 块直接放在相关散文旁。
27. Core Workflow 步骤 3 宽布局：宽文档布局由 renderer 拥有并有意 allowlist：只有字面代码评审面（`diff`、`annotated-code`）和 `tabs` 块（垂直方向或类似 diff 子项）可宽于散文；`api-endpoint`、`openapi-spec`、`data-model`、`json-explorer`、`wireframe`、question 和 `custom-html` 块保持正常文档流，除非其自身渲染器另有规定。
28. Core Workflow 步骤 4：展示返回的 Plans 链接或内联 MCP App 并请用户评审；始终在聊天中包含实际 URL，让下一步在 CLI 或其他纯文本宿主中是点击；当宿主暴露嵌入式浏览器/预览面板且工具可打开任意 URL 时，自动打开返回计划 URL 便于评审——这是便利和冒烟测试，绝不是唯一交接或访问模型。
29. Core Workflow 步骤 4 续：计划应开箱即用于本地 agent 和本地浏览器会话；如果已登录嵌入式浏览器无法读取本地计划而匿名/工具检查可读，修复 app/action 所有权或访问路径，不要手动补丁单个计划；对高风险计划（架构、后端、数据、多文件或有风险），也在用户阅读时启动 Self-Review Before Handoff 自审 pass，而不是阻塞交接。
30. Core Workflow 步骤 5：托管计划，在编辑前、评审后、任何长暂停后和最终回复前调用 `get-plan-feedback`；将 `anchorDetails`、resolver intent、最近评审事件和浏览器交接的聚焦截图视为确切变化和每条评论指向的真相源。
31. Core Workflow 步骤 6：托管计划，用 `update-visual-plan` 应用变更，优先 targeted `contentPatches`；将顶层 `content` payload 视为完整替换，不是合并；不要发送部分 `content` 对象来添加 canvas 或一个块；如果必须完整替换或 `replace-blocks`，立即在写入前调用 `get-visual-plan`，传其 `plan.updatedAt` 作为 `expectedUpdatedAt`，并传承每个现有块和视觉面；绝不复用早期读取或反馈 payload 的 revision。
32. Core Workflow 步骤 6 续：为源码控制友好编辑，使用 granular `patch-visual-plan-source` 操作针对 MDX 文件，而不是重新生成计划；`replace-file` 也是破坏性的，且需要同样新鲜 `expectedUpdatedAt` fence。
33. Core Workflow 步骤 7：每次托管计划写入后，再次调用 `get-visual-plan` 并比较持久化文本、块 ID/数量、canvas frames 和 prototype 与预期结果；成功 mutation 响应不是无关内容幸存的证明；如果编辑处理了 agent-targeted feedback，只有在此验证调用后才对线程调用 `resolve-plan-comment` 并对其评论调用 `consume-plan-feedback`；两者都做，使已处理反馈既不 visibly open 也不作为 pending work 返回。
34. Core Workflow 步骤 8：托管计划，仅在用户想要可分享凭据或 repo check-in 工件时用 `export-visual-plan` 导出。
35. Self-Review Before Handoff：该对抗性自审 pass 是 opt-in 不是默认；仅对高风险计划运行——不可逆迁移、安全敏感工作，或用户明确要求额外严谨——否则跳过；它大约使计划生成成本翻倍，所以小、UI-only、单决策或普通计划默认跳过，不运行。
36. 自审运行时要便宜且非阻塞：先展示计划，并行评审；发布链接让用户开始阅读，然后并行跑评审——绝不让用户等待。
37. 评审已写计划，不要重新调研；批评计划文本及其自身块；起草时已完成 grounding，所以评审检查输出而不是重新探索 repo。
38. 生成一个 skeptical reviewer，其唯一工作是找弱点、缺失或错误——不是赞美；指向：隐式或未做的难逆决策（wire format、public ids、data-model shape、auth、ownership）；未锚定真实文件或符号的步骤；计划应承诺一个却给选项菜单；明显缺失决策（what happens when X?、why not Y?）；填充或单步 filler。
39. 修复 vs 询问：用 `update-visual-plan` `contentPatches` 自行应用明确修复——模糊 non-goals、未锚定声明、明显缺失决策；把真正判断调用路由回用户：加入底部 `question-form` Open Questions 块或批到正常 ask-user-question 流；不要默默决定它们。
40. 不要在用户阅读中途惊喜：大计划上，在编辑器加载前应用补丁；否则简要说明自审正在运行，使计划变化符合预期；下次响应时总结评审改变了什么以及向用户暴露了什么待决定。
41. 创建计划前或读取源计划后选择视觉表面；不要默认添加视觉装饰。
42. UI/产品计划顶部 canvas 通常是主要评审面；把第一个有意义的 wireframes 放那里，不要埋为文档体块；状态重要时用多个 canvas artboards，如 default view、overflow menu/popover、side panel、loading、error；在 frames 旁用 `targetId` 加 `placement` 放短注释；实现细节、取舍、文件地图、数据契约、风险、验证留在 canvas 下方文档体。
43. 当用户要求 flow、storyboard、journey、wireframe、canvas 或 what this looks like 时，视为 canvas-first 请求；每个用户可见状态一个 artboard，仅连接相邻 transitions，产品注释用短 canvas annotations；不要因为 HTML diagrams 更快写就用文档体 `diagram` 块替代请求的 storyboard；diagrams 属于 canvas 下方用于后端机制、架构或数据流解释。
44. 将产品 wireframes 和解释/元 diagrams 分开；从像讨论中 app 状态的纯屏幕开始，不在 UI 内嵌入 callout prose 或架构注释；箭头、标签、契约、数据流和模式解释放在单独 annotations、单独 canvas diagrams 或文档体。
45. 当计划触及现有 app，绘制前检查当前 shell/components；第一个 artboard 应看起来像真实 app 且密度相同：现有 sidebars、toolbar placement、overflow menus、app chrome 和 framework agent chrome 保持真实位置；把次级表面建模为单独状态，如 top-right overflow popover、sheet、panel、loading state 或单独 AgentSidebar，而不是发明永久 inspector 或把 framework chrome 折进产品 UI。
46. 对仅架构、仅后端、数据迁移、仅文案或其他非视觉计划无视觉面；不要用顶部 canvas 做架构图、依赖图、文件计划、API 契约或仅数据流评审；仅当关系需要视觉解释时用文档加局部内联图，通常每个推荐或决策一个空间图；优先 grouped regions、layers、quadrants、matrices 或 before/after panels 而非单轴链，除非关系确实顺序。
47. 仅 canvas 用于一个静态屏幕、前后对比、组件状态、小 popover 或不需要点击的视觉方向；将这些 wireframes 放在 `content.canvas`，省略 `content.prototype`。
48. Canvas + prototype 用于多步 UI 流、onboarding、wizards、review/approval flows、导航变化或评审者需要操作行为的任何事；静态 wireframes 放 `content.canvas`，对齐的功能 prototype 放 `content.prototype`，依赖顶部视觉 tabs 切换；两者都有时默认打开 Wireframes tab；prototype 保留为交互后续视图。
49. 默认 wireframes；干净极简 UI、高 UX 标准或引用 Linear/Vercel 描述的是内容和密度标准；它们不要求全保真设计模式；除非用户明确要求 branded、pixel-accurate、production-like 或 full visual design，否则用 renderer-owned wireframes；这保持每个 canvas 屏幕可检查且全部内容可见。
50. Prototype-first 当用户要求操作 UI 或交互是主要问题时；用 `create-prototype-plan`，它仍保留有用静态 mock。
51. 混合 canvas + prototype 计划，重用 labels 和 IDs；除非明确单面，一起 patch surfaces；输出审计读 observability skill：支持 single-app 和 workspace tables，保留 app previews，保持 audit、synthesis、diffs 和应用变更 admin-gated。
52. 将 higher fidelity、pixel-accurate、polished mockup、production-like、real design 和 not a sketch/wireframe 视为 design-first 语言，即使请求也说 mockup；新计划用 `create-plan-design`；已有计划保持同一 plan id 并调用 `update-visual-plan`，带 `set-visual-render-mode` patch，使用 renderMode: "design"，并在同一更新中升级 screen HTML/CSS；将结果 grounding 到真实 app shell、tokens、typography、spacing 和 states，并加稳定 `data-design-id` targets；把 scoped styles 放在每个 screen 的 `css` 字段，绝不在 `<style>` 标签；viewer-local Clean toggle 只改变一个浏览器的 wireframe 偏好，不是保真升级；不要创建重复计划处理保真后续。
53. Wireframe quality：创作任何 wireframe / `<Screen>` / `WireframeBlock` 前，阅读 skill 目录 `references/wireframe.md`；它是 HTML wireframe 质量的单一真相源，与 `/visual-plan` 和 `/visual-recap` 共享；不要凭记忆创作 wireframes；UI recap/plan wireframes 必须满足严格质量标准——full-width chrome、pinned bottom bars、真实产品内容、before/after comparability、正确 `surface` preset、`--wf-*` tokens 而非 hex、无 `<html>`/`<style>`/font 标签。
54. Canvas：创作或编辑任何 canvas、artboard 或 annotation 前，阅读 `references/canvas.md`；它是 canvas/artboard 机制的单一真相源；不要凭记忆创作 canvas layouts；canvas 是静态 UI mockups 的单一真相源：`surface` 锁定每个 artboard footprint，mixed surfaces 分 lanes 布局，annotations 是纯文本 designer notes，用 `targetId`/`placement` 锚定，编辑是外科式 `contentPatches`；canvas artboards 使用与文档体 `WireframeBlock` screens 相同 HTML wireframe 路径：用语义 HTML fragment 创作 `<Screen surface="..." html={...} />`；不要在 canvas `<Screen>` 标签内创作新的 kit-tree 子项如 `<FrameScreen>`、`<Card>`、`<Row>`、`<Btn>`；这些是旧计划兼容标记，会产生脆弱 canvas 布局。
55. Document quality：创作计划文档前，阅读 `references/document-quality.md`；它是文档质量标准单一真相源；不要凭记忆写文档；文档是严肃技术计划，不是营销：outcome-first、prose-first、self-contained、用正确原生块构建、开放问题在单一底部 `question-form`，交接前视觉检查。
56. Good vs bad exemplar：创作计划前阅读 `references/exemplar.md`；其中有 UI-first 计划和 `/visual-plan` 的 worked example，以及要避免的反模式。
57. Authoring invariants：`content` 是完整替换；传 `content` 或模式的便捷数组（`screens`/`transitions` 或 `states`/`components`），绝不同时传；create actions 拒绝混合源，以免第二 payload 静默丢弃 CSS、frames 或文档块。
58. Authoring invariants：design screen 的 scoped `css` 是工件一部分；在 prototype screen 及其匹配 canvas frame 上都保留它，并用 renderer-owned `--wf-*` tokens 实现可移植颜色和字体。
59. Authoring invariants：rich-text `data.markdown` 必须包含实际运行时换行；不要给计划一行 Markdown 值包含字面 `\n` 转义文本，否则整个 section 渲染成一个标题；当周围 Markdown 仍有真实换行时，代码示例中转义换行可以。
60. Authoring invariants：canvas artboards 不滚动；保持 wireframe HTML 自然流，当屏幕超过 surface preset 时设置更大 frame `height`；保持 surface 宽度，交接前在默认缩放检查底边。
61. Authoring invariants：每次托管写入后，重读结构化内容并检查 live Plan surface；有效 JSON payload 不是 CSS 已加载或 Markdown 渲染成预期 heading/paragraph/list 结构的证明。
62. Tool Guidance `create-visual-plan`：每个 agent 任务/运行开始一个结构化视觉计划，或通过传 `planText` 导入已有文本计划；`content` 可包含无视觉面、仅 canvas 或 canvas + prototype。
63. Tool Guidance `create-ui-plan`：当工作主要是产品 UI 时开始 UI-first 计划。
64. Tool Guidance `create-prototype-plan`：开始 prototype-first 计划，带功能顶部评审面；如果交互本身也必须高保真，将每个 screen 的 `renderMode` 设为 `design` 并通过 `css` 传 scoped styles；否则用 `create-plan-design` 做 design-first 评审。
65. Tool Guidance `create-plan-design`：开始全保真 branded Design-tab 计划，可选匹配 Prototype tab。
66. Tool Guidance `convert-visual-plan-to-prototype`：将现有 HTML wireframe canvas 转为 prototype 计划。
67. Tool Guidance `create-visual-questions`：仅在用户明确要求视觉 intake questionnaire 时使用，不作为 `/visual-plan` preflight。
68. Tool Guidance `update-visual-plan`：用 targeted `contentPatches` 修订内容、状态或评论（见 Core Workflow 步骤 6-7）；当将现有计划提升到高保真时，使用 `set-visual-render-mode` 与 renderMode: "design"，并配合有意 screen HTML/CSS；仅 render mode 只去除 sketch 处理；`replace-blocks` 和完整 `content` 替换需要来自新鲜 `get-visual-plan` 调用的 `expectedUpdatedAt`。
69. Tool Guidance `read-visual-plan-source`：读取规范计划为 `plan.mdx`、可选 `canvas.mdx`、可选 `.plan-state.json` 和 JSON。
70. Tool Guidance `patch-visual-plan-source`：通过稳定 block、artboard、annotation、component 或 wireframe-node id 应用 granular MDX AST patches；优先这些 targeted 操作；`replace-file` 需要来自新鲜 `get-visual-plan` 调用的 `expectedUpdatedAt`。
71. Tool Guidance `import-visual-plan-source`：从 MDX 文件夹创建或替换计划。
72. Tool Guidance `get-visual-plan`：读取当前结构化计划、导出 HTML、annotations 和 `plan.updatedAt`；也返回用于源工作流的 MDX 文件夹；在破坏性写入前立即重读以获得其并发 fence，并在每次写入后再次读取以验证持久化状态。
73. Tool Guidance `get-plan-feedback`：读取未消费的人类反馈；频繁使用；返回 grouped threads、精确 anchor details、expected resolver 和最近 review-event payloads，使 agent 只处理给它们的评论。
74. Tool Guidance `get-plan-blocks`：创作前解析 block tags——不要记标签；先调用获得 live block registry 的权威 tag names、required fields 和 prop shapes。
75. Tool Guidance `export-visual-plan`：导出 HTML、Markdown fallback、结构化 JSON 和 MDX 文件供 repo check-in。
76. 当用户批评计划外观或结构，修复 renderer 或此 skill——绝不要手工编辑一个存储计划；把反馈变成更好指导。
77. Local-Files Privacy Mode：当用户不想要托管 Plan 数据库写入——无 DB 写入、无 Plan MCP publish、完全本地/离线/私有规划、repo-owned source-controlled artifacts，或 `AGENT_NATIVE_PLANS_MODE=local-files`——除 schema-only `get-plan-blocks` 目录查找外，不要调用任何托管 Plan 工具。
78. Local-Files Privacy Mode：创作本地 MDX 文件夹并用 `plan local check` / `plan local serve` / `plan local verify` 预览；使用前阅读 `references/local-files.md`；只沿用 Core Workflow 的代码研究和计划撰写指导；托管一切由 local bridge 替代。
79. 注释锚点：适用于托管计划 with `get-plan-feedback`/`update-visual-plan`；local-files 模式不要调托管 feedback/update 工具；直接解释 file/chat feedback，编辑 MDX 文件，重跑 local bridge check/serve/verify 命令，报告新的 local URL。
80. `get-plan-feedback` 返回 rich anchors——行动前阅读；Coordinate frames：`targetX`/`targetY` 是元素内百分比；bare `x`/`y` 是整个计划文档百分比；`canvasX`/`canvasY` 是设计 canvas 原始 board-world 像素。
81. Wireframe pins：anchors 包含 `targetNodeId` 和 `targetNodePath`（如 card > list > listItem Acme Inc）标识精确 kit node；直接用 `targetNodeId` 配 wireframe node patch ops；design artboards 用 `data-design-id` 值配 `update-design-element-style`；优先 node id/path 而非 raw coordinates；无 node id 时才回退坐标加聚焦截图（红圈标记精确点）。
82. Text quotes：用 `contextBefore`/`contextAfter` 对当前 prose 解析 `textQuote`；如果 `ambiguous: true`，问用户——不要猜。
83. Detached comments：`get-plan-feedback` 标记 `detachedThreads`；对重写内容 reconcile，绝不静默丢弃。
84. Routing：`resolutionTarget` 是唯一路由信号：对 `agent` 行动，把 `human` 当上下文；`@mentions` 是要通知的人，绝不是路由信号。
85. Two-axis state：把每个 ingested comment 标为 consumed（`update-visual-plan` 上 `consumedCommentIds`）；只对实际处理的 agent-targeted comments 设 `status=resolved`；human-targeted 保持 open；当编辑处理反馈，先重读持久化计划并验证请求变更；然后才调用 `resolve-plan-comment` 和 `consume-plan-feedback`；绝不要只沿一个轴标记已处理反馈。
86. Visibility & Sharing：用 `set-resource-visibility` 改变谁可见计划（public、login、org-scoped）；用 `share-resource` 通过 email 或 role 授予特定用户或角色访问；在分享任何覆盖未发布或私有工作的计划前设可见性门——默认最窄范围满足评审需求。
87. Setup & Authentication Coding agent (CLI)：用 `npx @agent-native/core@latest skills add visual-plans` 一次安装；它安装 Plans skills、注册 hosted Plans MCP connector，并为所选本地客户端运行 auth/setup（一次性浏览器登录是预期）；之后 `/visual-plan`、`/visual-recap`、`/visualize-repo` 是安装的 slash commands。
88. 如果只需一个命令，用 `skills add visual-plan`、`skills add visual-recap` 或 `skills add visualize-repo`；其他 planning modes（`create-ui-plan`、`create-prototype-plan`、`create-plan-design`、`create-visual-questions`）是 MCP tools 可从 `/visual-plan` 到达，不是单独 slash commands。
89. 传 `--no-connect` 注册 connector 而不认证，然后准备好时运行 `npx @agent-native/core@latest connect https://plan.agent-native.com --client all`，或选择更窄 `--client`；auth 和 MCP tool loading 每客户端 config/session。
90. Browser：打开 Plans editor 无需注册创建和编辑，作为 guest 工作；仅当想保存或分享时登录；登录会把 guest 计划 claim 到账户。
91. Sharing and commenting 需要账户：public/shared plans 任何有链接者可查看，但评论需要 agent-native 账户。
92. 完全离线无账户，本地运行 Plans app 并把计划同步到 repo 为 MDX；本地模式是单独高级路径，不是默认托管流。
93. Repo-wide visual docs：运行 `npx @agent-native/core@latest visualize-repo --open` 创建/更新 `agent-native.json`，seed `.agent-native/visual-docs/repo-overview`，打开 local bridge。
94. If Plans tool returns `needs auth`、`Unauthorized` 或 `Session terminated`，不要重试——停止并给用户 `references/connection.md` 里的 per-client reconnect 步骤，然后 connector 可用后继续。
95. Hosted default：连接 `https://plan.agent-native.com/mcp`。不要把共享秘密放进 skill 文件。

适用边界 · 注意事项

• 真正琐碎、无歧义的工作（typo、一行修复、单个明确函数、一句话能描述 diff）不要使用，直接改。
• 架构/后端/数据迁移/纯文案等非视觉计划不要加顶部视觉面，也不要用顶部 canvas 做架构图、依赖图、文件计划、API 契约或纯数据流评审。
• 小、UI-only、单决策或普通计划默认不要运行 Self-Review Before Handoff；不可逆迁移、安全敏感或用户明确要求额外严谨时才运行。