@agent-native/core 0.42.0 → 0.43.0

package/dist/cli/skills.d.ts

@@ -5,8 +5,8 @@
  */
 import { type AppSkillManifest } from "./app-skill.js";
 import { type ClientId } from "./mcp-config-writers.js";
-export declare const VISUAL_PLANS_SKILL_MD = "---\nname: visual-plan\ndescription: >-\n  Use Agent-Native Plans when coding-agent work needs an interactive structured\n  plan document with inline diagrams, implementation maps, optional UI/product\n  wireframes or prototypes, annotations, and comments.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture, backend, data, and refactor plans\nusually start in the document with local diagrams near each claim. UI and product\nplans should still start with the top canvas/prototype when screens or behavior\nare what the user needs to review.\n\n`/visual-plan` is the canonical command and the main entry point. Use `/ui-plan`\nwhen the work is primarily product UI and review should start with the screens.\nUse `/prototype-plan` when review should start with a functional live prototype.\nUse `/plan-design` when review should start with full-fidelity branded design.\nUse `/visual-questions` only when the user explicitly wants a visual intake form\nbefore planning. When a Codex, Claude Code, Markdown, or pasted plan already\nexists, `/visual-plan` uses that source plan as the starting point and builds\nthe review surface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan when work is multi-file, ambiguous, long-running,\nrisky, or UI-heavy, when architecture / data flow / UI direction / options /\nopen questions would benefit from inline diagrams or structured blocks, when the\nuser needs to react to a direction before you implement, or when an existing text\nplan needs a richer review surface.\n\n## Plan Discipline\n\n- **Gate hard.** A polished visual plan is the most expensive plan form; only\n  invest when a wrong direction is costly. Skip it for trivial, unambiguous work\n  \u2014 typos, one-line fixes, a single well-specified function, anything whose diff\n  you could describe in one sentence \u2014 and just make the change. Never pad a plan\n  with filler and never ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing `actions/` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses \u2014 existing actions, schema,\n  components, helpers \u2014 before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them \u2014 wire format, public ids,\n  data-model shape, auth and ownership boundaries \u2014 and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Preserve existing plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material. Preserve its\n  intent, do not invent codebase facts, label inferred visuals as inferred, and\n  build the visual review structure around the plan the user already has.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it \u2014 explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call `create-visual-questions` from\n  `/visual-plan`; keep any answerable follow-up inside the plan itself as a\n  bottom `question-form` Open Questions block. Otherwise state the assumption\n  explicitly and proceed, and put anything unresolved in an open-questions block.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step \u2014 do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with `update-visual-plan` rather than only changing course in\n  chat, and re-read the approved plan before major steps.\n\n## Core Workflow\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Decide whether the plan needs a top visual surface with the rules below, then call\n   `create-visual-plan` with the title, brief, source, repo path, and structured\n   `content` blocks. When a source plan already exists, pass it as `planText`\n   and preserve the original plan's intent while adding structured review\n   content.\n3. Compose or enrich any top UI/product visual surface from the kit and write the\n   document with native blocks (see the cores below). Keep the document close to\n   the Markdown plan the agent would normally output, or to the existing plan\n   when one was provided. For architecture, backend, refactor, API, data-model,\n   migration, or code plans, usually omit `content.canvas` and\n   `content.prototype`; put `diagram`, `mermaid`, `api-endpoint`,\n   `openapi-spec`, `data-model`, `diff`, `file-tree`, `json-explorer`,\n   `code` and `annotated-code` blocks directly next\n   to the relevant prose. Skip the top visual surface for non-visual work.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review; do not rely on this as the only handoff.\n   Treat that browser open as a convenience and smoke test, not as the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. Call `get-plan-feedback` before editing, after review, after any long pause,\n   and before the final response. Treat `anchorDetails`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. Apply changes with `update-visual-plan`, preferring targeted `contentPatches`.\n   When the user wants source-control friendly edits, use\n   `patch-visual-plan-source` against the MDX files instead of regenerating the\n   plan.\n7. Export with `export-visual-plan` only when the user wants a shareable receipt\n   or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nFor high-stakes plans \u2014 architecture, backend, data-model, migration, multi-file,\nor otherwise risky work \u2014 run one adversarial self-review pass before treating the\nplan as final. Skip it for small, UI-only, or single-decision plans where the cost\noutweighs the value. Keep the pass cheap and non-blocking:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel \u2014 never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong \u2014 not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with `update-visual-plan`\n  `contentPatches` \u2014 vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom `question-form` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in `content.canvas` and omit `content.prototype`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  `content.canvas`, add the aligned functional prototype in\n  `content.prototype`, and rely on the top visual tabs to switch between them.\n- **Prototype-first** when the user explicitly asks for `/prototype-plan`, asks\n  to operate the UI, or when interaction is the main question. Use\n  `create-prototype-plan`, which still preserves static mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\n## Wireframe & Canvas Core\n\nThis section is shared by `/visual-plan` and `/ui-plan`, and is the single\nsource of truth for how wireframes and the canvas work. The wireframe-quality\nrules below are additionally shared, word for word, with `/visual-recap`; the\ncanvas/artboard mechanics apply only to `/visual-plan` and `/ui-plan`. Do not\nparaphrase any of it per command.\n\n<!-- SHARED-CORE:wireframe-quality START -->\n\n**A wireframe is an HTML mockup. The renderer owns the look; you write the\ncontent.** Set `data.html` to a self-contained, semantic HTML fragment of the\nscreen and set `data.surface`. The renderer owns the surface footprint/aspect,\nthe dark/light theme, the hand-drawn font, and the rough.js sketch overlay \u2014 you\nnever write `<html>`/`<body>`/`<script>`/`<style>` tags, font-family, hex colors,\nor any width/height/coordinates. You write real HTML layout and real product\ncontent; the renderer styles and roughens it.\n\n**A wireframe block's data is an HTML screen plus a surface:**\n\n```json\n{\n  \"surface\": \"browser\",\n  \"html\": \"<div style=\\\"display:flex;flex-direction:column;gap:10px;padding:16px;height:100%\\\"><h1>Sign in</h1><p class=\\\"wf-muted\\\">Use your work email to continue.</p><div class=\\\"wf-card\\\" style=\\\"display:flex;flex-direction:column;gap:10px\\\"><label>Email<input value=\\\"jane@acme.co\\\" /></label><label>Password<input value=\\\"\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\\\" /></label><label style=\\\"display:flex;align-items:center;gap:8px\\\"><input type=\\\"checkbox\\\" checked /> Remember me</label><button class=\\\"primary\\\">Sign in</button></div><a href=\\\"#\\\">Forgot password?</a></div>\"\n}\n```\n\n**Write PLAIN semantic HTML and let the renderer style it.** Bare elements\n(`h1`/`h2`/`h3`, `p`, `button`, `input`, `<input type=\"checkbox\">`, `a`, `hr`)\nare auto-themed \u2014 no classes needed. Helper classes carry the rest:\n\n- `.wf-card` / `.wf-box` \u2014 a bordered, padded container (a panel, a list item).\n- `.wf-pill` / `.wf-chip` \u2014 a rounded tag or filter; add `.accent`\n  (`<span class=\"wf-pill accent\">`) for the accent-filled variant.\n- `.wf-muted` \u2014 secondary/muted text (or use `<small>`).\n- `button.primary` or any element with `[data-primary]` \u2014 the accent-filled\n  primary button.\n\n**Use the `--wf-*` tokens for any custom color, never hex.** The renderer flips\nthese on light/dark, so reading them is what keeps a mockup correct in both\nthemes. For any inline border, background, or text color, reference a token:\n`style=\"border:1.4px solid var(--wf-line)\"`. The tokens are `--wf-ink` (text),\n`--wf-muted` (secondary text), `--wf-line` (borders/dividers), `--wf-paper`\n(page background), `--wf-card` (raised surface), `--wf-accent` /\n`--wf-accent-fg` / `--wf-accent-soft` (brand action), `--wf-warn`, `--wf-ok`,\nand `--wf-radius`. Never hard-code a hex color and never set `font-family` \u2014 the\nrenderer owns the sketch/clean font.\n\n**Lay out with inline `style` flex/grid.** You write the real layout \u2014\n`display:flex; flex-direction:column; gap:10px; padding:16px` and so on \u2014 and the\nrenderer never repositions anything. Compose the actual product: reproduce the\ncurrent screen, then show the modification. Real labels, real counts, real dates,\nreal button text grounded in the screen you read; not lorem or gray bars.\n\n**Surface presets \u2014 match the real footprint, never default to desktop+mobile.**\nPick the `surface` that matches what the user will actually see:\n\n- `browser`: a web page that needs a browser chrome frame around it.\n- `desktop`: a full desktop app page or app shell.\n- `mobile`: a phone screen, only when the work is genuinely mobile.\n- `popover`: a small floating menu, dropdown, or inline popover.\n- `panel`: a side panel, inspector, or sidebar widget.\n\nA sidebar popover renders as a small surface, not a desktop page and a phone\nframe. Do not emit `desktop` + `mobile` variants unless responsive behavior\nactually changes the layout. For a component or widget, show one broader\napp-context frame only when placement affects understanding, then the focused\ncomponent states.\n\n**Model the actual component shell for small surfaces.** A rendered UI change\nbelongs in a wireframe; reserve `diagram` for architecture, dependency, state,\nor data-flow relationships. Popovers, dropdown menus, command palettes, and\ncontext menus use `surface: \"popover\"` unless the surrounding page placement is\nthe point of the change. Dialogs, sheets, inspectors, sidebars, and long\nproperty panels use the matching `panel` / `desktop` surface as appropriate.\nShow the real chrome: trigger or anchor when it matters, title/header row,\ntop-right actions, separators, fields, options, selected states, body content,\nand footer actions that are visible in the workflow.\n\n**Modify, don't redesign.** When the task changes an existing screen, reproduce\nthe current screen's real layout and footprint FIRST, then change only the delta\nand call it out with a single annotation. Do not restack the page into a new\nlayout. For net-new surfaces, compose from the real app shell.\n\n**Classify mockup scope before implementation.** Before turning a plan mockup\ninto source code, decide whether each artboard represents the whole page/app\nshell, a route body inside an existing shell, or a component/sub-surface. If an\nartboard includes navigation, sidebars, auth banners, or a signup/login form,\nmap those pieces to the real shared shell/auth components instead of nesting the\nentire mockup inside the current page. When a mockup references the product's\nstandard signup/login page, find and reuse that existing implementation; do not\napproximate it from the wireframe.\n\n**Zoom in on sub-surfaces, don't redraw the page.** For a small sub-surface (a\npopover, menu, dialog, toast), show the full screen once, then add a small\nseparate artboard whose `html` contains ONLY that sub-surface \u2014 do not re-draw\nthe whole page around it, and do not scale a duplicate up. Pick the matching\n`surface` (e.g. `popover`) so the footprint is right; never widen a popover to\npage width.\n\n**Loading / skeleton states.** Set `data.skeleton: true` on the wireframe and\nfill the `html` with neutral, textless placeholder geometry \u2014 boxes and bars\nbuilt as `<div>`s with `background:var(--wf-line)` and explicit heights/widths,\nno labels or copy. The renderer drops borders, sketch, and color into the\nskeleton register automatically. Never escape to a `custom-html` document block\nto fake a loader.\n\n**Editing an existing mockup.** To change one element, text, or color in an\nexisting html mockup, do NOT regenerate the frame \u2014 call `update-visual-plan`\nwith `contentPatches: [{ op: \"patch-wireframe-html\", blockId, edits: [{ find,\nreplace }] }]`. Each `find` is a unique snippet of the current html (read it\nfirst with `get-visual-plan`); set `all: true` on an edit to replace every\noccurrence. The result is re-sanitized.\n\n**Treat the wireframe border as part of the visible design.** Always wrap HTML\nwireframe content in a root container with real inner padding before drawing\ncards, fields, pills, labels, or controls. Use at least 14-16px of padding,\n`box-sizing: border-box`, `height: 100%`, and `gap` between child rows so the\nfirst row never sits flush against the screen border. Keep text away from\nborders: every container, field, button, menu item, and annotation needs enough\npadding and line-height to read cleanly in the rendered Plan view.\n\n**Lay out children safely so they never collide.** Use HTML flex/grid with\n`gap`, `min-width: 0`, and sensible overflow. Avoid negative margins, absolute\npositioning, or fixed child widths that can collide when the renderer switches\nbetween light/dark, sketch/clean, or different zoom levels.\n\n**Do not wrap intentionally single-line labels.** For tab rails, breadcrumbs,\nfile chips, code filenames, and other deliberately single-line labels, do not\nlet long text wrap. It is acceptable and usually preferable to use\n`white-space: nowrap`, `overflow: hidden`, and `text-overflow: ellipsis` (or\nabstract bars) so the wireframe demonstrates the actual layout behavior instead\nof producing ugly vertical text. Use horizontally scrollable or clipped rails\nfor overflow.\n\n**Fill the frame; keep labels short.** Each artboard is a fixed-size surface \u2014 compose enough realistic HTML to fill it top to bottom with even vertical rhythm; never leave a large empty band. On desktop/app-shell sidebars, let the nav stack flex to fill (`flex:1`) and add any persistent bottom action/status after it so the rail reads complete in taller frames. On mobile especially, flow real rows down the whole screen (status bar, header, then list/detail content) rather than a header floating above a gap. Keep every label short enough to sit on one line within its column \u2014 shorten the copy rather than relying on the frame to absorb it (long labels wrap or clip).\n\n**Before / after must be comparable.** When showing a state change, preserve the\nunchanged controls in both states so the reviewer can see exactly what moved or\nappeared; do not show an added control as a generic box floating elsewhere in\nthe surface. Place the new/changed affordance where the implementation puts it \u2014\nfor example, a new `Edit with AI` action in a popover header belongs in the\ntop-right header slot, aligned with the title, not in the body or footer. Use\nthe same frame size, scale, outer padding, border radius, and visual density on\nboth sides unless the change itself alters those properties, and let the frame\nheight fit the content rather than leaving a tall empty lower half.\n\n**Name the states with the column header, never inside the frame.** Put the two\nstates in a `columns` block and set each column's `label` to `Before` and\n`After` \u2014 the renderer draws that label as an `h4` heading above each frame. Do\nNOT bake a `Before`/`After` pill, title, or heading into the wireframe `html`: a\nlabel placed inside reads as part of the product UI, lands in a random corner,\nand clutters the comparison. The column header is the one and only place the\nstate name belongs.\n\n**Let the surface choose side-by-side vs. stacked.** The `columns` renderer lays\nnarrow surfaces (`mobile`, `popover`, `panel`) out side by side, and\nautomatically stacks wide surfaces (`desktop`, `browser`) vertically at full\ndocument width so a large frame is never crushed into a half-width column and\ncropped. Author both wireframes with the real `surface` and the matching\n`Before`/`After` column labels; do not hand-stack the pair into separate\ntop-level wireframes or duplicate the state name as body content.\n\n**Good example \u2014 a contacts list, surface `browser`.** A small, real screen\ncomposed from the helper classes and tokens, layout in inline flex, no fonts or\nhex colors:\n\n```html\n<div\n  style=\"display:flex;flex-direction:column;gap:12px;padding:16px;height:100%\"\n>\n  <div style=\"display:flex;align-items:center;justify-content:space-between\">\n    <h1>Contacts</h1>\n    <button class=\"primary\">New contact</button>\n  </div>\n  <div style=\"display:flex;gap:6px\">\n    <span class=\"wf-pill accent\">All 128</span>\n    <span class=\"wf-pill\">Favorites</span>\n    <span class=\"wf-pill\">Archived</span>\n  </div>\n  <div\n    class=\"wf-card\"\n    style=\"display:flex;flex-direction:column;gap:0;padding:0\"\n  >\n    <div\n      style=\"display:flex;align-items:center;gap:10px;padding:10px 12px;border-bottom:1.4px solid var(--wf-line)\"\n    >\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Jane Cooper</strong><br /><small>jane@acme.co</small>\n      </div>\n      <span class=\"wf-pill\">Lead</span>\n    </div>\n    <div style=\"display:flex;align-items:center;gap:10px;padding:10px 12px\">\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Marcus Lee</strong><br /><small>marcus@globex.io</small>\n      </div>\n      <span class=\"wf-pill\">Customer</span>\n    </div>\n  </div>\n</div>\n```\n\n<!-- SHARED-CORE:wireframe-quality END -->\n\n<!-- SHARED-CORE:canvas-surface START -->\n\n**Artboard placement is locked by the `surface`, not by coordinates.** The\nsurface locks the footprint and aspect; never set artboard width/height and\nnever use coordinates inside the wireframe HTML. Let canvas auto-placement\nhandle simple one-row boards. For mixed-footprint canvases, board-level artboard\n`x`/`y` is allowed and expected when it creates clear lanes.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters. Connect\nonly neighboring steps; never draw a long connector that skips across unrelated\nframes. Before handoff, inspect the top canvas at default zoom and move any\nframe whose label, connector, or annotation crosses another frame.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle Figma-style notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams are\ndifferent: keep them inline in the document, close to the recommendation they\nsupport, unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it, but new\nplans emit `html`. Do not author fresh kit-tree screens - write the HTML mockup\ninstead. Likewise, old or imported plans may carry coordinate-based regions or\nfree-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The `surface` drives each artboard's aspect\nand footprint, and the gutter parks notes by `targetId` + `placement`. The only\nnew-plan coordinate exception is deliberate board-level artboard `x`/`y` for\nmulti-lane mixed-surface canvases; never supply artboard width/height, note\ncoordinates, or wireframe-internal coordinates.\n\n<!-- SHARED-CORE:canvas-surface END -->\n\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan` and `/ui-plan`. It is\nthe single source of truth for the document below the canvas. Do not paraphrase\nit per command.\n\n<!-- SHARED-CORE:document-quality START -->\n\n**The document is a serious technical plan, not marketing.** Write it the way a\nstrong Claude or Codex implementation plan reads: outcome-first, prose-first,\nself-contained, and specific. State the objective and what \"done\" means, the\nscope and non-goals, the proposed approach with the key decisions and their\nrationale, ordered steps that name real files, symbols, actions, and data\nshapes, the risks, and a closing verification step (tests, build, or a checkable\nbehavior). Replace vague prose with specifics; never ship a step like \"make it\nwork.\" No hero art, gradients, logos, nav bars, slogans, value props, giant\nlanding-page headings, or marketing cards unless the user explicitly asks.\n\n**When top visuals exist, they and the document never duplicate each other.**\nFor UI work, the UI story lives in the top visual surface: canvas artboards for\nstatic inspection, plus prototype tabs when the flow should be functional. The\ndocument carries the technical depth the visuals cannot show \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation should\ncarry its own nearby inline `diagram` / `data-model` block plus file evidence\nand terse Problem/Solution/Why text. For architecture/code diagrams, prefer\nstandard two-dimensional layouts: paired before/after panels, layered diagrams,\nswimlanes, dependency maps, matrices, or grouped regions. Do not default to\nleft-to-right chains; use a line only when the relationship is truly a sequence.\nUse native `diagram` blocks with `data.html` / `data.css` for these richer\nlayouts; the fragment may use semantic HTML and inline SVG, and the renderer\napplies the viewer's sketch/clean style. Leave room for the sketch font: keep\nlabels short, give nodes generous width, and place boundary/annotation labels in\nunused space instead of over nodes. For small text/SVG changes to an existing\nHTML diagram, use `patch-diagram-html` with a unique `find`/`replace` snippet\ninstead of resending the whole `data.html` string. Legacy `nodes` / `edges` are\nonly for tiny previews or genuinely linear step flows. Repeat a wireframe in the document only\nfor a genuinely new detail view or comparison. Skip the visual surface entirely\nfor non-visual work and write a clean rich document. For a simple binary UI\nvisual choice, show the two directions in the canvas only; do not repeat the\nsame options as body wireframes, a `decision` block, or prose. Put the actual\nchoice in the bottom \"Open Questions\" form.\n\n**Use the right block, and make it carry substance.** For the authoritative,\nmachine-checked list of block types and their data schemas, call `get-plan-blocks`\n\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- `decision` ONLY for a genuinely-open either/or the reviewer must still pick\n  between \u2014 two or three option cards with real consequences. If you have already\n  committed to an approach, state it as settled prose or a `callout`, NOT a\n  `decision` block; a decision card for a question you have already answered just\n  reads as a confusing mid-document form. Never duplicate the same choice across a\n  `decision` block and the bottom Open Questions `question-form` \u2014 pick one home\n  for it. These are static records; do not style them like clickable tabs or chips\n  unless the renderer truly supports changing the selection.\n- `columns` for side-by-side before/after or current/target comparisons where\n  each side needs real nested blocks; label the columns clearly and avoid\n  stacking comparison blocks vertically when parallel reading is the point.\n- `diagram` for two-dimensional architecture, dependency, data-flow, or state\n  relationships, only when it clarifies something real. For architecture/code\n  diagrams, prefer `data.html` / `data.css` with semantic HTML and inline SVG so\n  the diagram can use panels, layers, matrices, arrows, annotations, and\n  responsive layout directly. Author diagram HTML with renderer-owned primitives\n  like `.diagram-panel`, `.diagram-card`, `.diagram-node`, `.diagram-box`,\n  `.diagram-pill`, `.diagram-muted`, and `[data-rough]`; they map to the plan's\n  Tailwind theme variables through `--wf-ink`, `--wf-muted`, `--wf-line`,\n  `--wf-paper`, `--wf-card`, `--wf-accent`, `--wf-accent-soft`, `--wf-warn`, and\n  `--wf-ok`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not\n  set `font-family` and do not hard-code hex, rgb, or hsl colors in diagram HTML\n  or CSS. Use legacy `nodes` / `edges` only for small previews or truly\n  sequential flows. In architecture/code plans, prefer a repeated section rhythm:\n  recommendation title, confidence and category badges, code-path evidence, a\n  local before/after or current/target spatial diagram, then concise\n  Problem/Solution/Why text. Labels must not overlap nodes, connectors, or each\n  other.\n- `tabs` for multiple states, directions, or comparisons. A tab that reveals\n  only prose usually means the plan is under-specified \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question in both a `decision` block and a\n`question-form`.\n\n**`custom-html` is a bounded escape hatch only** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\n\n**Before handoff, open the plan and check it.** Fix overlap, excessive\nwhitespace, clipped fragments, misleading inactive controls, poor contrast, and\nunreadable diagrams before asking for approval.\n\n<!-- SHARED-CORE:document-quality END -->\n\n## Good vs. Bad Exemplar\n\n<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard whose\n`data.html` is a real flex layout \u2014 a sidebar of links (`Inbox 12`, `Today 4`,\n`Done`), a main column with an `<h1>Today</h1>`, accent `.wf-pill`s for the\nfilters, a muted section label `OVERDUE`, and `.wf-card` task rows carrying real\ntitles, due dates, and a primary `button.primary` \u2014 styled only through bare\nelements, helper classes, and `--wf-*` tokens, so the renderer applies the\ncorrect desktop footprint, theme, and one subtle whole-frame wobble. Plain-text\ndesigner notes sit spaced off the frame, pointing only at the controls that need\nexplanation. Below it, a Claude/Codex-grade document: objective and\ndone-criteria, a few `code` blocks (grouped in a vertical `tabs` block when\nmore than one) showing the real shape of the load-bearing files, a `decision`\ncard weighing two real approaches,\nand a validation step \u2014 none of it repeating the canvas. If the task also\nchanges a multi-step completion flow, the same top area includes a Prototype tab\nwhose screens use the same labels and states as the canvas artboards, with\n`data-goto` controls for the sequence. This is the bar.\n\n**GOOD.** A `/visual-plan` for a backend architecture review: no top canvas.\nThe document opens with context and a legend, then repeats recommendation cards:\ntitle, confidence/category badges, a monospace grid of real file paths, one\ninline two-dimensional before/after or layered architecture diagram, and terse\nProblem/Solution/Why bullets using the codebase's vocabulary. The diagram uses\nspace to show boundaries, layers, and ownership; it is not a default\nleft-to-right chain. The plan ends with a top recommendation and a bottom\nquestion-form only if the next architecture direction is genuinely open. This is\nbetter than a top canvas because each diagram is local to the claim it supports.\n\n**BAD.** A `data.html` with hard-coded hex colors, a `font-family`, or fixed\npixel width/height; gray placeholder bars \"insinuating\" text on a non-skeleton\nframe; a forced desktop + mobile pair for a popover; floating bordered\nannotation cards hugging the frames; a fresh hand-authored kit-tree `screen`\ninstead of `html`; a multi-step UI flow with only static frames and no prototype\ntab; a mockup escaped into a document `custom-html` block; and a marketing-style\ndocument with a hero heading and value props that just restates what the canvas\nalready shows. Also bad: an architecture-only plan forced into a top canvas of\nlabeled boxes with overlapping text, where the actual code evidence and\nrecommendations live elsewhere. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-visual-plan`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing `planText`; `content` may include no\n  visual surface, canvas only, or canvas + prototype.\n- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.\n- `create-prototype-plan`: start a prototype-first plan with a functional top\n  review surface.\n- `create-plan-design`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only for the explicit `/visual-questions`\n  command, not as `/visual-plan` preflight.\n- `update-visual-plan`: revise content, status, or comments; prefer\n  `contentPatches` over regenerating the whole plan.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: read the current structured plan, exported HTML, and\n  annotations; it also returns the MDX folder for source workflows.\n- `get-plan-feedback`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and\nauthenticates it in the same step (a one-time browser sign-in at setup \u2014 this is\nintended), so the first tool call does not hit an OAuth wall:\n\n```bash\nagent-native skills add visual-plan\n```\n\nAfter that, `/visual-plan` (and `/visual-recap`, `/ui-plan`,\n`/prototype-plan`, `/plan-design`, `/visual-questions`) generate a plan and open\nthe editor. Pass `--no-connect` to\nregister the connector without authenticating, then run\n`agent-native connect https://plan.agent-native.com` whenever you are ready.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`,\ndo not keep retrying the tool. Authenticate the connector with\n`agent-native connect https://plan.agent-native.com` (OAuth-capable hosts can\ninstead re-run /mcp and choose Authenticate), then continue once the connector\nis available.\n\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do\nnot put shared secrets in skill files.\n";
-export declare const UI_PLAN_SKILL_MD = "---\nname: ui-plan\ndescription: >-\n  Use Agent-Native Plans for UI-first planning with an optional top pan/zoom\n  wireframe canvas, a refined Notion-like document, rich tabs, diagrams,\n  comments, drawing, and agent handoff.\nmetadata:\n  visibility: exported\n---\n\n# UI Plan\n\nUse `/ui-plan` when the task is primarily about product UI, user flows,\ninteraction details, component layout, or visual direction. The reviewable UI\ncomes first; implementation detail comes after the user has something concrete to\nreact to.\n\n`/visual-plan` remains the general command for architecture, backend, refactors,\nand mixed work. Use `/prototype-plan` when the UI review needs a functional live\nprototype instead of static screens. Use `/plan-design` when polish, brand, or\nvisual fidelity are material to the decision. Use `/visual-questions` only when\nthe user explicitly wants visual intake before planning. Use `/visual-plan` when\na text plan already exists and should become the source material for the review.\n\n## Plan Discipline\n\n- **Gate hard.** Use a UI plan when the surface is new, ambiguous, spans several\n  screens or states, or the direction needs agreement before coding. Skip it for\n  cosmetic one-liners \u2014 a color, a label, a spacing tweak \u2014 and just make the\n  change. Never ship a single-step or filler plan.\n- **Research before you draft.** Read the real components, routes, and design\n  tokens first; ground every mockup and the file map in actual files and symbols.\n  Delegate wide exploration to a sub-agent when the surface is large.\n- **Planning is read-only.** Make no source edits while building or reviewing.\n  Start editing only after the user approves the UI direction.\n- **Clarify vs. assume.** Do not ask how to build the UI \u2014 present the direction\n  and options as mockups and tabs. Ask a clarifying question only when an\n  ambiguity would change the design; use the host agent's normal\n  ask-user-question flow and batch 2-4 before finalizing. Do not call\n  `create-visual-questions` from `/ui-plan`; keep answerable follow-up inside\n  the same plan as a bottom `question-form` Open Questions block. Otherwise\n  state the assumption in the plan and proceed.\n- **The plan is the approval gate.** Ask the user to review and approve the UI\n  direction before you write code, and name the files/areas the work touches.\n\n## UI-First Workflow\n\n1. Follow the host agent's normal planning flow: inspect the codebase, gather\n   the UI/component context needed, and ask native clarifying questions as needed\n   before generating the plan.\n2. Call `create-ui-plan` with a UI-specific title, brief, source, repo path, and\n   structured `content`. The canvas comes first, the document second.\n3. Compose the top canvas from the kit (see the cores below): the key artboards\n   with real product content, designer notes, and connectors only for real\n   sequences. Skip the canvas when wireframes would not clarify the work.\n4. Continue below as a concise technical document that stays close to the\n   Markdown plan the agent would normally output \u2014 not a second copy of the\n   canvas \u2014 covering concrete files, contracts, phases, risks, and validation.\n5. Call `get-plan-feedback` before implementation, after review, after a long\n   pause, and before the final response. Treat `anchorDetails`, resolver intent,\n   recent review events, and any focused screenshots from browser handoff as the\n   source of truth for exactly what changed and exactly what each UI comment\n   points at. Apply changes with `update-visual-plan`, preferring\n   `contentPatches` for one frame, annotation, node, tab, or block. When the\n   user wants source-control friendly edits, use `patch-visual-plan-source`\n   against the MDX files instead of regenerating the plan.\n\n## Agent Handoff\n\nAfter the canvas and document, add a short handoff that names the chosen UI\ndirection, unresolved visual questions, and feedback that must be read before\ncode changes. Never claim feedback has been applied until `get-plan-feedback` or\nthe user has supplied it.\n\n## Wireframe & Canvas Core\n\nThis section is shared by `/visual-plan` and `/ui-plan`, and is the single\nsource of truth for how wireframes and the canvas work. The wireframe-quality\nrules below are additionally shared, word for word, with `/visual-recap`; the\ncanvas/artboard mechanics apply only to `/visual-plan` and `/ui-plan`. Do not\nparaphrase any of it per command.\n\n<!-- SHARED-CORE:wireframe-quality START -->\n\n**A wireframe is an HTML mockup. The renderer owns the look; you write the\ncontent.** Set `data.html` to a self-contained, semantic HTML fragment of the\nscreen and set `data.surface`. The renderer owns the surface footprint/aspect,\nthe dark/light theme, the hand-drawn font, and the rough.js sketch overlay \u2014 you\nnever write `<html>`/`<body>`/`<script>`/`<style>` tags, font-family, hex colors,\nor any width/height/coordinates. You write real HTML layout and real product\ncontent; the renderer styles and roughens it.\n\n**A wireframe block's data is an HTML screen plus a surface:**\n\n```json\n{\n  \"surface\": \"browser\",\n  \"html\": \"<div style=\\\"display:flex;flex-direction:column;gap:10px;padding:16px;height:100%\\\"><h1>Sign in</h1><p class=\\\"wf-muted\\\">Use your work email to continue.</p><div class=\\\"wf-card\\\" style=\\\"display:flex;flex-direction:column;gap:10px\\\"><label>Email<input value=\\\"jane@acme.co\\\" /></label><label>Password<input value=\\\"\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\\\" /></label><label style=\\\"display:flex;align-items:center;gap:8px\\\"><input type=\\\"checkbox\\\" checked /> Remember me</label><button class=\\\"primary\\\">Sign in</button></div><a href=\\\"#\\\">Forgot password?</a></div>\"\n}\n```\n\n**Write PLAIN semantic HTML and let the renderer style it.** Bare elements\n(`h1`/`h2`/`h3`, `p`, `button`, `input`, `<input type=\"checkbox\">`, `a`, `hr`)\nare auto-themed \u2014 no classes needed. Helper classes carry the rest:\n\n- `.wf-card` / `.wf-box` \u2014 a bordered, padded container (a panel, a list item).\n- `.wf-pill` / `.wf-chip` \u2014 a rounded tag or filter; add `.accent`\n  (`<span class=\"wf-pill accent\">`) for the accent-filled variant.\n- `.wf-muted` \u2014 secondary/muted text (or use `<small>`).\n- `button.primary` or any element with `[data-primary]` \u2014 the accent-filled\n  primary button.\n\n**Use the `--wf-*` tokens for any custom color, never hex.** The renderer flips\nthese on light/dark, so reading them is what keeps a mockup correct in both\nthemes. For any inline border, background, or text color, reference a token:\n`style=\"border:1.4px solid var(--wf-line)\"`. The tokens are `--wf-ink` (text),\n`--wf-muted` (secondary text), `--wf-line` (borders/dividers), `--wf-paper`\n(page background), `--wf-card` (raised surface), `--wf-accent` /\n`--wf-accent-fg` / `--wf-accent-soft` (brand action), `--wf-warn`, `--wf-ok`,\nand `--wf-radius`. Never hard-code a hex color and never set `font-family` \u2014 the\nrenderer owns the sketch/clean font.\n\n**Lay out with inline `style` flex/grid.** You write the real layout \u2014\n`display:flex; flex-direction:column; gap:10px; padding:16px` and so on \u2014 and the\nrenderer never repositions anything. Compose the actual product: reproduce the\ncurrent screen, then show the modification. Real labels, real counts, real dates,\nreal button text grounded in the screen you read; not lorem or gray bars.\n\n**Surface presets \u2014 match the real footprint, never default to desktop+mobile.**\nPick the `surface` that matches what the user will actually see:\n\n- `browser`: a web page that needs a browser chrome frame around it.\n- `desktop`: a full desktop app page or app shell.\n- `mobile`: a phone screen, only when the work is genuinely mobile.\n- `popover`: a small floating menu, dropdown, or inline popover.\n- `panel`: a side panel, inspector, or sidebar widget.\n\nA sidebar popover renders as a small surface, not a desktop page and a phone\nframe. Do not emit `desktop` + `mobile` variants unless responsive behavior\nactually changes the layout. For a component or widget, show one broader\napp-context frame only when placement affects understanding, then the focused\ncomponent states.\n\n**Model the actual component shell for small surfaces.** A rendered UI change\nbelongs in a wireframe; reserve `diagram` for architecture, dependency, state,\nor data-flow relationships. Popovers, dropdown menus, command palettes, and\ncontext menus use `surface: \"popover\"` unless the surrounding page placement is\nthe point of the change. Dialogs, sheets, inspectors, sidebars, and long\nproperty panels use the matching `panel` / `desktop` surface as appropriate.\nShow the real chrome: trigger or anchor when it matters, title/header row,\ntop-right actions, separators, fields, options, selected states, body content,\nand footer actions that are visible in the workflow.\n\n**Modify, don't redesign.** When the task changes an existing screen, reproduce\nthe current screen's real layout and footprint FIRST, then change only the delta\nand call it out with a single annotation. Do not restack the page into a new\nlayout. For net-new surfaces, compose from the real app shell.\n\n**Classify mockup scope before implementation.** Before turning a plan mockup\ninto source code, decide whether each artboard represents the whole page/app\nshell, a route body inside an existing shell, or a component/sub-surface. If an\nartboard includes navigation, sidebars, auth banners, or a signup/login form,\nmap those pieces to the real shared shell/auth components instead of nesting the\nentire mockup inside the current page. When a mockup references the product's\nstandard signup/login page, find and reuse that existing implementation; do not\napproximate it from the wireframe.\n\n**Zoom in on sub-surfaces, don't redraw the page.** For a small sub-surface (a\npopover, menu, dialog, toast), show the full screen once, then add a small\nseparate artboard whose `html` contains ONLY that sub-surface \u2014 do not re-draw\nthe whole page around it, and do not scale a duplicate up. Pick the matching\n`surface` (e.g. `popover`) so the footprint is right; never widen a popover to\npage width.\n\n**Loading / skeleton states.** Set `data.skeleton: true` on the wireframe and\nfill the `html` with neutral, textless placeholder geometry \u2014 boxes and bars\nbuilt as `<div>`s with `background:var(--wf-line)` and explicit heights/widths,\nno labels or copy. The renderer drops borders, sketch, and color into the\nskeleton register automatically. Never escape to a `custom-html` document block\nto fake a loader.\n\n**Editing an existing mockup.** To change one element, text, or color in an\nexisting html mockup, do NOT regenerate the frame \u2014 call `update-visual-plan`\nwith `contentPatches: [{ op: \"patch-wireframe-html\", blockId, edits: [{ find,\nreplace }] }]`. Each `find` is a unique snippet of the current html (read it\nfirst with `get-visual-plan`); set `all: true` on an edit to replace every\noccurrence. The result is re-sanitized.\n\n**Treat the wireframe border as part of the visible design.** Always wrap HTML\nwireframe content in a root container with real inner padding before drawing\ncards, fields, pills, labels, or controls. Use at least 14-16px of padding,\n`box-sizing: border-box`, `height: 100%`, and `gap` between child rows so the\nfirst row never sits flush against the screen border. Keep text away from\nborders: every container, field, button, menu item, and annotation needs enough\npadding and line-height to read cleanly in the rendered Plan view.\n\n**Lay out children safely so they never collide.** Use HTML flex/grid with\n`gap`, `min-width: 0`, and sensible overflow. Avoid negative margins, absolute\npositioning, or fixed child widths that can collide when the renderer switches\nbetween light/dark, sketch/clean, or different zoom levels.\n\n**Do not wrap intentionally single-line labels.** For tab rails, breadcrumbs,\nfile chips, code filenames, and other deliberately single-line labels, do not\nlet long text wrap. It is acceptable and usually preferable to use\n`white-space: nowrap`, `overflow: hidden`, and `text-overflow: ellipsis` (or\nabstract bars) so the wireframe demonstrates the actual layout behavior instead\nof producing ugly vertical text. Use horizontally scrollable or clipped rails\nfor overflow.\n\n**Fill the frame; keep labels short.** Each artboard is a fixed-size surface \u2014 compose enough realistic HTML to fill it top to bottom with even vertical rhythm; never leave a large empty band. On desktop/app-shell sidebars, let the nav stack flex to fill (`flex:1`) and add any persistent bottom action/status after it so the rail reads complete in taller frames. On mobile especially, flow real rows down the whole screen (status bar, header, then list/detail content) rather than a header floating above a gap. Keep every label short enough to sit on one line within its column \u2014 shorten the copy rather than relying on the frame to absorb it (long labels wrap or clip).\n\n**Before / after must be comparable.** When showing a state change, preserve the\nunchanged controls in both states so the reviewer can see exactly what moved or\nappeared; do not show an added control as a generic box floating elsewhere in\nthe surface. Place the new/changed affordance where the implementation puts it \u2014\nfor example, a new `Edit with AI` action in a popover header belongs in the\ntop-right header slot, aligned with the title, not in the body or footer. Use\nthe same frame size, scale, outer padding, border radius, and visual density on\nboth sides unless the change itself alters those properties, and let the frame\nheight fit the content rather than leaving a tall empty lower half.\n\n**Name the states with the column header, never inside the frame.** Put the two\nstates in a `columns` block and set each column's `label` to `Before` and\n`After` \u2014 the renderer draws that label as an `h4` heading above each frame. Do\nNOT bake a `Before`/`After` pill, title, or heading into the wireframe `html`: a\nlabel placed inside reads as part of the product UI, lands in a random corner,\nand clutters the comparison. The column header is the one and only place the\nstate name belongs.\n\n**Let the surface choose side-by-side vs. stacked.** The `columns` renderer lays\nnarrow surfaces (`mobile`, `popover`, `panel`) out side by side, and\nautomatically stacks wide surfaces (`desktop`, `browser`) vertically at full\ndocument width so a large frame is never crushed into a half-width column and\ncropped. Author both wireframes with the real `surface` and the matching\n`Before`/`After` column labels; do not hand-stack the pair into separate\ntop-level wireframes or duplicate the state name as body content.\n\n**Good example \u2014 a contacts list, surface `browser`.** A small, real screen\ncomposed from the helper classes and tokens, layout in inline flex, no fonts or\nhex colors:\n\n```html\n<div\n  style=\"display:flex;flex-direction:column;gap:12px;padding:16px;height:100%\"\n>\n  <div style=\"display:flex;align-items:center;justify-content:space-between\">\n    <h1>Contacts</h1>\n    <button class=\"primary\">New contact</button>\n  </div>\n  <div style=\"display:flex;gap:6px\">\n    <span class=\"wf-pill accent\">All 128</span>\n    <span class=\"wf-pill\">Favorites</span>\n    <span class=\"wf-pill\">Archived</span>\n  </div>\n  <div\n    class=\"wf-card\"\n    style=\"display:flex;flex-direction:column;gap:0;padding:0\"\n  >\n    <div\n      style=\"display:flex;align-items:center;gap:10px;padding:10px 12px;border-bottom:1.4px solid var(--wf-line)\"\n    >\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Jane Cooper</strong><br /><small>jane@acme.co</small>\n      </div>\n      <span class=\"wf-pill\">Lead</span>\n    </div>\n    <div style=\"display:flex;align-items:center;gap:10px;padding:10px 12px\">\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Marcus Lee</strong><br /><small>marcus@globex.io</small>\n      </div>\n      <span class=\"wf-pill\">Customer</span>\n    </div>\n  </div>\n</div>\n```\n\n<!-- SHARED-CORE:wireframe-quality END -->\n\n<!-- SHARED-CORE:canvas-surface START -->\n\n**Artboard placement is locked by the `surface`, not by coordinates.** The\nsurface locks the footprint and aspect; never set artboard width/height and\nnever use coordinates inside the wireframe HTML. Let canvas auto-placement\nhandle simple one-row boards. For mixed-footprint canvases, board-level artboard\n`x`/`y` is allowed and expected when it creates clear lanes.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters. Connect\nonly neighboring steps; never draw a long connector that skips across unrelated\nframes. Before handoff, inspect the top canvas at default zoom and move any\nframe whose label, connector, or annotation crosses another frame.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle Figma-style notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams are\ndifferent: keep them inline in the document, close to the recommendation they\nsupport, unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it, but new\nplans emit `html`. Do not author fresh kit-tree screens - write the HTML mockup\ninstead. Likewise, old or imported plans may carry coordinate-based regions or\nfree-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The `surface` drives each artboard's aspect\nand footprint, and the gutter parks notes by `targetId` + `placement`. The only\nnew-plan coordinate exception is deliberate board-level artboard `x`/`y` for\nmulti-lane mixed-surface canvases; never supply artboard width/height, note\ncoordinates, or wireframe-internal coordinates.\n\n<!-- SHARED-CORE:canvas-surface END -->\n\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan` and `/ui-plan`. It is\nthe single source of truth for the document below the canvas. Do not paraphrase\nit per command.\n\n<!-- SHARED-CORE:document-quality START -->\n\n**The document is a serious technical plan, not marketing.** Write it the way a\nstrong Claude or Codex implementation plan reads: outcome-first, prose-first,\nself-contained, and specific. State the objective and what \"done\" means, the\nscope and non-goals, the proposed approach with the key decisions and their\nrationale, ordered steps that name real files, symbols, actions, and data\nshapes, the risks, and a closing verification step (tests, build, or a checkable\nbehavior). Replace vague prose with specifics; never ship a step like \"make it\nwork.\" No hero art, gradients, logos, nav bars, slogans, value props, giant\nlanding-page headings, or marketing cards unless the user explicitly asks.\n\n**When top visuals exist, they and the document never duplicate each other.**\nFor UI work, the UI story lives in the top visual surface: canvas artboards for\nstatic inspection, plus prototype tabs when the flow should be functional. The\ndocument carries the technical depth the visuals cannot show \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation should\ncarry its own nearby inline `diagram` / `data-model` block plus file evidence\nand terse Problem/Solution/Why text. For architecture/code diagrams, prefer\nstandard two-dimensional layouts: paired before/after panels, layered diagrams,\nswimlanes, dependency maps, matrices, or grouped regions. Do not default to\nleft-to-right chains; use a line only when the relationship is truly a sequence.\nUse native `diagram` blocks with `data.html` / `data.css` for these richer\nlayouts; the fragment may use semantic HTML and inline SVG, and the renderer\napplies the viewer's sketch/clean style. Leave room for the sketch font: keep\nlabels short, give nodes generous width, and place boundary/annotation labels in\nunused space instead of over nodes. For small text/SVG changes to an existing\nHTML diagram, use `patch-diagram-html` with a unique `find`/`replace` snippet\ninstead of resending the whole `data.html` string. Legacy `nodes` / `edges` are\nonly for tiny previews or genuinely linear step flows. Repeat a wireframe in the document only\nfor a genuinely new detail view or comparison. Skip the visual surface entirely\nfor non-visual work and write a clean rich document. For a simple binary UI\nvisual choice, show the two directions in the canvas only; do not repeat the\nsame options as body wireframes, a `decision` block, or prose. Put the actual\nchoice in the bottom \"Open Questions\" form.\n\n**Use the right block, and make it carry substance.** For the authoritative,\nmachine-checked list of block types and their data schemas, call `get-plan-blocks`\n\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- `decision` ONLY for a genuinely-open either/or the reviewer must still pick\n  between \u2014 two or three option cards with real consequences. If you have already\n  committed to an approach, state it as settled prose or a `callout`, NOT a\n  `decision` block; a decision card for a question you have already answered just\n  reads as a confusing mid-document form. Never duplicate the same choice across a\n  `decision` block and the bottom Open Questions `question-form` \u2014 pick one home\n  for it. These are static records; do not style them like clickable tabs or chips\n  unless the renderer truly supports changing the selection.\n- `columns` for side-by-side before/after or current/target comparisons where\n  each side needs real nested blocks; label the columns clearly and avoid\n  stacking comparison blocks vertically when parallel reading is the point.\n- `diagram` for two-dimensional architecture, dependency, data-flow, or state\n  relationships, only when it clarifies something real. For architecture/code\n  diagrams, prefer `data.html` / `data.css` with semantic HTML and inline SVG so\n  the diagram can use panels, layers, matrices, arrows, annotations, and\n  responsive layout directly. Author diagram HTML with renderer-owned primitives\n  like `.diagram-panel`, `.diagram-card`, `.diagram-node`, `.diagram-box`,\n  `.diagram-pill`, `.diagram-muted`, and `[data-rough]`; they map to the plan's\n  Tailwind theme variables through `--wf-ink`, `--wf-muted`, `--wf-line`,\n  `--wf-paper`, `--wf-card`, `--wf-accent`, `--wf-accent-soft`, `--wf-warn`, and\n  `--wf-ok`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not\n  set `font-family` and do not hard-code hex, rgb, or hsl colors in diagram HTML\n  or CSS. Use legacy `nodes` / `edges` only for small previews or truly\n  sequential flows. In architecture/code plans, prefer a repeated section rhythm:\n  recommendation title, confidence and category badges, code-path evidence, a\n  local before/after or current/target spatial diagram, then concise\n  Problem/Solution/Why text. Labels must not overlap nodes, connectors, or each\n  other.\n- `tabs` for multiple states, directions, or comparisons. A tab that reveals\n  only prose usually means the plan is under-specified \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question in both a `decision` block and a\n`question-form`.\n\n**`custom-html` is a bounded escape hatch only** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\n\n**Before handoff, open the plan and check it.** Fix overlap, excessive\nwhitespace, clipped fragments, misleading inactive controls, poor contrast, and\nunreadable diagrams before asking for approval.\n\n<!-- SHARED-CORE:document-quality END -->\n\n## Good vs. Bad Exemplar\n\n<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard whose\n`data.html` is a real flex layout \u2014 a sidebar of links (`Inbox 12`, `Today 4`,\n`Done`), a main column with an `<h1>Today</h1>`, accent `.wf-pill`s for the\nfilters, a muted section label `OVERDUE`, and `.wf-card` task rows carrying real\ntitles, due dates, and a primary `button.primary` \u2014 styled only through bare\nelements, helper classes, and `--wf-*` tokens, so the renderer applies the\ncorrect desktop footprint, theme, and one subtle whole-frame wobble. Plain-text\ndesigner notes sit spaced off the frame, pointing only at the controls that need\nexplanation. Below it, a Claude/Codex-grade document: objective and\ndone-criteria, a few `code` blocks (grouped in a vertical `tabs` block when\nmore than one) showing the real shape of the load-bearing files, a `decision`\ncard weighing two real approaches,\nand a validation step \u2014 none of it repeating the canvas. If the task also\nchanges a multi-step completion flow, the same top area includes a Prototype tab\nwhose screens use the same labels and states as the canvas artboards, with\n`data-goto` controls for the sequence. This is the bar.\n\n**GOOD.** A `/visual-plan` for a backend architecture review: no top canvas.\nThe document opens with context and a legend, then repeats recommendation cards:\ntitle, confidence/category badges, a monospace grid of real file paths, one\ninline two-dimensional before/after or layered architecture diagram, and terse\nProblem/Solution/Why bullets using the codebase's vocabulary. The diagram uses\nspace to show boundaries, layers, and ownership; it is not a default\nleft-to-right chain. The plan ends with a top recommendation and a bottom\nquestion-form only if the next architecture direction is genuinely open. This is\nbetter than a top canvas because each diagram is local to the claim it supports.\n\n**BAD.** A `data.html` with hard-coded hex colors, a `font-family`, or fixed\npixel width/height; gray placeholder bars \"insinuating\" text on a non-skeleton\nframe; a forced desktop + mobile pair for a popover; floating bordered\nannotation cards hugging the frames; a fresh hand-authored kit-tree `screen`\ninstead of `html`; a multi-step UI flow with only static frames and no prototype\ntab; a mockup escaped into a document `custom-html` block; and a marketing-style\ndocument with a hero heading and value props that just restates what the canvas\nalready shows. Also bad: an architecture-only plan forced into a top canvas of\nlabeled boxes with overlapping text, where the actual code evidence and\nrecommendations live elsewhere. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-ui-plan`: create the UI-first structured visual plan.\n- `create-prototype-plan`: create a prototype-first plan when UI review needs a\n  functional live prototype.\n- `create-plan-design`: create a full-fidelity branded design plan when polish,\n  brand, and detailed visual direction are primary review inputs.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only for the explicit `/visual-questions`\n  command, not as `/ui-plan` preflight.\n- `update-visual-plan`: revise content, mockups, comments, or handoff notes;\n  prefer targeted `contentPatches`.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: inspect the current structured plan, exported HTML, and\n  annotations; it also returns the MDX folder for source workflows.\n- `get-plan-feedback`: read unconsumed reviewer comments before coding; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and\nauthenticates it in the same step (a one-time browser sign-in at setup \u2014 this is\nintended), so the first tool call does not hit an OAuth wall:\n\n```bash\nagent-native skills add visual-plan\n```\n\nAfter that, `/visual-plan` (and `/visual-recap`, `/ui-plan`,\n`/prototype-plan`, `/plan-design`, `/visual-questions`) generate a plan and open\nthe editor. Pass `--no-connect` to\nregister the connector without authenticating, then run\n`agent-native connect https://plan.agent-native.com` whenever you are ready.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`,\ndo not keep retrying the tool. Authenticate the connector with\n`agent-native connect https://plan.agent-native.com` (OAuth-capable hosts can\ninstead re-run /mcp and choose Authenticate), then continue once the connector\nis available.\n\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do\nnot put shared secrets in skill files.\n";
+export declare const VISUAL_PLANS_SKILL_MD = "---\nname: visual-plan\ndescription: >-\n  Use Agent-Native Plans when coding-agent work needs an interactive structured\n  plan document with inline diagrams, implementation maps, optional UI/product\n  wireframes or prototypes, annotations, and comments.\nmetadata:\n  visibility: exported\n---\n\n# Agent-Native Plans\n\nAgent-Native Plans is structured visual planning mode for coding agents. Build\nthe plan you would normally write in Markdown, but as a scannable document with\neditable blocks mixed in: inline diagrams, code snippets,\nopen questions, and an optional top visual review area (wireframe canvas, live\nprototype, or both in tabs). Architecture, backend, data, and refactor plans\nusually start in the document with local diagrams near each claim. UI and product\nplans should still start with the top canvas/prototype when screens or behavior\nare what the user needs to review.\n\n`/visual-plan` is the canonical command and the main entry point. Use `/ui-plan`\nwhen the work is primarily product UI and review should start with the screens.\nUse `/prototype-plan` when review should start with a functional live prototype.\nUse `/plan-design` when review should start with full-fidelity branded design.\nUse `/visual-questions` only when the user explicitly wants a visual intake form\nbefore planning. When a Codex, Claude Code, Markdown, or pasted plan already\nexists, `/visual-plan` uses that source plan as the starting point and builds\nthe review surface from it instead of starting over.\n\n## When To Use\n\nCreate or adapt a visual plan when work is multi-file, ambiguous, long-running,\nrisky, or UI-heavy, when architecture / data flow / UI direction / options /\nopen questions would benefit from inline diagrams or structured blocks, when the\nuser needs to react to a direction before you implement, or when an existing text\nplan needs a richer review surface.\n\n## Plan Discipline\n\n- **Gate hard.** A polished visual plan is the most expensive plan form; only\n  invest when a wrong direction is costly. Skip it for trivial, unambiguous work\n  \u2014 typos, one-line fixes, a single well-specified function, anything whose diff\n  you could describe in one sentence \u2014 and just make the change. Never pad a plan\n  with filler and never ship a single-step plan.\n- **Research before you draft.** Read the real files, actions, schema, and\n  patterns first; name actual files, symbols, and data shapes instead of\n  inventing them. Check existing `actions/` before proposing endpoints and prefer\n  named client helpers over raw fetch. Delegate wide exploration to a sub-agent.\n  Lead with reuse: for each step, name what it reuses \u2014 existing actions, schema,\n  components, helpers \u2014 before what it adds, so the plan explains the genuinely new\n  delta instead of redescribing what already exists.\n- **Decide the hard-to-reverse bets first.** For non-trivial backend, data, or API\n  work, sketch where the feature is headed, then call out the decisions that are\n  expensive to undo once data or callers depend on them \u2014 wire format, public ids,\n  data-model shape, auth and ownership boundaries \u2014 and get those right in the plan\n  even if most of the feature ships later. Then scope to the smallest first cut that\n  proves the approach without foreclosing it, stating both what is in and what is\n  explicitly deferred.\n- **Preserve existing plans.** If the user pasted, referenced, or already has a\n  Codex / Claude Code / Markdown plan, treat it as source material. Preserve its\n  intent, do not invent codebase facts, label inferred visuals as inferred, and\n  build the visual review structure around the plan the user already has.\n- **Planning is read-only.** Make no source edits while building or reviewing the\n  plan. Start editing only after the user approves the direction.\n- **Clarify vs. assume.** Do not ask how to build it \u2014 explore and present the\n  approach and options in the plan. Ask a clarifying question only when an\n  ambiguity would change the design and you cannot resolve it from the code; use\n  the host agent's normal ask-user-question flow and batch 2-4 high-leverage\n  questions before finalizing. Do not call `create-visual-questions` from\n  `/visual-plan`; keep any answerable follow-up inside the plan itself as a\n  bottom `question-form` Open Questions block. Otherwise state the assumption\n  explicitly and proceed, and put anything unresolved in an open-questions block.\n- **The plan is the approval gate.** After surfacing it, ask the user to review\n  and approve before you write code, and name which files/areas the work touches.\n  Presenting the plan and requesting sign-off is the approval step \u2014 do not ask a\n  separate \"does this look good?\" question.\n- **The document is the source of truth, not the chat.** When scope shifts,\n  update the plan with `update-visual-plan` rather than only changing course in\n  chat, and re-read the approved plan before major steps.\n\n## Core Workflow\n\n1. Follow the host agent's normal planning flow: inspect the codebase, delegate\n   wide exploration when useful, gather the info needed, and ask native\n   clarifying questions as needed before generating the plan. If a source plan\n   already exists, gather its exact text from the user's paste, a referenced\n   file, or recent visible agent context; do not invent source text.\n2. Decide whether the plan needs a top visual surface with the rules below, then call\n   `create-visual-plan` with the title, brief, source, repo path, and structured\n   `content` blocks. When a source plan already exists, pass it as `planText`\n   and preserve the original plan's intent while adding structured review\n   content.\n3. Compose or enrich any top UI/product visual surface from the kit and write the\n   document with native blocks (see the cores below). Keep the document close to\n   the Markdown plan the agent would normally output, or to the existing plan\n   when one was provided. For architecture, backend, refactor, API, data-model,\n   migration, or code plans, usually omit `content.canvas` and\n   `content.prototype`; put `diagram`, `mermaid`, `api-endpoint`,\n   `openapi-spec`, `data-model`, `diff`, `file-tree`, `json-explorer`,\n   `code` and `annotated-code` blocks directly next\n   to the relevant prose. Skip the top visual surface for non-visual work.\n4. Surface the returned Plans link or inline MCP App and ask the user to review.\n   Always include the actual URL in chat so the next step is a click in CLI or\n   other text-only hosts. When the host exposes an embedded browser/preview panel\n   and a tool can open arbitrary URLs there, open the returned plan URL\n   automatically for convenient review; do not rely on this as the only handoff.\n   Treat that browser open as a convenience and smoke test, not as the access\n   model. Plans should load out of the box for the local agent and local browser\n   session; if a signed-in embedded browser cannot read a local plan that an\n   anonymous/tool check can read, fix the app/action ownership or access path\n   rather than patching one plan by hand. For high-stakes plans (architecture,\n   backend, data, multi-file, or risky), also kick off the self-review pass in\n   **Self-Review Before Handoff** while the user reads, instead of blocking the\n   handoff on it.\n5. Call `get-plan-feedback` before editing, after review, after any long pause,\n   and before the final response. Treat `anchorDetails`, resolver intent, recent\n   review events, and any focused screenshots from browser handoff as the source\n   of truth for exactly what changed and exactly what each comment points at.\n6. Apply changes with `update-visual-plan`, preferring targeted `contentPatches`.\n   When the user wants source-control friendly edits, use\n   `patch-visual-plan-source` against the MDX files instead of regenerating the\n   plan.\n7. Export with `export-visual-plan` only when the user wants a shareable receipt\n   or repo-check-in artifacts.\n\n## Self-Review Before Handoff\n\nFor high-stakes plans \u2014 architecture, backend, data-model, migration, multi-file,\nor otherwise risky work \u2014 run one adversarial self-review pass before treating the\nplan as final. Skip it for small, UI-only, or single-decision plans where the cost\noutweighs the value. Keep the pass cheap and non-blocking:\n\n- **Surface the plan first, review concurrently.** Post the link and let the user\n  start reading, then run the review in parallel \u2014 never make the user wait on it.\n- **Review the written plan; do not re-research.** Critique the plan text and its\n  own blocks. The grounding was already done while drafting, so the review checks\n  the output instead of re-exploring the repo.\n- **Spawn one skeptical reviewer** whose only job is to find what is weak, missing,\n  or wrong \u2014 not to praise. Point it at: hard-to-reverse decisions made implicitly\n  or not at all (wire format, public ids, data-model shape, auth, ownership); steps\n  not anchored in real files or symbols; a menu of options where the plan should\n  commit to one; obvious missing decisions (\"what happens when X?\", \"why not Y?\");\n  and padding or single-step filler.\n- **Fix vs. ask.** Apply clear-cut fixes yourself with `update-visual-plan`\n  `contentPatches` \u2014 vague non-goals, unanchored claims, an obvious missing\n  decision. Route genuine judgment calls back to the user instead: add them to the\n  bottom `question-form` Open Questions block or batch them into the normal\n  ask-user-question flow. Do not silently decide them.\n- **Do not surprise the user mid-read.** On a large plan, apply the patches before\n  the editor loads; otherwise note briefly that a self-review is running so the\n  plan changing under them is expected. When you next respond, summarize what the\n  review changed and what it surfaced for the user to decide.\n\n## Visual Surface Choice\n\nChoose the surface before creating the plan or after reading the source plan. Do\nnot add visual chrome by default:\n\n- **No visual surface** for architecture-only, backend-only, data migration,\n  copy-only, or otherwise non-visual plans. Do not use the top canvas for\n  architecture diagrams, dependency maps, file plans, API contracts, or\n  data-flow-only reviews. Use a strong document with local inline diagrams\n  only when relationships need a visual explanation, usually one spatial diagram\n  per recommendation or decision. Prefer grouped regions, layers, quadrants,\n  matrices, or before/after panels over a single-axis chain unless the\n  relationship is truly sequential.\n- **Canvas only** for one static screen, a before/after comparison, a component\n  state, a small popover, or a visual direction that does not require clicking.\n  Put those wireframes in `content.canvas` and omit `content.prototype`.\n- **Canvas + prototype** for multi-step UI flows, onboarding, wizards,\n  review/approval flows, navigation changes, or anything where the reviewer\n  needs to operate the behavior. Keep the static wireframes in\n  `content.canvas`, add the aligned functional prototype in\n  `content.prototype`, and rely on the top visual tabs to switch between them.\n- **Prototype-first** when the user explicitly asks for `/prototype-plan`, asks\n  to operate the UI, or when interaction is the main question. Use\n  `create-prototype-plan`, which still preserves static mocks where useful.\n\nFor mixed canvas + prototype plans, reuse the same real labels, app statuses,\nand screen ids across both surfaces. The canvas is the inspectable static reference;\nthe prototype is the interactive version of that same flow, not a separate\ndesign direction.\n\n## Wireframe & Canvas Core\n\nThis section is shared by `/visual-plan` and `/ui-plan`, and is the single\nsource of truth for how wireframes and the canvas work. The wireframe-quality\nrules below are additionally shared, word for word, with `/visual-recap`; the\ncanvas/artboard mechanics apply only to `/visual-plan` and `/ui-plan`. Do not\nparaphrase any of it per command.\n\n<!-- SHARED-CORE:wireframe-quality START -->\n\n**A wireframe is an HTML mockup. The renderer owns the look; you write the\ncontent.** Set `data.html` to a self-contained, semantic HTML fragment of the\nscreen and set `data.surface`. The renderer owns the surface footprint/aspect,\nthe dark/light theme, the hand-drawn font, and the rough.js sketch overlay \u2014 you\nnever write `<html>`/`<body>`/`<script>`/`<style>` tags, font-family, hex colors,\nor any width/height/coordinates. You write real HTML layout and real product\ncontent; the renderer styles and roughens it.\n\n**A wireframe block's data is an HTML screen plus a surface:**\n\n```json\n{\n  \"surface\": \"browser\",\n  \"html\": \"<div style=\\\"display:flex;flex-direction:column;gap:10px;padding:16px;height:100%\\\"><h1>Sign in</h1><p class=\\\"wf-muted\\\">Use your work email to continue.</p><div class=\\\"wf-card\\\" style=\\\"display:flex;flex-direction:column;gap:10px\\\"><label>Email<input value=\\\"jane@acme.co\\\" /></label><label>Password<input value=\\\"\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\\\" /></label><label style=\\\"display:flex;align-items:center;gap:8px\\\"><input type=\\\"checkbox\\\" checked /> Remember me</label><button class=\\\"primary\\\">Sign in</button></div><a href=\\\"#\\\">Forgot password?</a></div>\"\n}\n```\n\n**Write PLAIN semantic HTML and let the renderer style it.** Bare elements\n(`h1`/`h2`/`h3`, `p`, `button`, `input`, `<input type=\"checkbox\">`, `a`, `hr`)\nare auto-themed \u2014 no classes needed. Helper classes carry the rest:\n\n- `.wf-card` / `.wf-box` \u2014 a bordered, padded container (a panel, a list item).\n- `.wf-pill` / `.wf-chip` \u2014 a rounded tag or filter; add `.accent`\n  (`<span class=\"wf-pill accent\">`) for the accent-filled variant.\n- `.wf-muted` \u2014 secondary/muted text (or use `<small>`).\n- `button.primary` or any element with `[data-primary]` \u2014 the accent-filled\n  primary button.\n\n**Use the `--wf-*` tokens for any custom color, never hex.** The renderer flips\nthese on light/dark, so reading them is what keeps a mockup correct in both\nthemes. For any inline border, background, or text color, reference a token:\n`style=\"border:1.4px solid var(--wf-line)\"`. The tokens are `--wf-ink` (text),\n`--wf-muted` (secondary text), `--wf-line` (borders/dividers), `--wf-paper`\n(page background), `--wf-card` (raised surface), `--wf-accent` /\n`--wf-accent-fg` / `--wf-accent-soft` (brand action), `--wf-warn`, `--wf-ok`,\nand `--wf-radius`. Never hard-code a hex color and never set `font-family` \u2014 the\nrenderer owns the sketch/clean font.\n\n**Lay out with inline `style` flex/grid.** You write the real layout \u2014\n`display:flex; flex-direction:column; gap:10px; padding:16px` and so on \u2014 and the\nrenderer never repositions anything. Compose the actual product: reproduce the\ncurrent screen, then show the modification. Real labels, real counts, real dates,\nreal button text grounded in the screen you read; not lorem or gray bars.\n\n**Surface presets \u2014 match the real footprint, never default to desktop+mobile.**\nPick the `surface` that matches what the user will actually see:\n\n- `browser`: a web page that needs a browser chrome frame around it.\n- `desktop`: a full desktop app page or app shell.\n- `mobile`: a phone screen, only when the work is genuinely mobile.\n- `popover`: a small floating menu, dropdown, or inline popover.\n- `panel`: a side panel, inspector, or sidebar widget.\n\nA sidebar popover renders as a small surface, not a desktop page and a phone\nframe. Do not emit `desktop` + `mobile` variants unless responsive behavior\nactually changes the layout. For a component or widget, show one broader\napp-context frame only when placement affects understanding, then the focused\ncomponent states.\n\n**Model the actual component shell for small surfaces.** A rendered UI change\nbelongs in a wireframe; reserve `diagram` for architecture, dependency, state,\nor data-flow relationships. Popovers, dropdown menus, command palettes, and\ncontext menus use `surface: \"popover\"` unless the surrounding page placement is\nthe point of the change. Dialogs, sheets, inspectors, sidebars, and long\nproperty panels use the matching `panel` / `desktop` surface as appropriate.\nShow the real chrome: trigger or anchor when it matters, title/header row,\ntop-right actions, separators, fields, options, selected states, body content,\nand footer actions that are visible in the workflow.\n\n**Modify, don't redesign.** When the task changes an existing screen, reproduce\nthe current screen's real layout and footprint FIRST, then change only the delta\nand call it out with a single annotation. Do not restack the page into a new\nlayout. For net-new surfaces, compose from the real app shell.\n\n**Classify mockup scope before implementation.** Before turning a plan mockup\ninto source code, decide whether each artboard represents the whole page/app\nshell, a route body inside an existing shell, or a component/sub-surface. If an\nartboard includes navigation, sidebars, auth banners, or a signup/login form,\nmap those pieces to the real shared shell/auth components instead of nesting the\nentire mockup inside the current page. When a mockup references the product's\nstandard signup/login page, find and reuse that existing implementation; do not\napproximate it from the wireframe.\n\n**Zoom in on sub-surfaces, don't redraw the page.** For a small sub-surface (a\npopover, menu, dialog, toast), show the full screen once, then add a small\nseparate artboard whose `html` contains ONLY that sub-surface \u2014 do not re-draw\nthe whole page around it, and do not scale a duplicate up. Pick the matching\n`surface` (e.g. `popover`) so the footprint is right; never widen a popover to\npage width.\n\n**Loading / skeleton states.** Set `data.skeleton: true` on the wireframe and\nfill the `html` with neutral, textless placeholder geometry \u2014 boxes and bars\nbuilt as `<div>`s with `background:var(--wf-line)` and explicit heights/widths,\nno labels or copy. The renderer drops borders, sketch, and color into the\nskeleton register automatically. Never escape to a `custom-html` document block\nto fake a loader.\n\n**Editing an existing mockup.** To change one element, text, or color in an\nexisting html mockup, do NOT regenerate the frame \u2014 call `update-visual-plan`\nwith `contentPatches: [{ op: \"patch-wireframe-html\", blockId, edits: [{ find,\nreplace }] }]`. Each `find` is a unique snippet of the current html (read it\nfirst with `get-visual-plan`); set `all: true` on an edit to replace every\noccurrence. The result is re-sanitized.\n\n**Treat the wireframe border as part of the visible design.** Always wrap HTML\nwireframe content in a root container with real inner padding before drawing\ncards, fields, pills, labels, or controls. Use at least 14-16px of padding,\n`box-sizing: border-box`, `height: 100%`, and `gap` between child rows so the\nfirst row never sits flush against the screen border. Keep text away from\nborders: every container, field, button, menu item, and annotation needs enough\npadding and line-height to read cleanly in the rendered Plan view.\n\n**Lay out children safely so they never collide.** Use HTML flex/grid with\n`gap`, `min-width: 0`, and sensible overflow. Avoid negative margins, absolute\npositioning, or fixed child widths that can collide when the renderer switches\nbetween light/dark, sketch/clean, or different zoom levels.\n\n**Do not wrap intentionally single-line labels.** For tab rails, breadcrumbs,\nfile chips, code filenames, and other deliberately single-line labels, do not\nlet long text wrap. It is acceptable and usually preferable to use\n`white-space: nowrap`, `overflow: hidden`, and `text-overflow: ellipsis` (or\nabstract bars) so the wireframe demonstrates the actual layout behavior instead\nof producing ugly vertical text. Use horizontally scrollable or clipped rails\nfor overflow.\n\n**Fill the frame; keep labels short.** Each artboard is a fixed-size surface \u2014 compose enough realistic HTML to fill it top to bottom with even vertical rhythm; never leave a large empty band. On desktop/app-shell sidebars, let the nav stack flex to fill (`flex:1`) and add any persistent bottom action/status after it so the rail reads complete in taller frames. On mobile especially, flow real rows down the whole screen (status bar, header, then list/detail content) rather than a header floating above a gap. Keep every label short enough to sit on one line within its column \u2014 shorten the copy rather than relying on the frame to absorb it (long labels wrap or clip).\n\n**Before / after must be comparable.** When showing a state change, preserve the\nunchanged controls in both states so the reviewer can see exactly what moved or\nappeared; do not show an added control as a generic box floating elsewhere in\nthe surface. Place the new/changed affordance where the implementation puts it \u2014\nfor example, a new `Edit with AI` action in a popover header belongs in the\ntop-right header slot, aligned with the title, not in the body or footer. Use\nthe same frame size, scale, outer padding, border radius, and visual density on\nboth sides unless the change itself alters those properties, and let the frame\nheight fit the content rather than leaving a tall empty lower half.\n\n**Name the states with the column header, never inside the frame.** Put the two\nstates in a `columns` block and set each column's `label` to `Before` and\n`After` \u2014 the renderer draws that label as an `h4` heading above each frame. Do\nNOT bake a `Before`/`After` pill, title, or heading into the wireframe `html`: a\nlabel placed inside reads as part of the product UI, lands in a random corner,\nand clutters the comparison. The column header is the one and only place the\nstate name belongs.\n\n**Let the surface choose side-by-side vs. stacked.** The `columns` renderer lays\nnarrow surfaces (`mobile`, `popover`, `panel`) out side by side, and\nautomatically stacks wide surfaces (`desktop`, `browser`) vertically at full\ndocument width so a large frame is never crushed into a half-width column and\ncropped. Author both wireframes with the real `surface` and the matching\n`Before`/`After` column labels; do not hand-stack the pair into separate\ntop-level wireframes or duplicate the state name as body content.\n\n**Good example \u2014 a contacts list, surface `browser`.** A small, real screen\ncomposed from the helper classes and tokens, layout in inline flex, no fonts or\nhex colors:\n\n```html\n<div\n  style=\"display:flex;flex-direction:column;gap:12px;padding:16px;height:100%\"\n>\n  <div style=\"display:flex;align-items:center;justify-content:space-between\">\n    <h1>Contacts</h1>\n    <button class=\"primary\">New contact</button>\n  </div>\n  <div style=\"display:flex;gap:6px\">\n    <span class=\"wf-pill accent\">All 128</span>\n    <span class=\"wf-pill\">Favorites</span>\n    <span class=\"wf-pill\">Archived</span>\n  </div>\n  <div\n    class=\"wf-card\"\n    style=\"display:flex;flex-direction:column;gap:0;padding:0\"\n  >\n    <div\n      style=\"display:flex;align-items:center;gap:10px;padding:10px 12px;border-bottom:1.4px solid var(--wf-line)\"\n    >\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Jane Cooper</strong><br /><small>jane@acme.co</small>\n      </div>\n      <span class=\"wf-pill\">Lead</span>\n    </div>\n    <div style=\"display:flex;align-items:center;gap:10px;padding:10px 12px\">\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Marcus Lee</strong><br /><small>marcus@globex.io</small>\n      </div>\n      <span class=\"wf-pill\">Customer</span>\n    </div>\n  </div>\n</div>\n```\n\n<!-- SHARED-CORE:wireframe-quality END -->\n\n<!-- SHARED-CORE:canvas-surface START -->\n\n**Artboard placement is locked by the `surface`, not by coordinates.** The\nsurface locks the footprint and aspect; never set artboard width/height and\nnever use coordinates inside the wireframe HTML. Let canvas auto-placement\nhandle simple one-row boards. For mixed-footprint canvases, board-level artboard\n`x`/`y` is allowed and expected when it creates clear lanes.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters. Connect\nonly neighboring steps; never draw a long connector that skips across unrelated\nframes. Before handoff, inspect the top canvas at default zoom and move any\nframe whose label, connector, or annotation crosses another frame.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle Figma-style notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams are\ndifferent: keep them inline in the document, close to the recommendation they\nsupport, unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it, but new\nplans emit `html`. Do not author fresh kit-tree screens - write the HTML mockup\ninstead. Likewise, old or imported plans may carry coordinate-based regions or\nfree-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The `surface` drives each artboard's aspect\nand footprint, and the gutter parks notes by `targetId` + `placement`. The only\nnew-plan coordinate exception is deliberate board-level artboard `x`/`y` for\nmulti-lane mixed-surface canvases; never supply artboard width/height, note\ncoordinates, or wireframe-internal coordinates.\n\n<!-- SHARED-CORE:canvas-surface END -->\n\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan` and `/ui-plan`. It is\nthe single source of truth for the document below the canvas. Do not paraphrase\nit per command.\n\n<!-- SHARED-CORE:document-quality START -->\n\n**The document is a serious technical plan, not marketing.** Write it the way a\nstrong Claude or Codex implementation plan reads: outcome-first, prose-first,\nself-contained, and specific. State the objective and what \"done\" means, the\nscope and non-goals, the proposed approach with the key decisions and their\nrationale, ordered steps that name real files, symbols, actions, and data\nshapes, the risks, and a closing verification step (tests, build, or a checkable\nbehavior). Replace vague prose with specifics; never ship a step like \"make it\nwork.\" No hero art, gradients, logos, nav bars, slogans, value props, giant\nlanding-page headings, or marketing cards unless the user explicitly asks.\n\n**When top visuals exist, they and the document never duplicate each other.**\nFor UI work, the UI story lives in the top visual surface: canvas artboards for\nstatic inspection, plus prototype tabs when the flow should be functional. The\ndocument carries the technical depth the visuals cannot show \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation should\ncarry its own nearby inline `diagram` / `data-model` block plus file evidence\nand terse Problem/Solution/Why text. For architecture/code diagrams, prefer\nstandard two-dimensional layouts: paired before/after panels, layered diagrams,\nswimlanes, dependency maps, matrices, or grouped regions. Do not default to\nleft-to-right chains; use a line only when the relationship is truly a sequence.\nUse native `diagram` blocks with `data.html` / `data.css` for these richer\nlayouts; the fragment may use semantic HTML and inline SVG, and the renderer\napplies the viewer's sketch/clean style. Leave room for the sketch font: keep\nlabels short, give nodes generous width, and place boundary/annotation labels in\nunused space instead of over nodes. For small text/SVG changes to an existing\nHTML diagram, use `patch-diagram-html` with a unique `find`/`replace` snippet\ninstead of resending the whole `data.html` string. Legacy `nodes` / `edges` are\nonly for tiny previews or genuinely linear step flows. Repeat a wireframe in the document only\nfor a genuinely new detail view or comparison. Skip the visual surface entirely\nfor non-visual work and write a clean rich document. For a simple binary UI\nvisual choice, show the two directions in the canvas only; do not repeat the\nsame options as body wireframes, a `decision` block, or prose. Put the actual\nchoice in the bottom \"Open Questions\" form.\n\n**Use the right block, and make it carry substance.** For the authoritative,\nmachine-checked list of block types and their data schemas, call `get-plan-blocks`\n\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- `decision` ONLY for a genuinely-open either/or the reviewer must still pick\n  between \u2014 two or three option cards with real consequences. If you have already\n  committed to an approach, state it as settled prose or a `callout`, NOT a\n  `decision` block; a decision card for a question you have already answered just\n  reads as a confusing mid-document form. Never duplicate the same choice across a\n  `decision` block and the bottom Open Questions `question-form` \u2014 pick one home\n  for it. These are static records; do not style them like clickable tabs or chips\n  unless the renderer truly supports changing the selection.\n- `columns` for side-by-side before/after or current/target comparisons where\n  each side needs real nested blocks; label the columns clearly and avoid\n  stacking comparison blocks vertically when parallel reading is the point.\n- `diagram` for two-dimensional architecture, dependency, data-flow, or state\n  relationships, only when it clarifies something real. For architecture/code\n  diagrams, prefer `data.html` / `data.css` with semantic HTML and inline SVG so\n  the diagram can use panels, layers, matrices, arrows, annotations, and\n  responsive layout directly. Author diagram HTML with renderer-owned primitives\n  like `.diagram-panel`, `.diagram-card`, `.diagram-node`, `.diagram-box`,\n  `.diagram-pill`, `.diagram-muted`, and `[data-rough]`; they map to the plan's\n  Tailwind theme variables through `--wf-ink`, `--wf-muted`, `--wf-line`,\n  `--wf-paper`, `--wf-card`, `--wf-accent`, `--wf-accent-soft`, `--wf-warn`, and\n  `--wf-ok`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not\n  set `font-family` and do not hard-code hex, rgb, or hsl colors in diagram HTML\n  or CSS. Use legacy `nodes` / `edges` only for small previews or truly\n  sequential flows. In architecture/code plans, prefer a repeated section rhythm:\n  recommendation title, confidence and category badges, code-path evidence, a\n  local before/after or current/target spatial diagram, then concise\n  Problem/Solution/Why text. Labels must not overlap nodes, connectors, or each\n  other.\n- `tabs` for multiple states, directions, or comparisons. A tab that reveals\n  only prose usually means the plan is under-specified \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nThat bottom form is the ONLY place that enumerates the open questions: never add\na second \"Open Questions\" heading, list, or recap of the same questions earlier\nin the document. A one-line pointer in the overview prose (\"a few decisions are\nstill open \u2014 see Open Questions below\") is fine, but do not reproduce the\nquestion list or a parallel questions/decisions section above it.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question in both a `decision` block and a\n`question-form`.\n\n**`custom-html` is a bounded escape hatch only** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\n\n**Before handoff, open the plan and check it.** Fix overlap, excessive\nwhitespace, clipped fragments, misleading inactive controls, poor contrast, and\nunreadable diagrams before asking for approval.\n\n<!-- SHARED-CORE:document-quality END -->\n\n## Good vs. Bad Exemplar\n\n<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard whose\n`data.html` is a real flex layout \u2014 a sidebar of links (`Inbox 12`, `Today 4`,\n`Done`), a main column with an `<h1>Today</h1>`, accent `.wf-pill`s for the\nfilters, a muted section label `OVERDUE`, and `.wf-card` task rows carrying real\ntitles, due dates, and a primary `button.primary` \u2014 styled only through bare\nelements, helper classes, and `--wf-*` tokens, so the renderer applies the\ncorrect desktop footprint, theme, and one subtle whole-frame wobble. Plain-text\ndesigner notes sit spaced off the frame, pointing only at the controls that need\nexplanation. Below it, a Claude/Codex-grade document: objective and\ndone-criteria, a few `code` blocks (grouped in a vertical `tabs` block when\nmore than one) showing the real shape of the load-bearing files, a `decision`\ncard weighing two real approaches,\nand a validation step \u2014 none of it repeating the canvas. If the task also\nchanges a multi-step completion flow, the same top area includes a Prototype tab\nwhose screens use the same labels and states as the canvas artboards, with\n`data-goto` controls for the sequence. This is the bar.\n\n**GOOD.** A `/visual-plan` for a backend architecture review: no top canvas.\nThe document opens with context and a legend, then repeats recommendation cards:\ntitle, confidence/category badges, a monospace grid of real file paths, one\ninline two-dimensional before/after or layered architecture diagram, and terse\nProblem/Solution/Why bullets using the codebase's vocabulary. The diagram uses\nspace to show boundaries, layers, and ownership; it is not a default\nleft-to-right chain. The plan ends with a top recommendation and a bottom\nquestion-form only if the next architecture direction is genuinely open. This is\nbetter than a top canvas because each diagram is local to the claim it supports.\n\n**BAD.** A `data.html` with hard-coded hex colors, a `font-family`, or fixed\npixel width/height; gray placeholder bars \"insinuating\" text on a non-skeleton\nframe; a forced desktop + mobile pair for a popover; floating bordered\nannotation cards hugging the frames; a fresh hand-authored kit-tree `screen`\ninstead of `html`; a multi-step UI flow with only static frames and no prototype\ntab; a mockup escaped into a document `custom-html` block; and a marketing-style\ndocument with a hero heading and value props that just restates what the canvas\nalready shows. Also bad: an architecture-only plan forced into a top canvas of\nlabeled boxes with overlapping text, where the actual code evidence and\nrecommendations live elsewhere. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-visual-plan`: start one structured visual plan per agent task/run, or\n  import an existing text plan by passing `planText`; `content` may include no\n  visual surface, canvas only, or canvas + prototype.\n- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.\n- `create-prototype-plan`: start a prototype-first plan with a functional top\n  review surface.\n- `create-plan-design`: start a full-fidelity branded Design-tab plan with an\n  optional matching Prototype tab.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only for the explicit `/visual-questions`\n  command, not as `/visual-plan` preflight.\n- `update-visual-plan`: revise content, status, or comments; prefer\n  `contentPatches` over regenerating the whole plan.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: read the current structured plan, exported HTML, and\n  annotations; it also returns the MDX folder for source workflows.\n- `get-plan-feedback`: read unconsumed human feedback. Use it frequently; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and\nauthenticates it in the same step (a one-time browser sign-in at setup \u2014 this is\nintended), so the first tool call does not hit an OAuth wall:\n\n```bash\nagent-native skills add visual-plan\n```\n\nAfter that, `/visual-plan` (and `/visual-recap`, `/ui-plan`,\n`/prototype-plan`, `/plan-design`, `/visual-questions`) generate a plan and open\nthe editor. Pass `--no-connect` to\nregister the connector without authenticating, then run\n`agent-native connect https://plan.agent-native.com` whenever you are ready.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`,\ndo not keep retrying the tool. Authenticate the connector with\n`agent-native connect https://plan.agent-native.com` (OAuth-capable hosts can\ninstead re-run /mcp and choose Authenticate), then continue once the connector\nis available.\n\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do\nnot put shared secrets in skill files.\n";
+export declare const UI_PLAN_SKILL_MD = "---\nname: ui-plan\ndescription: >-\n  Use Agent-Native Plans for UI-first planning with an optional top pan/zoom\n  wireframe canvas, a refined Notion-like document, rich tabs, diagrams,\n  comments, drawing, and agent handoff.\nmetadata:\n  visibility: exported\n---\n\n# UI Plan\n\nUse `/ui-plan` when the task is primarily about product UI, user flows,\ninteraction details, component layout, or visual direction. The reviewable UI\ncomes first; implementation detail comes after the user has something concrete to\nreact to.\n\n`/visual-plan` remains the general command for architecture, backend, refactors,\nand mixed work. Use `/prototype-plan` when the UI review needs a functional live\nprototype instead of static screens. Use `/plan-design` when polish, brand, or\nvisual fidelity are material to the decision. Use `/visual-questions` only when\nthe user explicitly wants visual intake before planning. Use `/visual-plan` when\na text plan already exists and should become the source material for the review.\n\n## Plan Discipline\n\n- **Gate hard.** Use a UI plan when the surface is new, ambiguous, spans several\n  screens or states, or the direction needs agreement before coding. Skip it for\n  cosmetic one-liners \u2014 a color, a label, a spacing tweak \u2014 and just make the\n  change. Never ship a single-step or filler plan.\n- **Research before you draft.** Read the real components, routes, and design\n  tokens first; ground every mockup and the file map in actual files and symbols.\n  Delegate wide exploration to a sub-agent when the surface is large.\n- **Planning is read-only.** Make no source edits while building or reviewing.\n  Start editing only after the user approves the UI direction.\n- **Clarify vs. assume.** Do not ask how to build the UI \u2014 present the direction\n  and options as mockups and tabs. Ask a clarifying question only when an\n  ambiguity would change the design; use the host agent's normal\n  ask-user-question flow and batch 2-4 before finalizing. Do not call\n  `create-visual-questions` from `/ui-plan`; keep answerable follow-up inside\n  the same plan as a bottom `question-form` Open Questions block. Otherwise\n  state the assumption in the plan and proceed.\n- **The plan is the approval gate.** Ask the user to review and approve the UI\n  direction before you write code, and name the files/areas the work touches.\n\n## UI-First Workflow\n\n1. Follow the host agent's normal planning flow: inspect the codebase, gather\n   the UI/component context needed, and ask native clarifying questions as needed\n   before generating the plan.\n2. Call `create-ui-plan` with a UI-specific title, brief, source, repo path, and\n   structured `content`. The canvas comes first, the document second.\n3. Compose the top canvas from the kit (see the cores below): the key artboards\n   with real product content, designer notes, and connectors only for real\n   sequences. Skip the canvas when wireframes would not clarify the work.\n4. Continue below as a concise technical document that stays close to the\n   Markdown plan the agent would normally output \u2014 not a second copy of the\n   canvas \u2014 covering concrete files, contracts, phases, risks, and validation.\n5. Call `get-plan-feedback` before implementation, after review, after a long\n   pause, and before the final response. Treat `anchorDetails`, resolver intent,\n   recent review events, and any focused screenshots from browser handoff as the\n   source of truth for exactly what changed and exactly what each UI comment\n   points at. Apply changes with `update-visual-plan`, preferring\n   `contentPatches` for one frame, annotation, node, tab, or block. When the\n   user wants source-control friendly edits, use `patch-visual-plan-source`\n   against the MDX files instead of regenerating the plan.\n\n## Agent Handoff\n\nAfter the canvas and document, add a short handoff that names the chosen UI\ndirection, unresolved visual questions, and feedback that must be read before\ncode changes. Never claim feedback has been applied until `get-plan-feedback` or\nthe user has supplied it.\n\n## Wireframe & Canvas Core\n\nThis section is shared by `/visual-plan` and `/ui-plan`, and is the single\nsource of truth for how wireframes and the canvas work. The wireframe-quality\nrules below are additionally shared, word for word, with `/visual-recap`; the\ncanvas/artboard mechanics apply only to `/visual-plan` and `/ui-plan`. Do not\nparaphrase any of it per command.\n\n<!-- SHARED-CORE:wireframe-quality START -->\n\n**A wireframe is an HTML mockup. The renderer owns the look; you write the\ncontent.** Set `data.html` to a self-contained, semantic HTML fragment of the\nscreen and set `data.surface`. The renderer owns the surface footprint/aspect,\nthe dark/light theme, the hand-drawn font, and the rough.js sketch overlay \u2014 you\nnever write `<html>`/`<body>`/`<script>`/`<style>` tags, font-family, hex colors,\nor any width/height/coordinates. You write real HTML layout and real product\ncontent; the renderer styles and roughens it.\n\n**A wireframe block's data is an HTML screen plus a surface:**\n\n```json\n{\n  \"surface\": \"browser\",\n  \"html\": \"<div style=\\\"display:flex;flex-direction:column;gap:10px;padding:16px;height:100%\\\"><h1>Sign in</h1><p class=\\\"wf-muted\\\">Use your work email to continue.</p><div class=\\\"wf-card\\\" style=\\\"display:flex;flex-direction:column;gap:10px\\\"><label>Email<input value=\\\"jane@acme.co\\\" /></label><label>Password<input value=\\\"\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\\\" /></label><label style=\\\"display:flex;align-items:center;gap:8px\\\"><input type=\\\"checkbox\\\" checked /> Remember me</label><button class=\\\"primary\\\">Sign in</button></div><a href=\\\"#\\\">Forgot password?</a></div>\"\n}\n```\n\n**Write PLAIN semantic HTML and let the renderer style it.** Bare elements\n(`h1`/`h2`/`h3`, `p`, `button`, `input`, `<input type=\"checkbox\">`, `a`, `hr`)\nare auto-themed \u2014 no classes needed. Helper classes carry the rest:\n\n- `.wf-card` / `.wf-box` \u2014 a bordered, padded container (a panel, a list item).\n- `.wf-pill` / `.wf-chip` \u2014 a rounded tag or filter; add `.accent`\n  (`<span class=\"wf-pill accent\">`) for the accent-filled variant.\n- `.wf-muted` \u2014 secondary/muted text (or use `<small>`).\n- `button.primary` or any element with `[data-primary]` \u2014 the accent-filled\n  primary button.\n\n**Use the `--wf-*` tokens for any custom color, never hex.** The renderer flips\nthese on light/dark, so reading them is what keeps a mockup correct in both\nthemes. For any inline border, background, or text color, reference a token:\n`style=\"border:1.4px solid var(--wf-line)\"`. The tokens are `--wf-ink` (text),\n`--wf-muted` (secondary text), `--wf-line` (borders/dividers), `--wf-paper`\n(page background), `--wf-card` (raised surface), `--wf-accent` /\n`--wf-accent-fg` / `--wf-accent-soft` (brand action), `--wf-warn`, `--wf-ok`,\nand `--wf-radius`. Never hard-code a hex color and never set `font-family` \u2014 the\nrenderer owns the sketch/clean font.\n\n**Lay out with inline `style` flex/grid.** You write the real layout \u2014\n`display:flex; flex-direction:column; gap:10px; padding:16px` and so on \u2014 and the\nrenderer never repositions anything. Compose the actual product: reproduce the\ncurrent screen, then show the modification. Real labels, real counts, real dates,\nreal button text grounded in the screen you read; not lorem or gray bars.\n\n**Surface presets \u2014 match the real footprint, never default to desktop+mobile.**\nPick the `surface` that matches what the user will actually see:\n\n- `browser`: a web page that needs a browser chrome frame around it.\n- `desktop`: a full desktop app page or app shell.\n- `mobile`: a phone screen, only when the work is genuinely mobile.\n- `popover`: a small floating menu, dropdown, or inline popover.\n- `panel`: a side panel, inspector, or sidebar widget.\n\nA sidebar popover renders as a small surface, not a desktop page and a phone\nframe. Do not emit `desktop` + `mobile` variants unless responsive behavior\nactually changes the layout. For a component or widget, show one broader\napp-context frame only when placement affects understanding, then the focused\ncomponent states.\n\n**Model the actual component shell for small surfaces.** A rendered UI change\nbelongs in a wireframe; reserve `diagram` for architecture, dependency, state,\nor data-flow relationships. Popovers, dropdown menus, command palettes, and\ncontext menus use `surface: \"popover\"` unless the surrounding page placement is\nthe point of the change. Dialogs, sheets, inspectors, sidebars, and long\nproperty panels use the matching `panel` / `desktop` surface as appropriate.\nShow the real chrome: trigger or anchor when it matters, title/header row,\ntop-right actions, separators, fields, options, selected states, body content,\nand footer actions that are visible in the workflow.\n\n**Modify, don't redesign.** When the task changes an existing screen, reproduce\nthe current screen's real layout and footprint FIRST, then change only the delta\nand call it out with a single annotation. Do not restack the page into a new\nlayout. For net-new surfaces, compose from the real app shell.\n\n**Classify mockup scope before implementation.** Before turning a plan mockup\ninto source code, decide whether each artboard represents the whole page/app\nshell, a route body inside an existing shell, or a component/sub-surface. If an\nartboard includes navigation, sidebars, auth banners, or a signup/login form,\nmap those pieces to the real shared shell/auth components instead of nesting the\nentire mockup inside the current page. When a mockup references the product's\nstandard signup/login page, find and reuse that existing implementation; do not\napproximate it from the wireframe.\n\n**Zoom in on sub-surfaces, don't redraw the page.** For a small sub-surface (a\npopover, menu, dialog, toast), show the full screen once, then add a small\nseparate artboard whose `html` contains ONLY that sub-surface \u2014 do not re-draw\nthe whole page around it, and do not scale a duplicate up. Pick the matching\n`surface` (e.g. `popover`) so the footprint is right; never widen a popover to\npage width.\n\n**Loading / skeleton states.** Set `data.skeleton: true` on the wireframe and\nfill the `html` with neutral, textless placeholder geometry \u2014 boxes and bars\nbuilt as `<div>`s with `background:var(--wf-line)` and explicit heights/widths,\nno labels or copy. The renderer drops borders, sketch, and color into the\nskeleton register automatically. Never escape to a `custom-html` document block\nto fake a loader.\n\n**Editing an existing mockup.** To change one element, text, or color in an\nexisting html mockup, do NOT regenerate the frame \u2014 call `update-visual-plan`\nwith `contentPatches: [{ op: \"patch-wireframe-html\", blockId, edits: [{ find,\nreplace }] }]`. Each `find` is a unique snippet of the current html (read it\nfirst with `get-visual-plan`); set `all: true` on an edit to replace every\noccurrence. The result is re-sanitized.\n\n**Treat the wireframe border as part of the visible design.** Always wrap HTML\nwireframe content in a root container with real inner padding before drawing\ncards, fields, pills, labels, or controls. Use at least 14-16px of padding,\n`box-sizing: border-box`, `height: 100%`, and `gap` between child rows so the\nfirst row never sits flush against the screen border. Keep text away from\nborders: every container, field, button, menu item, and annotation needs enough\npadding and line-height to read cleanly in the rendered Plan view.\n\n**Lay out children safely so they never collide.** Use HTML flex/grid with\n`gap`, `min-width: 0`, and sensible overflow. Avoid negative margins, absolute\npositioning, or fixed child widths that can collide when the renderer switches\nbetween light/dark, sketch/clean, or different zoom levels.\n\n**Do not wrap intentionally single-line labels.** For tab rails, breadcrumbs,\nfile chips, code filenames, and other deliberately single-line labels, do not\nlet long text wrap. It is acceptable and usually preferable to use\n`white-space: nowrap`, `overflow: hidden`, and `text-overflow: ellipsis` (or\nabstract bars) so the wireframe demonstrates the actual layout behavior instead\nof producing ugly vertical text. Use horizontally scrollable or clipped rails\nfor overflow.\n\n**Fill the frame; keep labels short.** Each artboard is a fixed-size surface \u2014 compose enough realistic HTML to fill it top to bottom with even vertical rhythm; never leave a large empty band. On desktop/app-shell sidebars, let the nav stack flex to fill (`flex:1`) and add any persistent bottom action/status after it so the rail reads complete in taller frames. On mobile especially, flow real rows down the whole screen (status bar, header, then list/detail content) rather than a header floating above a gap. Keep every label short enough to sit on one line within its column \u2014 shorten the copy rather than relying on the frame to absorb it (long labels wrap or clip).\n\n**Before / after must be comparable.** When showing a state change, preserve the\nunchanged controls in both states so the reviewer can see exactly what moved or\nappeared; do not show an added control as a generic box floating elsewhere in\nthe surface. Place the new/changed affordance where the implementation puts it \u2014\nfor example, a new `Edit with AI` action in a popover header belongs in the\ntop-right header slot, aligned with the title, not in the body or footer. Use\nthe same frame size, scale, outer padding, border radius, and visual density on\nboth sides unless the change itself alters those properties, and let the frame\nheight fit the content rather than leaving a tall empty lower half.\n\n**Name the states with the column header, never inside the frame.** Put the two\nstates in a `columns` block and set each column's `label` to `Before` and\n`After` \u2014 the renderer draws that label as an `h4` heading above each frame. Do\nNOT bake a `Before`/`After` pill, title, or heading into the wireframe `html`: a\nlabel placed inside reads as part of the product UI, lands in a random corner,\nand clutters the comparison. The column header is the one and only place the\nstate name belongs.\n\n**Let the surface choose side-by-side vs. stacked.** The `columns` renderer lays\nnarrow surfaces (`mobile`, `popover`, `panel`) out side by side, and\nautomatically stacks wide surfaces (`desktop`, `browser`) vertically at full\ndocument width so a large frame is never crushed into a half-width column and\ncropped. Author both wireframes with the real `surface` and the matching\n`Before`/`After` column labels; do not hand-stack the pair into separate\ntop-level wireframes or duplicate the state name as body content.\n\n**Good example \u2014 a contacts list, surface `browser`.** A small, real screen\ncomposed from the helper classes and tokens, layout in inline flex, no fonts or\nhex colors:\n\n```html\n<div\n  style=\"display:flex;flex-direction:column;gap:12px;padding:16px;height:100%\"\n>\n  <div style=\"display:flex;align-items:center;justify-content:space-between\">\n    <h1>Contacts</h1>\n    <button class=\"primary\">New contact</button>\n  </div>\n  <div style=\"display:flex;gap:6px\">\n    <span class=\"wf-pill accent\">All 128</span>\n    <span class=\"wf-pill\">Favorites</span>\n    <span class=\"wf-pill\">Archived</span>\n  </div>\n  <div\n    class=\"wf-card\"\n    style=\"display:flex;flex-direction:column;gap:0;padding:0\"\n  >\n    <div\n      style=\"display:flex;align-items:center;gap:10px;padding:10px 12px;border-bottom:1.4px solid var(--wf-line)\"\n    >\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Jane Cooper</strong><br /><small>jane@acme.co</small>\n      </div>\n      <span class=\"wf-pill\">Lead</span>\n    </div>\n    <div style=\"display:flex;align-items:center;gap:10px;padding:10px 12px\">\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Marcus Lee</strong><br /><small>marcus@globex.io</small>\n      </div>\n      <span class=\"wf-pill\">Customer</span>\n    </div>\n  </div>\n</div>\n```\n\n<!-- SHARED-CORE:wireframe-quality END -->\n\n<!-- SHARED-CORE:canvas-surface START -->\n\n**Artboard placement is locked by the `surface`, not by coordinates.** The\nsurface locks the footprint and aspect; never set artboard width/height and\nnever use coordinates inside the wireframe HTML. Let canvas auto-placement\nhandle simple one-row boards. For mixed-footprint canvases, board-level artboard\n`x`/`y` is allowed and expected when it creates clear lanes.\n\n**Lay out mixed canvases in lanes.** When a canvas contains broad browser /\ndesktop frames plus compact `mobile`, `popover`, or `panel` surfaces, do not put\neverything in one horizontal strip. Use board-level artboard `x`/`y` to reserve\nlanes with generous empty space: main flow on one row, compact surfaces in their\nown column or row, and loading/error states in a lower row. Keep at least 96px\nbetween rendered artboard rectangles plus room for annotation gutters. Connect\nonly neighboring steps; never draw a long connector that skips across unrelated\nframes. Before handoff, inspect the top canvas at default zoom and move any\nframe whose label, connector, or annotation crosses another frame.\n\n**Canvas annotations are designer notes on the artboard.** When a top canvas is\npresent, sprinkle Figma-style notes near the frames they explain: a short\nheading, supporting text, and bullets \u2014 plain text layers, never bordered or\nshadowed cards, and never a box around a frame. The renderer spaces notes away\nfrom frames, so place each note by the frame it describes. Use an arrow only to\npoint at one specific control or transition; for a broad frame-level note, write\ntext beside the frame with no connector. Connectors are for real sequences only \u2014\nnever fake \"Step 1 \u2192 Step 2\" lines between independent states.\n\n**Do not create overlapping annotations.** Anchor each ordinary note to the\nframe it explains with `targetId` + `placement` (top/right/bottom/left), and\nomit `type` or use `type: \"note\"`. The renderer parks notes in a gutter beside\nthe frame and lays them out automatically. Do not use `type: \"callout\"`,\n`type: \"text\"`, `type: \"arrow\"`, x/y, or points for ordinary notes; those are\nfreeform review-markup layers and must be reserved for intentional markup in\nopen canvas space. Reserve arrows for a note that must point at one specific\ncontrol inside a frame; a note that simply sits beside its frame needs no arrow.\n\n**Patching.** Edit one wireframe, canvas annotation, diagram, or block with targeted `contentPatches`\n(for example `patch-wireframe-html`, `patch-diagram-html`, `update-block`,\n`replace-blocks`, `update-canvas-annotation`) rather\nthan regenerating the whole plan. `contentPatches` are part of the public MCP\naction schema, so Claude Code, Codex, Cursor, and other hosts can make surgical\nedits. If an agent is working from exported source files, use\n`read-visual-plan-source` / `patch-visual-plan-source`: `plan.mdx` holds\nfrontmatter plus markdown/document blocks, `canvas.mdx` holds\n`<DesignBoard>/<Section>/<Artboard>/<Screen>/<Annotation>/<Connector>`, and the\npatch action normalizes the MDX back into the same JSON runtime model. JSON is\nthe canonical runtime shape; MDX is the repo-friendly authoring/export surface.\nIn the browser, humans edit `rich-text` prose inline; agents should still use\n`update-rich-text` content patches or source patches for prose, and use\ncomments/structured patches for canvas, artboard, wireframe, and diagram edits.\n\n**Never emit a titled artboard with no interior wireframe content.** Every artboard\nyou place on the canvas must carry an `html` wireframe or reference a wireframe\nblock via `blockId`; when using `blockId`, the referenced `wireframe` /\n`legacy-wireframe` block must remain in the plan. If you remove a duplicate\nwireframe from the document body, first move its `data` inline onto the\ncorresponding `content.canvas.frames[*].wireframe` / `legacyWireframe`. A\nlabel-only frame or a frame pointing at a deleted block renders empty and is\nrejected at parse time. If you only have a title, write it as a section header or\nannotation, not an empty artboard.\n\n**UI mockups belong in the top visual review area.** Static UI/product visuals\nlive on the canvas; multi-step UI flows get both canvas wireframes and a\nprototype. When the user asks for a mockup, UI state, loading state, layout,\nscreen, or visual comparison, make the canvas the primary home for that static\nvisual. When the user asks for a prototype or the plan contains a sequence the\nreviewer must feel, keep the canvas artboards and add `content.prototype` so the\ntop surface shows Wireframes / Prototype tabs. Architecture/code diagrams are\ndifferent: keep them inline in the document, close to the recommendation they\nsupport, unless the user explicitly asks for a spatial board. Document blocks\ncan explain, compare, or map implementation, but they should not host the\nprimary UI mockup or prototype just because `custom-html`, screenshots, or prose\nare easier to produce. If the canvas/prototype surface cannot represent the\nrequested UI fidelity, still keep the closest top-surface representation and\ncall out or extend the needed renderer capability. A skeleton/loading mockup\nalso lives in a canvas artboard \u2014 never move a mockup out of the canvas.\n\n**Legacy kit tree.** Older plans set a `screen` array of `{ el, ...props }` kit\nnodes instead of `html`; the renderer still accepts and displays it, but new\nplans emit `html`. Do not author fresh kit-tree screens - write the HTML mockup\ninstead. Likewise, old or imported plans may carry coordinate-based regions or\nfree-float x/y on notes; those are legacy escape hatches the renderer still\nshows but you must never produce. The `surface` drives each artboard's aspect\nand footprint, and the gutter parks notes by `targetId` + `placement`. The only\nnew-plan coordinate exception is deliberate board-level artboard `x`/`y` for\nmulti-lane mixed-surface canvases; never supply artboard width/height, note\ncoordinates, or wireframe-internal coordinates.\n\n<!-- SHARED-CORE:canvas-surface END -->\n\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan` and `/ui-plan`. It is\nthe single source of truth for the document below the canvas. Do not paraphrase\nit per command.\n\n<!-- SHARED-CORE:document-quality START -->\n\n**The document is a serious technical plan, not marketing.** Write it the way a\nstrong Claude or Codex implementation plan reads: outcome-first, prose-first,\nself-contained, and specific. State the objective and what \"done\" means, the\nscope and non-goals, the proposed approach with the key decisions and their\nrationale, ordered steps that name real files, symbols, actions, and data\nshapes, the risks, and a closing verification step (tests, build, or a checkable\nbehavior). Replace vague prose with specifics; never ship a step like \"make it\nwork.\" No hero art, gradients, logos, nav bars, slogans, value props, giant\nlanding-page headings, or marketing cards unless the user explicitly asks.\n\n**When top visuals exist, they and the document never duplicate each other.**\nFor UI work, the UI story lives in the top visual surface: canvas artboards for\nstatic inspection, plus prototype tabs when the flow should be functional. The\ndocument carries the technical depth the visuals cannot show \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation should\ncarry its own nearby inline `diagram` / `data-model` block plus file evidence\nand terse Problem/Solution/Why text. For architecture/code diagrams, prefer\nstandard two-dimensional layouts: paired before/after panels, layered diagrams,\nswimlanes, dependency maps, matrices, or grouped regions. Do not default to\nleft-to-right chains; use a line only when the relationship is truly a sequence.\nUse native `diagram` blocks with `data.html` / `data.css` for these richer\nlayouts; the fragment may use semantic HTML and inline SVG, and the renderer\napplies the viewer's sketch/clean style. Leave room for the sketch font: keep\nlabels short, give nodes generous width, and place boundary/annotation labels in\nunused space instead of over nodes. For small text/SVG changes to an existing\nHTML diagram, use `patch-diagram-html` with a unique `find`/`replace` snippet\ninstead of resending the whole `data.html` string. Legacy `nodes` / `edges` are\nonly for tiny previews or genuinely linear step flows. Repeat a wireframe in the document only\nfor a genuinely new detail view or comparison. Skip the visual surface entirely\nfor non-visual work and write a clean rich document. For a simple binary UI\nvisual choice, show the two directions in the canvas only; do not repeat the\nsame options as body wireframes, a `decision` block, or prose. Put the actual\nchoice in the bottom \"Open Questions\" form.\n\n**Use the right block, and make it carry substance.** For the authoritative,\nmachine-checked list of block types and their data schemas, call `get-plan-blocks`\n\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- `decision` ONLY for a genuinely-open either/or the reviewer must still pick\n  between \u2014 two or three option cards with real consequences. If you have already\n  committed to an approach, state it as settled prose or a `callout`, NOT a\n  `decision` block; a decision card for a question you have already answered just\n  reads as a confusing mid-document form. Never duplicate the same choice across a\n  `decision` block and the bottom Open Questions `question-form` \u2014 pick one home\n  for it. These are static records; do not style them like clickable tabs or chips\n  unless the renderer truly supports changing the selection.\n- `columns` for side-by-side before/after or current/target comparisons where\n  each side needs real nested blocks; label the columns clearly and avoid\n  stacking comparison blocks vertically when parallel reading is the point.\n- `diagram` for two-dimensional architecture, dependency, data-flow, or state\n  relationships, only when it clarifies something real. For architecture/code\n  diagrams, prefer `data.html` / `data.css` with semantic HTML and inline SVG so\n  the diagram can use panels, layers, matrices, arrows, annotations, and\n  responsive layout directly. Author diagram HTML with renderer-owned primitives\n  like `.diagram-panel`, `.diagram-card`, `.diagram-node`, `.diagram-box`,\n  `.diagram-pill`, `.diagram-muted`, and `[data-rough]`; they map to the plan's\n  Tailwind theme variables through `--wf-ink`, `--wf-muted`, `--wf-line`,\n  `--wf-paper`, `--wf-card`, `--wf-accent`, `--wf-accent-soft`, `--wf-warn`, and\n  `--wf-ok`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not\n  set `font-family` and do not hard-code hex, rgb, or hsl colors in diagram HTML\n  or CSS. Use legacy `nodes` / `edges` only for small previews or truly\n  sequential flows. In architecture/code plans, prefer a repeated section rhythm:\n  recommendation title, confidence and category badges, code-path evidence, a\n  local before/after or current/target spatial diagram, then concise\n  Problem/Solution/Why text. Labels must not overlap nodes, connectors, or each\n  other.\n- `tabs` for multiple states, directions, or comparisons. A tab that reveals\n  only prose usually means the plan is under-specified \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nThat bottom form is the ONLY place that enumerates the open questions: never add\na second \"Open Questions\" heading, list, or recap of the same questions earlier\nin the document. A one-line pointer in the overview prose (\"a few decisions are\nstill open \u2014 see Open Questions below\") is fine, but do not reproduce the\nquestion list or a parallel questions/decisions section above it.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question in both a `decision` block and a\n`question-form`.\n\n**`custom-html` is a bounded escape hatch only** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\n\n**Before handoff, open the plan and check it.** Fix overlap, excessive\nwhitespace, clipped fragments, misleading inactive controls, poor contrast, and\nunreadable diagrams before asking for approval.\n\n<!-- SHARED-CORE:document-quality END -->\n\n## Good vs. Bad Exemplar\n\n<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard whose\n`data.html` is a real flex layout \u2014 a sidebar of links (`Inbox 12`, `Today 4`,\n`Done`), a main column with an `<h1>Today</h1>`, accent `.wf-pill`s for the\nfilters, a muted section label `OVERDUE`, and `.wf-card` task rows carrying real\ntitles, due dates, and a primary `button.primary` \u2014 styled only through bare\nelements, helper classes, and `--wf-*` tokens, so the renderer applies the\ncorrect desktop footprint, theme, and one subtle whole-frame wobble. Plain-text\ndesigner notes sit spaced off the frame, pointing only at the controls that need\nexplanation. Below it, a Claude/Codex-grade document: objective and\ndone-criteria, a few `code` blocks (grouped in a vertical `tabs` block when\nmore than one) showing the real shape of the load-bearing files, a `decision`\ncard weighing two real approaches,\nand a validation step \u2014 none of it repeating the canvas. If the task also\nchanges a multi-step completion flow, the same top area includes a Prototype tab\nwhose screens use the same labels and states as the canvas artboards, with\n`data-goto` controls for the sequence. This is the bar.\n\n**GOOD.** A `/visual-plan` for a backend architecture review: no top canvas.\nThe document opens with context and a legend, then repeats recommendation cards:\ntitle, confidence/category badges, a monospace grid of real file paths, one\ninline two-dimensional before/after or layered architecture diagram, and terse\nProblem/Solution/Why bullets using the codebase's vocabulary. The diagram uses\nspace to show boundaries, layers, and ownership; it is not a default\nleft-to-right chain. The plan ends with a top recommendation and a bottom\nquestion-form only if the next architecture direction is genuinely open. This is\nbetter than a top canvas because each diagram is local to the claim it supports.\n\n**BAD.** A `data.html` with hard-coded hex colors, a `font-family`, or fixed\npixel width/height; gray placeholder bars \"insinuating\" text on a non-skeleton\nframe; a forced desktop + mobile pair for a popover; floating bordered\nannotation cards hugging the frames; a fresh hand-authored kit-tree `screen`\ninstead of `html`; a multi-step UI flow with only static frames and no prototype\ntab; a mockup escaped into a document `custom-html` block; and a marketing-style\ndocument with a hero heading and value props that just restates what the canvas\nalready shows. Also bad: an architecture-only plan forced into a top canvas of\nlabeled boxes with overlapping text, where the actual code evidence and\nrecommendations live elsewhere. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-ui-plan`: create the UI-first structured visual plan.\n- `create-prototype-plan`: create a prototype-first plan when UI review needs a\n  functional live prototype.\n- `create-plan-design`: create a full-fidelity branded design plan when polish,\n  brand, and detailed visual direction are primary review inputs.\n- `convert-visual-plan-to-prototype`: convert an existing HTML wireframe canvas\n  into a prototype plan.\n- `create-visual-questions`: use only for the explicit `/visual-questions`\n  command, not as `/ui-plan` preflight.\n- `update-visual-plan`: revise content, mockups, comments, or handoff notes;\n  prefer targeted `contentPatches`.\n- `read-visual-plan-source`: read the normalized plan as `plan.mdx`,\n  optional `canvas.mdx`, optional `.plan-state.json`, and JSON.\n- `patch-visual-plan-source`: apply granular MDX AST patches by stable block,\n  artboard, annotation, component, or wireframe-node id.\n- `import-visual-plan-source`: create or replace a plan from an MDX folder.\n- `get-visual-plan`: inspect the current structured plan, exported HTML, and\n  annotations; it also returns the MDX folder for source workflows.\n- `get-plan-feedback`: read unconsumed reviewer comments before coding; it\n  returns grouped threads, exact anchor details, expected resolver, and recent\n  review-event payloads so agents can act only on the comments meant for them.\n- `export-visual-plan`: export HTML, Markdown fallback, structured JSON, and MDX\n  files for repo check-in.\n\nWhen the user critiques a plan's look or structure, fix the renderer or this\nskill \u2014 never hand-edit one stored plan. Turn feedback into better guidance.\n\n## Setup & Authentication\n\nThere are two ways into Plans.\n\n**Coding agent (CLI).** Install once with the Agent-Native CLI. The command\ninstalls the Plans skills, registers the hosted Plans MCP connector, and\nauthenticates it in the same step (a one-time browser sign-in at setup \u2014 this is\nintended), so the first tool call does not hit an OAuth wall:\n\n```bash\nagent-native skills add visual-plan\n```\n\nAfter that, `/visual-plan` (and `/visual-recap`, `/ui-plan`,\n`/prototype-plan`, `/plan-design`, `/visual-questions`) generate a plan and open\nthe editor. Pass `--no-connect` to\nregister the connector without authenticating, then run\n`agent-native connect https://plan.agent-native.com` whenever you are ready.\n\n**Browser (people you share with).** Open the Plans editor and create & edit\nwith no sign-up \u2014 you work as a guest. Sign in only when you want to save or\nshare; signing in claims the plans you made as a guest into your account.\n\nSharing and commenting require an account: public/shared plans are viewable by\nanyone with the link, but commenting on them needs an agent-native account.\n\nFor fully offline, no-account use, run the Plans app locally and sync plans to\nyour repo as MDX. This local mode is a separate advanced path, not the default\nhosted flow.\n\nIf a Plans tool returns `needs auth`, `Unauthorized`, or `Session terminated`,\ndo not keep retrying the tool. Authenticate the connector with\n`agent-native connect https://plan.agent-native.com` (OAuth-capable hosts can\ninstead re-run /mcp and choose Authenticate), then continue once the connector\nis available.\n\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do\nnot put shared secrets in skill files.\n";
 export declare const PROTOTYPE_PLAN_SKILL_MD = "---\nname: prototype-plan\ndescription: >-\n  Use Agent-Native Plans for /prototype-plan when work needs a functional\n  prototype-first plan, static mocks, comments, review toggles, or conversion\n  from a visual plan.\nmetadata:\n  visibility: exported\n---\n\n# Prototype Plan\n\n`/prototype-plan` creates a plan whose primary review surface is a live,\nfunctional prototype above the document. Use it when the user needs to feel a\nflow, operate basic UI state, or comment on interaction before implementation\nhardens the decision.\n\n## Rule\n\nMake the prototype answer a concrete question. The plan should say what is being\ntested, show the functional prototype first, then keep static mocks and implementation\nnotes in the document below.\n\n## When To Use\n\nUse `/prototype-plan` when the user asks for a prototype, wants to click through\nand operate UI states, needs design review before code, wants comments pinned to\nlive screens, or asks to move a visual plan into a prototype.\n\nPrefer `/visual-plan` for architecture, data flow, or non-interactive planning.\nPrefer `/ui-plan` when static screen review is enough. Use `/visual-plan` first\nwhen the user hands you an existing Markdown/Codex/Claude plan that needs a\nvisual companion before becoming interactive.\n\n## Core Workflow\n\n1. Inspect the real codebase and decide the question the prototype should\n   answer. Good examples: \"Does this onboarding flow feel short enough?\" or\n   \"Which dashboard density should we implement?\"\n2. Call `create-prototype-plan` with a title, brief, and screen HTML. Default to\n   one functional prototype screen when local UI behavior is enough; use 2-4\n   screens only for true routes, steps, or materially different contexts. The\n   returned plan opens with the prototype viewer on top and static mocks, flow\n   diagram, implementation map, and verification below.\n3. Make controls actually work. Use the renderer's safe Alpine-like directives:\n   `x-data`, `x-model`, `x-for`, `x-text`, `x-show`, `:class`, `@click`, and\n   `@keydown.enter`. Use safe helper verbs such as `remove(list, item)`,\n   `setAll(list, 'done', true)`, `removeWhere(list, 'done', true)`, and counters\n   such as `count(list)`, `countWhere(list, 'done', true)`, and\n   `remaining(list, 'done')` when they help. Use `data-goto=\"screen-id\"` only\n   for true screen/route changes, not for every button press.\n4. Show important app feedback inside the prototype itself: selected filters,\n   checked rows, typed drafts, validation messages, permissions, progress, or\n   empty states.\n5. Surface the returned Plans link and ask the user to click through, comment on\n   the prototype or static mocks, and approve the direction before code changes.\n6. Before implementing or revising, call `get-plan-feedback`. Treat prototype\n   anchors, screenshots, and resolver intent as the source of truth.\n7. Update with `update-visual-plan` content patches. Use\n   `patch-prototype-html`, `update-prototype-screen`, or `set-prototype` for\n   targeted prototype edits instead of regenerating the whole plan.\n\n## Converting A Visual Plan\n\nWhen a visual plan already has HTML canvas wireframes, call\n`convert-visual-plan-to-prototype` with the plan id. This derives prototype\nscreens from the canvas frames, preserves the canvas/static mocks by default,\nand changes the top review surface to the prototype viewer.\n\nUse `removeCanvas: true` only when the user explicitly wants the old canvas\ngone. Otherwise keep static mocks available for source export and detailed\nreview.\n\n## Prototype Screen HTML\n\nWrite bounded semantic HTML fragments only:\n\n```html\n<div style=\"display:flex;flex-direction:column;gap:14px;padding:18px;height:100%\">\n  <header style=\"display:flex;justify-content:space-between;gap:12px\">\n    <div>\n      <h1>Launch checklist</h1>\n      <p class=\"wf-muted\">Reviewer can add, complete, filter, and remove tasks.</p>\n    </div>\n    <span class=\"wf-pill accent\">Live prototype</span>\n  </header>\n  <section\n    class=\"wf-card\"\n    x-data=\"{ draft: '', filter: 'all', todos: [{ text: 'Check copy', done: false }, { text: 'Confirm owner', done: true }] }\"\n    style=\"display:flex;flex-direction:column;gap:10px\"\n  >\n    <div style=\"display:flex;gap:8px\">\n      <input x-model=\"draft\" @keydown.enter=\"draft && todos.push({ text: draft, done: false }); draft = ''\" placeholder=\"Add task\" />\n      <button class=\"primary\" @click=\"draft && todos.push({ text: draft, done: false }); draft = ''\">Add</button>\n    </div>\n    <div style=\"display:flex;gap:8px\">\n      <button @click=\"filter = 'all'\" :class=\"{ primary: filter === 'all' }\">All</button>\n      <button @click=\"filter = 'done'\" :class=\"{ primary: filter === 'done' }\">Done</button>\n      <button @click=\"setAll(todos, 'done', true)\">Mark all done</button>\n    </div>\n    <p class=\"wf-muted\"><span x-text=\"remaining(todos, 'done')\"></span> open / <span x-text=\"count(todos)\"></span> total</p>\n    <div\n      class=\"wf-box\"\n      x-for=\"todo in todos\"\n      x-show=\"filter === 'all' || (filter === 'done' && todo.done)\"\n      :class=\"{ 'is-done': todo.done }\"\n      style=\"display:flex;justify-content:space-between;gap:10px\"\n    >\n      <label style=\"display:flex;gap:8px\"><input type=\"checkbox\" x-model=\"todo.done\" /><span x-text=\"todo.text\"></span></label>\n      <button @click=\"remove(todos, todo)\">Remove</button>\n    </div>\n    <button @click=\"removeWhere(todos, 'done', true)\">Clear completed</button>\n  </section>\n</div>\n```\n\nUse real labels, counts, dates, and controls grounded in the target app. Keep\nsurfaces honest: `browser` for web pages, `desktop` for app shells, `mobile`\nonly for real mobile work, `panel` for side panels, and `popover` for menus.\n\nDo not include `<html>`, `<body>`, `<script>`, `<style>`, browser `on*`\nhandler attributes such as `onclick`, fake APIs, raw secrets, or customer data.\nThe renderer owns sketchy/clean mode, theme, surface sizing, rough outlines, and\ncomment overlays.\n\n## Review Surface\n\nPrototype plans support:\n\n- real local controls through safe prototype directives\n- optional screen/route transitions from `data-goto`\n- rough vs clean mode through the shared wireframe toggle\n- dark vs light mode through the shared theme toggle\n- comment visibility from the prototype toolbar\n- Figma-style comments pinned directly on live prototype screens\n- a popout URL with `?prototype=1` for focused browser review\n- static wireframe mocks in the document body where they help implementation\n\n## Source Files\n\nRuntime JSON is canonical. Source export uses:\n\n- `plan.mdx` for document blocks\n- `prototype.mdx` for `<Prototype>`, `<PrototypeScreen>`, and\n  `<PrototypeTransition>`\n- `canvas.mdx` for static mocks when a canvas is present\n- `.plan-state.json` for persisted viewport state\n\nPatch source with `patch-visual-plan-source` only when the user wants\nsource-control friendly edits. Patch runtime content when the user is simply\nreviewing and iterating.\n\n## Related Skills\n\n- `visual-plan`\n- `ui-plan`\n- `visual-questions`\n";
 export declare const PLAN_DESIGN_SKILL_MD = "---\nname: plan-design\ndescription: >-\n  Use Agent-Native Plans for full-fidelity UI design planning with a Design\n  canvas tab and optional interactive Prototype tab before implementation.\nmetadata:\n  visibility: exported\n---\n\n# Plan Design\n\nUse `/plan-design` when the user needs a high-fidelity product design before\nimplementation: polished branded screens, realistic content, visual direction,\nand interaction review. It is the full-fidelity companion to `/visual-plan` and\n`/prototype-plan`: the top review surface should show `Design` and, when the\nflow needs interaction, `Prototype`.\n\n## When To Use\n\nUse this for UI-heavy work where brand, visual hierarchy, polished layout, or\ninteraction feel are material to the decision. Skip it for small copy, spacing,\nor obvious component changes.\n\n## Research First\n\nBefore creating the plan:\n\n1. Inspect the real app shell, routes, components, CSS variables, Tailwind\n   tokens, theme files, and any relevant screenshots.\n2. If `design.md` exists, treat it as the primary design brief and pass its\n   important content into `create-plan-design.designMd`.\n3. If a `.fig` local-copy file or parsed brand kit is available, use the\n   Design/brand-kit parsing actions from the app or shared tooling first, then\n   pass the extracted token summary into `brandKit`.\n4. Parse existing codebase style info when possible: CSS custom properties,\n   Tailwind config, global CSS, font declarations, spacing/radius tokens, and\n   component conventions. Pass the compact evidence into `codebaseStyles`.\n5. Ground every screen in actual product content. Avoid lorem ipsum, generic\n   marketing filler, and placeholder gray boxes unless designing an explicit\n   loading state.\n\n## Create The Plan\n\nCall `create-plan-design` with:\n\n- `title`, `brief`, `repoPath`, and any `implementationNotes`.\n- `designMd`, `brandKit`, `codebaseStyles`, or `designNotes` when available.\n- `screens`: one to six full-fidelity HTML/CSS screen fragments. Each screen\n  must include a bounded `html` fragment, optional scoped `css`, a `surface`,\n  and stable `data-design-id` attributes on elements a reviewer might edit.\n- `transitions` only when the Prototype tab should support true screen/step\n  navigation. Use `data-goto=\"screen-id\"` in the screen HTML for those controls.\n\nThe Design tab is the visual source of truth. The Prototype tab is for behavior\nand should reuse the same visual styling where practical. Do not create a\nseparate design direction in the prototype.\n\n## Full-Fidelity HTML Rules\n\n- Write bounded fragments only: no `<html>`, `<head>`, `<body>`, `<script>`,\n  `<style>`, external imports, iframes, SVG, or executable URLs.\n- Put CSS in the screen `css` field. The renderer scopes it to the artboard.\n- Use real CSS and CSS variables. Tailwind-like class names are fine only when\n  the provided `css` defines them or the classes are harmless semantic hooks.\n- Use `renderMode: \"design\"` on design screen data when authoring full\n  structured content directly.\n- Add `data-design-id=\"meaningful-name\"` to editable elements such as hero\n  panels, key buttons, cards, nav items, pricing rows, chart panels, and state\n  chips. Keep ids stable and descriptive.\n- Keep the design responsive within the selected surface. Text must not clip,\n  overlap, or rely on viewport-sized type.\n\n## Targeted Style Edits\n\nWhen a reviewer selects an element in the Design tab or asks for a specific\nstyle change, avoid regenerating the whole plan. Use:\n\n```json\n{\n  \"op\": \"update-design-element-style\",\n  \"frameId\": \"frame-overview\",\n  \"elementId\": \"primary-cta\",\n  \"styles\": {\n    \"background-color\": \"#0f766e\",\n    \"border-radius\": \"10px\"\n  }\n}\n```\n\nUse `frameId` for inline canvas designs or `blockId` for a referenced wireframe\nblock. Set a style value to `null` to remove it. Use `patch-wireframe-html` or\n`patch-prototype-html` for text/content changes inside a fragment.\n\n## Document Handoff\n\nBelow the visual surface, keep the document concise and implementation-oriented:\nactual files and symbols, state/actions/contracts, open questions, risks, and\nverification. The document should not repeat the same screens in prose.\n\nBefore implementation, call `get-plan-feedback` and treat comments, selected\nelement details, and recent review events as the source of truth.\n\n## Related Skills\n\n- `visual-plan`\n- `ui-plan`\n- `prototype-plan`\n- `frontend-design`\n";
 export declare const VISUAL_RECAP_SKILL_MD = "---\nname: visual-recap\ndescription: >-\n  Use Agent-Native Plans to turn a code change, PR diff, or git diff into a\n  visual recap plan for high-altitude review \u2014 schema, API, file, and\n  before/after changes as grounded structured blocks instead of a wall of diff.\nmetadata:\n  visibility: exported\n---\n\n# Visual Recap\n\n`/visual-recap` creates a visual plan built **from** a diff, not toward one. It\nis the reverse of forward planning: instead of describing the change you are\nabout to make, you describe the change that was just made, at a higher altitude\nthan line-by-line review. The same plan data model serves both directions \u2014\nschema, API, file, and architecture changes become the same `data-model`,\n`api-endpoint`, `file-tree`, and `diagram` blocks a forward plan would use, only\nnow they summarize work that exists. A reviewer scans the shape of the change\nbefore spending attention on the literal lines.\n\n## Always Publish As An Agent-Native Plan \u2014 Never Inline\n\nThe deliverable is ALWAYS a published Agent-Native Plan, created with the\n`create-visual-recap` tool on the `plan` MCP server. NEVER hand the recap to the\nuser as inline chat content \u2014 not Markdown prose, not an ASCII sketch, not a\ntable, not a fenced \"wireframe\", not a \"here's the recap\" summary. A recap's\nentire value is the hosted, interactive, annotatable plan; an inline summary is\nnot a recap, it is the thing a recap replaces. The only supported output is to\npublish the plan and return its absolute URL.\n\nIf the `plan` MCP server's tools are not available, do NOT improvise an inline\nrecap as a fallback. The usual cause is a connector that did not finish\nconnecting this session (it registers zero tools), NOT necessarily an auth\nproblem \u2014 so do not assume the user must authenticate. Stop and tell the user\nhow to restore it: reconnect the plan MCP server (in Claude Code, run `/mcp` and\nreconnect, or restart the session); only if it is genuinely unauthenticated, run\n`agent-native connect <plan-app-url>` or re-authenticate via `/mcp`. Then publish\nonce the tool is reachable. Falling back to inline content is a defect, not a\ndegraded mode.\n\n## When To Use\n\nBuild a recap when a PR or commit is large, multi-file, or touches schema, API\ncontracts, or architecture, and a reviewer would benefit from seeing the change\nmapped to structured blocks before reading the raw diff. A GitHub Action can\ngenerate one automatically from a PR diff; an agent can generate one on request\n(\"recap this PR\", \"show me what this branch changed\"). Skip it for small,\nsingle-file, or obvious diffs \u2014 a recap is review overhead, and a tiny change\nreviews faster as plain diff.\n\n## Recap The Whole Work Unit\n\nWhen `/visual-recap` is invoked in a chat thread after work has already happened,\nthe default scope is the whole current work unit/thread, not only the most recent\nuser message, tool action, or follow-up fix. Gather the thread-owned changes\nacross the conversation: original implementation work, later bug fixes, UI\nfollow-ups, tests, changesets, skill/instruction updates, generated plan/source\nartifacts, and any local import/linking fixes needed to make the recap open.\n\nUse the current diff plus conversation context to separate thread-owned changes\nfrom unrelated dirty work that existed before the thread. Exclude unrelated\npre-existing edits. If the scope is genuinely ambiguous and cannot be inferred,\nstate the assumption or ask a concise question before publishing.\n\nWhen updating an existing recap after feedback, revise the recap so it still\ncovers the whole thread/work unit plus the new correction. Do not replace a broad\nrecap with a narrow recap of only the latest feedback unless the user explicitly\nasks for that narrower scope.\n\n## Keep The Recap Body Lean\n\nDo not add boilerplate intro, disclaimer, provenance, or summary prose blocks to\nthe generated plan body. In particular, do not create a `rich-text` block just to\nsay the recap is an aid, that the reviewer should still review the diff, how many\nfiles changed, or which ref/working tree generated the recap. The plan title,\nbrief, `file-tree`, and optional `diffstat` already carry that context.\n\nOnly add prose blocks when they tell the reviewer something specific about the\nchange that the structured blocks do not: the objective, a real compatibility\nrisk, an important decision visible in the diff, or a grounded review note.\n\n## UI Impact Needs Wireframes\n\nWhen the diff changes rendered UI, layout, density, visual state, interaction\naffordances, navigation, controls, menus, dialogs, or design tokens, the recap\nMUST include one or more wireframes. Prose and file diffs are not a substitute\nfor showing what changed visually.\n\nChoose the smallest visual surface that makes the review clear:\n\n- Use a `Before` / `After` wireframe pair when the reviewer benefits from direct\n  comparison, such as a removed or added control, a changed state, layout\n  density, ordering, navigation, or a visible component replacement. The\n  Wireframe Quality core below owns how to lay that pair out (columns vs.\n  vertical stack by geometry).\n- Use an after-only wireframe when the change is purely additive or the \"before\"\n  state would only show absence without adding review value.\n- Use more than two wireframes when the UI change is flow-dependent, responsive,\n  or stateful; show the meaningful states in order instead of forcing a single\n  before/after pair.\n- For tiny surfaces like menus, popovers, dialogs, toasts, or panels, use the\n  matching `surface` (`popover`, `panel`, etc.) and show the focused sub-surface.\n  Do not redraw a full page unless placement in the page is itself part of the\n  change.\n\nGround each wireframe in the changed UI behavior, component names, file paths,\nand diff-visible labels/states. If exact pixels are inferred rather than\ncaptured, say so in the wireframe caption or a concise annotation. For\nlocal/manual recaps, import or update the plan source that holds the wireframes\nso the rendered recap opens with the UI visual available.\n\n## Wireframe Quality\n\nUI recap wireframes must look like the UI surface that changed, not like generic\narchitecture boxes. The following bar is shared, word for word, with\n`/visual-plan` and `/ui-plan`: it is the single source of truth for HTML\nwireframe quality, and applies to a recap's standalone `wireframe` /\n`WireframeBlock` / `<Screen>` exactly as it applies to a plan's canvas artboard.\n\n<!-- SHARED-CORE:wireframe-quality START -->\n\n**A wireframe is an HTML mockup. The renderer owns the look; you write the\ncontent.** Set `data.html` to a self-contained, semantic HTML fragment of the\nscreen and set `data.surface`. The renderer owns the surface footprint/aspect,\nthe dark/light theme, the hand-drawn font, and the rough.js sketch overlay \u2014 you\nnever write `<html>`/`<body>`/`<script>`/`<style>` tags, font-family, hex colors,\nor any width/height/coordinates. You write real HTML layout and real product\ncontent; the renderer styles and roughens it.\n\n**A wireframe block's data is an HTML screen plus a surface:**\n\n```json\n{\n  \"surface\": \"browser\",\n  \"html\": \"<div style=\\\"display:flex;flex-direction:column;gap:10px;padding:16px;height:100%\\\"><h1>Sign in</h1><p class=\\\"wf-muted\\\">Use your work email to continue.</p><div class=\\\"wf-card\\\" style=\\\"display:flex;flex-direction:column;gap:10px\\\"><label>Email<input value=\\\"jane@acme.co\\\" /></label><label>Password<input value=\\\"\u2022\u2022\u2022\u2022\u2022\u2022\u2022\u2022\\\" /></label><label style=\\\"display:flex;align-items:center;gap:8px\\\"><input type=\\\"checkbox\\\" checked /> Remember me</label><button class=\\\"primary\\\">Sign in</button></div><a href=\\\"#\\\">Forgot password?</a></div>\"\n}\n```\n\n**Write PLAIN semantic HTML and let the renderer style it.** Bare elements\n(`h1`/`h2`/`h3`, `p`, `button`, `input`, `<input type=\"checkbox\">`, `a`, `hr`)\nare auto-themed \u2014 no classes needed. Helper classes carry the rest:\n\n- `.wf-card` / `.wf-box` \u2014 a bordered, padded container (a panel, a list item).\n- `.wf-pill` / `.wf-chip` \u2014 a rounded tag or filter; add `.accent`\n  (`<span class=\"wf-pill accent\">`) for the accent-filled variant.\n- `.wf-muted` \u2014 secondary/muted text (or use `<small>`).\n- `button.primary` or any element with `[data-primary]` \u2014 the accent-filled\n  primary button.\n\n**Use the `--wf-*` tokens for any custom color, never hex.** The renderer flips\nthese on light/dark, so reading them is what keeps a mockup correct in both\nthemes. For any inline border, background, or text color, reference a token:\n`style=\"border:1.4px solid var(--wf-line)\"`. The tokens are `--wf-ink` (text),\n`--wf-muted` (secondary text), `--wf-line` (borders/dividers), `--wf-paper`\n(page background), `--wf-card` (raised surface), `--wf-accent` /\n`--wf-accent-fg` / `--wf-accent-soft` (brand action), `--wf-warn`, `--wf-ok`,\nand `--wf-radius`. Never hard-code a hex color and never set `font-family` \u2014 the\nrenderer owns the sketch/clean font.\n\n**Lay out with inline `style` flex/grid.** You write the real layout \u2014\n`display:flex; flex-direction:column; gap:10px; padding:16px` and so on \u2014 and the\nrenderer never repositions anything. Compose the actual product: reproduce the\ncurrent screen, then show the modification. Real labels, real counts, real dates,\nreal button text grounded in the screen you read; not lorem or gray bars.\n\n**Surface presets \u2014 match the real footprint, never default to desktop+mobile.**\nPick the `surface` that matches what the user will actually see:\n\n- `browser`: a web page that needs a browser chrome frame around it.\n- `desktop`: a full desktop app page or app shell.\n- `mobile`: a phone screen, only when the work is genuinely mobile.\n- `popover`: a small floating menu, dropdown, or inline popover.\n- `panel`: a side panel, inspector, or sidebar widget.\n\nA sidebar popover renders as a small surface, not a desktop page and a phone\nframe. Do not emit `desktop` + `mobile` variants unless responsive behavior\nactually changes the layout. For a component or widget, show one broader\napp-context frame only when placement affects understanding, then the focused\ncomponent states.\n\n**Model the actual component shell for small surfaces.** A rendered UI change\nbelongs in a wireframe; reserve `diagram` for architecture, dependency, state,\nor data-flow relationships. Popovers, dropdown menus, command palettes, and\ncontext menus use `surface: \"popover\"` unless the surrounding page placement is\nthe point of the change. Dialogs, sheets, inspectors, sidebars, and long\nproperty panels use the matching `panel` / `desktop` surface as appropriate.\nShow the real chrome: trigger or anchor when it matters, title/header row,\ntop-right actions, separators, fields, options, selected states, body content,\nand footer actions that are visible in the workflow.\n\n**Modify, don't redesign.** When the task changes an existing screen, reproduce\nthe current screen's real layout and footprint FIRST, then change only the delta\nand call it out with a single annotation. Do not restack the page into a new\nlayout. For net-new surfaces, compose from the real app shell.\n\n**Classify mockup scope before implementation.** Before turning a plan mockup\ninto source code, decide whether each artboard represents the whole page/app\nshell, a route body inside an existing shell, or a component/sub-surface. If an\nartboard includes navigation, sidebars, auth banners, or a signup/login form,\nmap those pieces to the real shared shell/auth components instead of nesting the\nentire mockup inside the current page. When a mockup references the product's\nstandard signup/login page, find and reuse that existing implementation; do not\napproximate it from the wireframe.\n\n**Zoom in on sub-surfaces, don't redraw the page.** For a small sub-surface (a\npopover, menu, dialog, toast), show the full screen once, then add a small\nseparate artboard whose `html` contains ONLY that sub-surface \u2014 do not re-draw\nthe whole page around it, and do not scale a duplicate up. Pick the matching\n`surface` (e.g. `popover`) so the footprint is right; never widen a popover to\npage width.\n\n**Loading / skeleton states.** Set `data.skeleton: true` on the wireframe and\nfill the `html` with neutral, textless placeholder geometry \u2014 boxes and bars\nbuilt as `<div>`s with `background:var(--wf-line)` and explicit heights/widths,\nno labels or copy. The renderer drops borders, sketch, and color into the\nskeleton register automatically. Never escape to a `custom-html` document block\nto fake a loader.\n\n**Editing an existing mockup.** To change one element, text, or color in an\nexisting html mockup, do NOT regenerate the frame \u2014 call `update-visual-plan`\nwith `contentPatches: [{ op: \"patch-wireframe-html\", blockId, edits: [{ find,\nreplace }] }]`. Each `find` is a unique snippet of the current html (read it\nfirst with `get-visual-plan`); set `all: true` on an edit to replace every\noccurrence. The result is re-sanitized.\n\n**Treat the wireframe border as part of the visible design.** Always wrap HTML\nwireframe content in a root container with real inner padding before drawing\ncards, fields, pills, labels, or controls. Use at least 14-16px of padding,\n`box-sizing: border-box`, `height: 100%`, and `gap` between child rows so the\nfirst row never sits flush against the screen border. Keep text away from\nborders: every container, field, button, menu item, and annotation needs enough\npadding and line-height to read cleanly in the rendered Plan view.\n\n**Lay out children safely so they never collide.** Use HTML flex/grid with\n`gap`, `min-width: 0`, and sensible overflow. Avoid negative margins, absolute\npositioning, or fixed child widths that can collide when the renderer switches\nbetween light/dark, sketch/clean, or different zoom levels.\n\n**Do not wrap intentionally single-line labels.** For tab rails, breadcrumbs,\nfile chips, code filenames, and other deliberately single-line labels, do not\nlet long text wrap. It is acceptable and usually preferable to use\n`white-space: nowrap`, `overflow: hidden`, and `text-overflow: ellipsis` (or\nabstract bars) so the wireframe demonstrates the actual layout behavior instead\nof producing ugly vertical text. Use horizontally scrollable or clipped rails\nfor overflow.\n\n**Fill the frame; keep labels short.** Each artboard is a fixed-size surface \u2014 compose enough realistic HTML to fill it top to bottom with even vertical rhythm; never leave a large empty band. On desktop/app-shell sidebars, let the nav stack flex to fill (`flex:1`) and add any persistent bottom action/status after it so the rail reads complete in taller frames. On mobile especially, flow real rows down the whole screen (status bar, header, then list/detail content) rather than a header floating above a gap. Keep every label short enough to sit on one line within its column \u2014 shorten the copy rather than relying on the frame to absorb it (long labels wrap or clip).\n\n**Before / after must be comparable.** When showing a state change, preserve the\nunchanged controls in both states so the reviewer can see exactly what moved or\nappeared; do not show an added control as a generic box floating elsewhere in\nthe surface. Place the new/changed affordance where the implementation puts it \u2014\nfor example, a new `Edit with AI` action in a popover header belongs in the\ntop-right header slot, aligned with the title, not in the body or footer. Use\nthe same frame size, scale, outer padding, border radius, and visual density on\nboth sides unless the change itself alters those properties, and let the frame\nheight fit the content rather than leaving a tall empty lower half.\n\n**Name the states with the column header, never inside the frame.** Put the two\nstates in a `columns` block and set each column's `label` to `Before` and\n`After` \u2014 the renderer draws that label as an `h4` heading above each frame. Do\nNOT bake a `Before`/`After` pill, title, or heading into the wireframe `html`: a\nlabel placed inside reads as part of the product UI, lands in a random corner,\nand clutters the comparison. The column header is the one and only place the\nstate name belongs.\n\n**Let the surface choose side-by-side vs. stacked.** The `columns` renderer lays\nnarrow surfaces (`mobile`, `popover`, `panel`) out side by side, and\nautomatically stacks wide surfaces (`desktop`, `browser`) vertically at full\ndocument width so a large frame is never crushed into a half-width column and\ncropped. Author both wireframes with the real `surface` and the matching\n`Before`/`After` column labels; do not hand-stack the pair into separate\ntop-level wireframes or duplicate the state name as body content.\n\n**Good example \u2014 a contacts list, surface `browser`.** A small, real screen\ncomposed from the helper classes and tokens, layout in inline flex, no fonts or\nhex colors:\n\n```html\n<div\n  style=\"display:flex;flex-direction:column;gap:12px;padding:16px;height:100%\"\n>\n  <div style=\"display:flex;align-items:center;justify-content:space-between\">\n    <h1>Contacts</h1>\n    <button class=\"primary\">New contact</button>\n  </div>\n  <div style=\"display:flex;gap:6px\">\n    <span class=\"wf-pill accent\">All 128</span>\n    <span class=\"wf-pill\">Favorites</span>\n    <span class=\"wf-pill\">Archived</span>\n  </div>\n  <div\n    class=\"wf-card\"\n    style=\"display:flex;flex-direction:column;gap:0;padding:0\"\n  >\n    <div\n      style=\"display:flex;align-items:center;gap:10px;padding:10px 12px;border-bottom:1.4px solid var(--wf-line)\"\n    >\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Jane Cooper</strong><br /><small>jane@acme.co</small>\n      </div>\n      <span class=\"wf-pill\">Lead</span>\n    </div>\n    <div style=\"display:flex;align-items:center;gap:10px;padding:10px 12px\">\n      <div\n        style=\"width:32px;height:32px;border-radius:999px;background:var(--wf-accent-soft)\"\n      ></div>\n      <div style=\"flex:1\">\n        <strong>Marcus Lee</strong><br /><small>marcus@globex.io</small>\n      </div>\n      <span class=\"wf-pill\">Customer</span>\n    </div>\n  </div>\n</div>\n```\n\n<!-- SHARED-CORE:wireframe-quality END -->\n\nUse the standard `WireframeBlock` / `<Screen>` format so the Plan viewer owns the\nsurface frame, theme, and sketchy/clean toggle. HTML wireframes are appropriate\nwhen placement precision matters, especially popovers, menus, dialogs, and dense\nforms; kit-tree wireframes are appropriate for simpler layouts. For HTML\nwireframes, keep `renderMode` unset or `wireframe` unless a design-only editable\nmockup is explicitly required, because `renderMode=\"design\"` disables the\nsketchy rough overlay.\n\nBefore sharing a UI-impact recap, render it in the Plan viewer and inspect it at\nthe current theme. If any label, annotation, toolbar, or wireframe content\noverlaps another element, fix the MDX and re-import before reporting the link. A\ntext-match screenshot is not enough; visually inspect the captured image.\n\n## Open And Report The Recap\n\nAfter creating the recap, link the reviewer to the rendered plan with an\n**absolute URL on the origin whose database actually holds the plan**. That\norigin is the Plan MCP server you just created the recap through \u2014 NOT whatever\ndev server you happen to know is running. The create tool returns the correct\nlink; report THAT. Never make the primary link a local `plan.mdx` file, a local\nmirror folder, or a relative path such as `/plans/<id>`.\n\nA recap lives only in the database of the MCP that created it. A separately\nrunning local dev server (e.g. `http://localhost:8081`) has its OWN database and\nwill NOT contain a recap created through the hosted MCP, so a hand-built\n`localhost` link returns \"Plan not found\". This is the most common recap\nmistake \u2014 do not guess an origin you have not confirmed shares the MCP's data.\n\nResolve the URL in this order:\n\n1. Use the absolute URL the create tool RETURNS \u2014 `openLink.webUrl`, else the\n   `visualUrl` in the returned `plan.mdx` frontmatter, else `url`/`path`\n   resolved against the MCP server's own origin (for the hosted MCP that is\n   `https://plan.agent-native.com`). This always points at the database that has\n   the plan.\n2. Use a `localhost`/dev origin ONLY when the recap was created through a Plan\n   MCP bound to that same origin \u2014 i.e. that MCP's url is\n   `http://localhost:<port>/_agent-native/mcp`. Creating through the hosted MCP\n   and linking to localhost is the exact mismatch that 404s.\n3. If only a plan id is available, build the MCP origin's absolute URL\n   (hosted: `https://plan.agent-native.com/plans/<id>`) and say it was inferred.\n\nIf the user wants to review on localhost but the recap was created through the\nhosted MCP, say so plainly: the local dev server cannot see it. To view a recap\non localhost (e.g. to exercise un-deployed local renderer changes), they must\nconnect a LOCAL Plan MCP (`http://localhost:<port>/_agent-native/mcp`) and\nre-create the recap through it so it lands in the local database; offer to do\nthat rather than handing over a localhost URL that will not resolve.\n\nWhen running in Codex and the Browser/in-app side browser tools are available,\nopen the returned absolute recap URL there automatically after creation. Still\ninclude the same absolute URL in the final response. Local mirror files like\n`plans/<slug>/plan.mdx` may be mentioned only as secondary source-control\nartifacts, not as the main way to open the recap.\n\n## Diff \u2192 Block Mapping\n\nMap each kind of change to the block that carries it, derived mechanically from\nthe actual diff:\n\n- **Schema / migration change** \u2192 `data-model` for the resulting entities,\n  fields, and relations. Flag what moved per field/entity with\n  `change: \"added\" | \"modified\" | \"removed\" | \"renamed\"`, and for a changed type\n  set `was` to the prior value (e.g. the old column type) \u2014 grounded in the real\n  migration diff. That diff-aware `data-model` is the headline; reach for a split\n  `diff` of the literal SQL only when the exact statement still matters, not by\n  default.\n- **API / action / route change** \u2192 `api-endpoint` with the method, path,\n  params, request, and responses as they are after the change. Flag each changed\n  param/response with `change` (and `was` on a param whose type/shape changed),\n  and set `change` on the endpoint root for a wholly added or removed route. Mark\n  removed endpoints with `deprecated: true` and explain in prose.\n  Keep multiple API endpoints in the normal single-column document flow unless\n  they are an explicit before/after contract comparison.\n- **Compatibility-sensitive change** \u2192 short `rich-text` notes beside the\n  relevant `data-model` / `api-endpoint` block. Name the changed field,\n  endpoint, or behavior and mark whether it is breaking, risky, or non-breaking;\n  pair that note with a split `diff` for the literal lines.\n- **Any meaningful code hunk** \u2192 `diff` with `mode: \"split\"`, carrying the real\n  `before` / `after` text and the `filename` / `language`. Split mode is the\n  default for a recap because before/after legibility is the whole point. Give\n  every `diff` a one-line `summary` saying what the hunk changes and why; it\n  renders as a description above the code so the reviewer reads intent first.\n  Never leave a diff unlabeled.\n  For the KEY changed files, attach `annotations` to the `diff` so the recap\n  calls out what each important hunk does \u2014 this is the headline affordance for\n  annotating the key files updated. Each annotation is\n  `{ side?: \"before\" | \"after\"; lines: \"13\" | \"13-15\"; label?: string; note }`\n  and anchors to the AFTER-side line numbers by default (set `side: \"before\"` to\n  point at removed lines). Keep it to a few high-signal notes per file, not one\n  per line.\n  When several key files each need a substantial diff, introduce the group with a\n  `rich-text` heading block whose markdown is `## Key changes`, then place the\n  `diff` blocks under it in a reusable `tabs` block with\n  `orientation: \"vertical\"` so file labels form a left rail and the selected\n  file's split diff renders on the right. Let that heading label the section \u2014 do\n  NOT also set a `title` on the `tabs` block. Keep each tab label to the file\n  path or a short basename plus directory hint.\n  If the recap ends with more than one supporting diff, that trailing diff\n  appendix should be one vertical `tabs` block under its own `## Key changes`\n  heading, not a stack of separate `diff` blocks.\n- **Brand-new file or a substantial added block with no meaningful \"before\"** \u2192\n  `annotated-code` rather than a one-sided split `diff`. Carry the real new code\n  with its `filename` / `language` and anchor a few high-signal notes to the lines\n  that matter (`{ lines: \"12\" | \"12-18\"; label?; note }`) so the reviewer reads\n  what the new code does, not code for code's sake. Keep split `diff` for true\n  before/after hunks where the removed lines still carry meaning, and group\n  several annotated walkthroughs in a vertical `tabs` block the same way diffs are\n  grouped.\n- **Files added / removed / renamed** \u2192 `file-tree` with each entry's `change`\n  flag (`added`, `removed`, `modified`, `renamed`) and a short `note`; attach a\n  `snippet` only when one tells the reviewer something the path does not.\n- **Rendered UI / interaction change** \u2192 one or more wireframes showing the\n  visible UI delta before the reviewer reads code. Use `Before` / `After`\n  wireframes when the comparison clarifies the change; otherwise use after-only\n  or a short state/flow sequence. Use realistic UI surfaces: for a popover\n  change, show a popover with its title row, top-right actions, options/fields,\n  and any opened prompt/menu anchored to the correct trigger. Keep the body lean:\n  the wireframe carries the UI story, while the file tree and split `diff`\n  blocks carry implementation evidence.\n- **Architecture or data-flow shift** \u2192 `diagram` with `data.html` / `data.css`\n  as a two-panel before/after, layered, or swimlane layout, or `mermaid` for a\n  quick graph. Use the two-dimensional layouts the Document Quality core\n  prescribes; do not reduce a structural change to a left-to-right chain.\n  Do not use `diagram` as a stand-in for rendered UI controls; UI changes need\n  `wireframe` blocks.\n  Diagram HTML/CSS should use renderer-owned primitives such as\n  `.diagram-panel`, `.diagram-card`, `.diagram-node`, `.diagram-box`,\n  `.diagram-pill`, `.diagram-muted`, and `[data-rough]`; these map to the plan's\n  Tailwind theme variables through `--wf-ink`, `--wf-muted`, `--wf-line`,\n  `--wf-paper`, `--wf-card`, `--wf-accent`, `--wf-accent-soft`, `--wf-warn`, and\n  `--wf-ok`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not\n  set `font-family` and do not emit hex, rgb/hsl literals, or one-off dark/light\n  palettes in diagram CSS.\n- **Outcome-first narrative** \u2192 `rich-text` for the \"what changed and why\" prose:\n  the objective the diff served, the key decisions visible in it, and the risks a\n  reviewer should weigh. This is the only place the model writes freely.\n\n## Before / After Is The Headline\n\nThe recap's center of gravity is the before/after comparison. For document-body\ncomparisons there are two primitives, and they cover the whole need together:\n\n- **`columns`** \u2014 the side-by-side container, for **structured** comparisons.\n  Use two columns labeled `Before` and `After`, each holding a block (commonly a\n  `data-model`, `api-endpoint`, or `rich-text`), so the reviewer reads the old\n  shape against the new shape in one glance. This is the right primitive for\n  \"the schema went from X to Y\" or \"the endpoint contract changed like this.\"\n  Do not use `columns` simply to compact or group a list of API endpoints.\n- **`diff` with `mode: \"split\"`** \u2014 for **code**. The split renders the literal\n  removed and added lines side by side. Use it for the actual hunks.\n\nFor UI diffs, wireframes are the visual comparison primitive. Use before/after\nwireframes when the comparison clarifies the change; use after-only or a state\nsequence when that better matches the change. The visual headline must show\nexact placement, realistic chrome, and adequate padding before any abstract\nexplanation. The Wireframe Quality core owns the before/after layout choice \u2014\nthe `columns` renderer keeps narrow surfaces side by side and auto-stacks wide\n`desktop`/`browser` frames vertically; never hand-build a side-by-side\nwireframe layout in `custom-html`. For document-body\ncomparisons, there is no other multi-column primitive \u2014 `columns` plus split\n`diff` are the whole comparison vocabulary. Do not hand-build side-by-side\nlayouts in `custom-html`, and do not stack two `data-model` blocks vertically\nand call it a comparison when `columns` exists to put them side by side.\n\n## Grounding Rule\n\nStructured blocks are **true by construction** only if they are derived from the\nactual changed lines. The `diff`, `data-model`, `api-endpoint`, and `file-tree`\nblocks MUST be built mechanically from the real diff \u2014 real paths, real fields,\nreal method/path, real before/after text \u2014 never inferred, rounded, or invented.\nThe model writes only the prose: the \"why\", the narrative, the risk read. A\nconfidently wrong recap is dangerous in a review context, because a reviewer who\ntrusts the summary may skip the very line the summary got wrong. When the diff\ndoes not contain a fact, leave it out rather than guess; mark anything the model\ninferred (not extracted) as inferred in prose.\n\n## Security\n\n- **Gate visibility.** Recaps of a private repo are org/login-gated \u2014 set the\n  plan's visibility to the owning org or login, never auto-public. A recap can\n  expose unreleased schema, internal endpoints, and architecture; treat it like\n  the source it summarizes.\n- **Never transcribe secrets.** A diff can contain API keys, tokens, webhook\n  URLs, signing secrets, `.env` values, or credential-looking literals. Do not\n  copy any of these into a `diff`, `file-tree` snippet, `api-endpoint`, or prose\n  block \u2014 redact them (`sk-\u2022\u2022\u2022`, `<redacted>`). This mirrors the repo's\n  hardcoded-secret rule: obviously fake placeholders only, never the real value,\n  in any block, caption, or note.\n\n## Bidirectional Loop (Fast-Follow)\n\nBecause a recap is a real, editable plan, the same review loop as forward plans\napplies: a reviewer can annotate any block, and the coding agent reads\n`get-plan-feedback` to drive fixes back into the code \u2014 annotation \u2192 agent \u2192\ndiff, the same close-the-loop flow forward plans use. In v1, recaps are\n**read-only**: they summarize a merged or proposed change for review, and the\nannotate-to-fix loop is a fast-follow, not yet wired. Build the recap so the\nblocks are anchorable and the loop drops in later without restructuring.\n\n## Related Skills\n\n- **visual-plan** \u2014 the canonical command and the source of the shared Wireframe\n  & Canvas and Document Quality cores; a recap follows the same block discipline\n  in reverse.\n- **security** \u2014 data scoping, secret handling, and the hardcoded-secret rule the\n  recap's redaction and visibility gating mirror.\n- **sharing** \u2014 org/login-gated visibility for the plan that holds the recap.\n";
@@ -26,10 +26,6 @@ export declare const BUILT_IN_APP_SKILLS: {
         skillName: string;
         extraSkills: {
             "visual-recap": string;
-            "visual-questions": string;
-            "ui-plan": string;
-            "prototype-plan": string;
-            "plan-design": string;
         };
         manifest: AppSkillManifest;
         skillMarkdown: string;

package/dist/cli/skills.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/cli/skills.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAOH,OAAO,EAKL,KAAK,gBAAgB,EAEtB,MAAM,gBAAgB,CAAC;AAWxB,OAAO,EAAW,KAAK,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAqsBjE,eAAO,MAAM,qBAAqB,u94CAsRjC,CAAC;AAEF,eAAO,MAAM,gBAAgB,i0pCAqK5B,CAAC;AAEF,eAAO,MAAM,uBAAuB,oiOA6JnC,CAAC;AAEF,eAAO,MAAM,oBAAoB,46IA4GhC,CAAC;AAEF,eAAO,MAAM,qBAAqB,sw+BA0UjC,CAAC;AAEF,eAAO,MAAM,yBAAyB,yvMAwIrC,CAAC;AAEF,eAAO,MAAM,mBAAmB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAqP/B,CAAC;AAqFF,KAAK,aAAa,GAAG,MAAM,GAAG,KAAK,GAAG,MAAM,CAAC;AAE7C,MAAM,WAAW,gBAAgB;IAC/B,OAAO,EAAE,aAAa,CAAC;IACvB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,OAAO,CAAC;IACxB,OAAO,CAAC,EAAE,QAAQ,EAAE,CAAC;IACrB,KAAK,EAAE,MAAM,CAAC;IACd,GAAG,EAAE,OAAO,CAAC;IACb,MAAM,EAAE,OAAO,CAAC;IAChB,SAAS,EAAE,OAAO,CAAC;IACnB,YAAY,EAAE,OAAO,CAAC;IACtB,GAAG,EAAE,OAAO,CAAC;IACb;;;;;OAKG;IACH,OAAO,EAAE,OAAO,CAAC;IACjB;;;;OAIG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,OAAO,CAAC;CAC5B;AAED,MAAM,WAAW,eAAe;IAC9B,EAAE,EAAE,MAAM,CAAC;IACX,WAAW,EAAE,MAAM,CAAC;IACpB,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,QAAQ,EAAE,CAAC;IACvB,MAAM,EAAE,OAAO,CAAC;IAChB,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,KAAK,CAAC,EAAE,OAAO,CAAC;IAChB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;IACnB;;;;OAIG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB;;;;OAIG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,mBAAmB,CAAC,EAAE,OAAO,CAAC;CAC/B;AAWD,UAAU,iBAAiB;IACzB,KAAK,CAAC,EAAE,SAAS,GAAG,QAAQ,GAAG,QAAQ,CAAC;CACzC;AAED,UAAU,gBAAgB;IACxB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,OAAO,CAAC;IAC9B,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,KAAK,IAAI,CAAC;IAChC,aAAa,CAAC,EAAE,CACd,OAAO,EAAE,yBAAyB,KAC/B,OAAO,CAAC,QAAQ,EAAE,GAAG,IAAI,CAAC,CAAC;IAChC,YAAY,CAAC,EAAE,CACb,OAAO,EAAE,yBAAyB,KAC/B,OAAO,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,CAAC;IAC9B,UAAU,CAAC,EAAE,CACX,GAAG,EAAE,MAAM,EACX,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,CAAC,EAAE,iBAAiB,KACxB,OAAO,CAAC,MAAM,CAAC,CAAC;IACrB;;;;OAIG;IACH,UAAU,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;CAChD;AAED,UAAU,yBAAyB;IACjC,cAAc,EAAE,QAAQ,EAAE,CAAC;IAC3B,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,QAAQ,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CAClE;AAED,UAAU,yBAAyB;IACjC,cAAc,EAAE,MAAM,EAAE,CAAC;IACzB,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CAChE;AAwJD,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,gBAAgB,CAqEhE;AA2SD,wBAAsB,mBAAmB,CACvC,MAAM,EAAE,gBAAgB,EACxB,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,eAAe,CAAC,CA0L1B;AAgBD,wBAAsB,SAAS,CAC7B,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,IAAI,CAAC,CAkIf"}
+{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/cli/skills.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAOH,OAAO,EAKL,KAAK,gBAAgB,EAEtB,MAAM,gBAAgB,CAAC;AAWxB,OAAO,EAAW,KAAK,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AA0sBjE,eAAO,MAAM,qBAAqB,k25CAsRjC,CAAC;AAEF,eAAO,MAAM,gBAAgB,4sqCAqK5B,CAAC;AAEF,eAAO,MAAM,uBAAuB,oiOA6JnC,CAAC;AAEF,eAAO,MAAM,oBAAoB,46IA4GhC,CAAC;AAEF,eAAO,MAAM,qBAAqB,sw+BA0UjC,CAAC;AAEF,eAAO,MAAM,yBAAyB,yvMAwIrC,CAAC;AAEF,eAAO,MAAM,mBAAmB;;;;;;;;;;;;;;;;;;;;;;;;;CAiM/B,CAAC;AAsEF,KAAK,aAAa,GAAG,MAAM,GAAG,KAAK,GAAG,MAAM,CAAC;AAE7C,MAAM,WAAW,gBAAgB;IAC/B,OAAO,EAAE,aAAa,CAAC;IACvB,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB,MAAM,EAAE,MAAM,CAAC;IACf,cAAc,EAAE,OAAO,CAAC;IACxB,OAAO,CAAC,EAAE,QAAQ,EAAE,CAAC;IACrB,KAAK,EAAE,MAAM,CAAC;IACd,GAAG,EAAE,OAAO,CAAC;IACb,MAAM,EAAE,OAAO,CAAC;IAChB,SAAS,EAAE,OAAO,CAAC;IACnB,YAAY,EAAE,OAAO,CAAC;IACtB,GAAG,EAAE,OAAO,CAAC;IACb;;;;;OAKG;IACH,OAAO,EAAE,OAAO,CAAC;IACjB;;;;OAIG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;IAChB;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,OAAO,CAAC;CAC5B;AAED,MAAM,WAAW,eAAe;IAC9B,EAAE,EAAE,MAAM,CAAC;IACX,WAAW,EAAE,MAAM,CAAC;IACpB,iBAAiB,CAAC,EAAE,MAAM,CAAC;IAC3B,UAAU,EAAE,MAAM,EAAE,CAAC;IACrB,YAAY,EAAE,MAAM,EAAE,CAAC;IACvB,MAAM,EAAE,MAAM,CAAC;IACf,UAAU,EAAE,QAAQ,EAAE,CAAC;IACvB,MAAM,EAAE,OAAO,CAAC;IAChB,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,KAAK,CAAC,EAAE,OAAO,CAAC;IAChB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,OAAO,CAAC,EAAE,MAAM,EAAE,CAAC;IACnB;;;;OAIG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;IACpB;;;;OAIG;IACH,cAAc,CAAC,EAAE,MAAM,CAAC;IACxB;;;;OAIG;IACH,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,mBAAmB,CAAC,EAAE,OAAO,CAAC;CAC/B;AAWD,UAAU,iBAAiB;IACzB,KAAK,CAAC,EAAE,SAAS,GAAG,QAAQ,GAAG,QAAQ,CAAC;CACzC;AAED,UAAU,gBAAgB;IACxB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,OAAO,CAAC;IAC9B,GAAG,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,KAAK,IAAI,CAAC;IAChC,aAAa,CAAC,EAAE,CACd,OAAO,EAAE,yBAAyB,KAC/B,OAAO,CAAC,QAAQ,EAAE,GAAG,IAAI,CAAC,CAAC;IAChC,YAAY,CAAC,EAAE,CACb,OAAO,EAAE,yBAAyB,KAC/B,OAAO,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,CAAC;IAC9B,UAAU,CAAC,EAAE,CACX,GAAG,EAAE,MAAM,EACX,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,CAAC,EAAE,iBAAiB,KACxB,OAAO,CAAC,MAAM,CAAC,CAAC;IACrB;;;;OAIG;IACH,UAAU,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,OAAO,CAAC,IAAI,CAAC,CAAC;CAChD;AAED,UAAU,yBAAyB;IACjC,cAAc,EAAE,QAAQ,EAAE,CAAC;IAC3B,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,QAAQ,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CAClE;AAED,UAAU,yBAAyB;IACjC,cAAc,EAAE,MAAM,EAAE,CAAC;IACzB,OAAO,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CAChE;AAwJD,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,gBAAgB,CAqEhE;AA2SD,wBAAsB,mBAAmB,CACvC,MAAM,EAAE,gBAAgB,EACxB,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,eAAe,CAAC,CA0L1B;AAgBD,wBAAsB,SAAS,CAC7B,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,IAAI,CAAC,CAkIf"}