@agent-native/core 0.37.2 → 0.37.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/skills.d.ts +4 -0
- package/dist/cli/skills.d.ts.map +1 -1
- package/dist/cli/skills.js +766 -537
- package/dist/cli/skills.js.map +1 -1
- package/package.json +1 -1
package/dist/cli/skills.d.ts
CHANGED
|
@@ -4,6 +4,10 @@
|
|
|
4
4
|
* command handles the common "install Assets for my agent" path in one step.
|
|
5
5
|
*/
|
|
6
6
|
import { type ClientId } from "./mcp-config-writers.js";
|
|
7
|
+
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 diagrams, wireframes, mockups, prototypes, annotations,\n 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: an optional pan/zoom wireframe canvas on top and a\nNotion-like technical document below. The user reacts to visuals first and reads\nprose only where it helps.\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 `/visual-questions` to run a visual intake form first. Use `/visualize-plan`\nto turn an existing Codex, Claude Code, Markdown, or pasted plan into a visual\ncompanion.\n\n## When To Use\n\nCreate a visual plan when work is multi-file, ambiguous, long-running, risky, or\nUI-heavy, when architecture / data flow / UI direction / options / open\nquestions would be clearer visually, or when the user needs to react to a\ndirection before you implement.\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- **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; batch\n 2-4 high-leverage questions before finalizing. 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. Call `create-visual-plan` with the title, brief, source, repo path, and\n structured `content` blocks.\n2. Compose the canvas from the kit and write the document with native blocks\n (see the two cores below). Skip the canvas for non-visual work.\n3. Surface the returned Plans link or inline MCP App and ask the user to review.\n4. Call `get-plan-feedback` before editing, after review, after any long pause,\n and before the final response.\n5. 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.\n6. Export with `export-visual-plan` only when the user wants a shareable receipt\n or repo-check-in artifacts.\n\n<!-- SHARED-CORE:wireframe-canvas START -->\n## Wireframe & Canvas Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for how wireframes and the\ncanvas work. Do not paraphrase it per command.\n\n**The renderer owns all visual quality. You emit content, never styling.** Flex\nlayout, fonts, density, spacing, theme, and the hand-drawn wobble all live in\nthe app renderer. Never emit coordinates, CSS, pixel sizes, or raw HTML for a\nwireframe's internals. Your job is to pick a surface, compose real product\ncontent from the kit, and annotate \u2014 nothing else.\n\n**A wireframe block's data is a declarative kit tree, not geometry:**\n\n```json\n{\n \"surface\": \"desktop\",\n \"screen\": [\n { \"el\": \"browserBar\", \"title\": \"tasklist\" },\n { \"el\": \"row\", \"children\": [\n { \"el\": \"sidebar\", \"children\": [\n { \"el\": \"navItem\", \"label\": \"Inbox\", \"count\": 12, \"active\": true },\n { \"el\": \"navItem\", \"label\": \"Today\", \"count\": 4 },\n { \"el\": \"navItem\", \"label\": \"Done\" }\n ] },\n { \"el\": \"main\", \"children\": [\n { \"el\": \"title\", \"text\": \"Today\", \"script\": true },\n { \"el\": \"chips\", \"items\": [\n { \"label\": \"All\", \"active\": true }, { \"label\": \"Active\" }, { \"label\": \"Done\" }\n ] },\n { \"el\": \"section\", \"label\": \"OVERDUE\", \"tone\": \"warn\" },\n { \"el\": \"taskRow\", \"title\": \"Send invoice to Acme Co.\", \"due\": \"Yesterday\", \"dueTone\": \"warn\", \"prio\": 1 },\n { \"el\": \"taskRow\", \"title\": \"Reply to design feedback\", \"due\": \"Today\", \"prio\": 2 }\n ] }\n ] }\n ]\n}\n```\n\nThe renderer maps each node to a flex kit component and applies one whole-frame\nwobble. Layout is always flex: `row`, `col`, `sidebar`, and `main` set the flex\ndirection; everything aligns by construction, so you never get overlap or drift.\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- `desktop`: a full 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- `browser`: a page that needs a browser chrome frame around it.\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**Node vocabulary (`el` values).** Every node is `{ el, ...props, children? }`:\n\n- Layout: `screen`, `row`, `col`, `sidebar`, `main`, `card{children}`,\n `column{title,count?,children}`, `box{children,dashed?}`, `divider`.\n- Chrome: `browserBar{title}`, `statusBar`, `searchBar`, `toolbar`.\n- Navigation: `navItem{label,count?,active?,dot?}`, `tabs`/`chips{items:[{label,active?}]}`,\n `chip{label,active?}`, `pill{label,tone?}`.\n- Content: `title{text,script?}`, `text{value,color?,weight?}`,\n `lines{n?,widths?}`, `section{label,tone?}`,\n `taskRow{title,note?,due?,dueTone?,prio?,done?}`, `kv{rows:[{k,v}]}`,\n `avatar`, `iconSquare{active?}`.\n- Inputs: `field{label?,value?,placeholder?,area?}`, `check{done?,shape?}`,\n `btn{label,solid?,full?}`, `fab{icon?}`.\n\nPut **real product content** in props: real labels, real dates, real counts,\nreal button text grounded in the actual screen or component you read. Use\n`lines`/`text` (with no `value`) only for genuine placeholder body copy \u2014 never\nfill a screen with gray placeholder bars. Buttons (`btn`, `fab`) must read as\nactionable controls.\n\n**Default crisp.** Sketchiness is a low default (a subtle single wobble over the\nwhole frame), not a heavy scribble. Do not ask for or assume a heavy sketch\nlook.\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**Patching.** Edit one wireframe node, canvas annotation, or block with targeted `contentPatches`\n(for example `update-wireframe-node`, `update-block`, `replace-blocks`) 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.\n\n**Legacy imports only.** Old or imported plans may carry coordinate-based\nregions or a full standalone HTML document; the renderer still displays them.\nNever emit geometry, regions, or a standalone HTML document for a new plan \u2014\ncompose the kit tree instead.\n<!-- SHARED-CORE:wireframe-canvas END -->\n\n<!-- SHARED-CORE:document-quality START -->\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for the document below the\ncanvas. Do not paraphrase it per command.\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**Canvas and document never duplicate each other.** The UI story lives on the\ncanvas with on-canvas annotations; the document carries the technical depth the\ncanvas cannot show \u2014 concrete file/symbol maps, API and data contracts, code\nsnippets, migration or implementation phases, risks, and validation. Repeat a\nwireframe in the document only for a genuinely new detail view or comparison.\nSkip the canvas entirely for non-visual work and write a clean rich document.\n\n**Use the right block, and make it carry substance:**\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `implementation-map` / `code-tabs` for the file map: file path, the\n symbols/components to touch, the reason, risk/coordination notes, and a\n concise syntax-highlighted snippet of the code shape \u2014 never the whole file,\n never a prose-only file list.\n- `decision` for two or three option cards with consequences. These are static\n records; do not style them like clickable tabs or chips unless the renderer\n truly supports changing the selection.\n- `diagram` for architecture, sequence, data-flow, dependency, or state\n relationships, only when it clarifies something real. Labels must not overlap\n nodes, connectors, or each 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 are callouts, not buried prose.** Surface anything unresolved in\na dedicated open-questions / needs-clarification block. Never put a\nquestions/decisions wall inside the plan narrative.\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 placeholder,\ndensity demo, or proof that custom HTML works. Prefer the native blocks; they\ncover real plans.\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<!-- SHARED-CORE:document-quality END -->\n\n<!-- SHARED-CORE:exemplar START -->\n## Good vs. Bad Exemplar\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard\ncomposed from the kit \u2014 a sidebar of real `navItem`s (`Inbox 12`, `Today 4`,\n`Done`), a `main` with a scripted `title`, real `chips`, a `section` labeled\n`OVERDUE`, and `taskRow`s carrying real titles, due dates, and priorities \u2014 one\nsubtle whole-frame wobble, correct desktop footprint, and plain-text designer\nnotes spaced off the frames pointing only at the controls that need explanation.\nBelow it, a Claude/Codex-grade document: objective and done-criteria, an\n`implementation-map` naming the real components and actions with short\nhighlighted snippets, a `decision` card weighing two real approaches, and a\nvalidation step \u2014 none of it repeating the canvas. This is the bar.\n\n**BAD.** Empty coordinate boxes placed by `x/y/width/height`, gray placeholder\nbars \"insinuating\" text, crisp double-bordered rectangles or a heavy scribble, a\nforced desktop + mobile pair for a popover, floating bordered annotation cards\nhugging the frames, and a marketing-style document with a hero heading and value\nprops that just restates what the canvas already shows. Never produce this.\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-visual-plan`: start one structured visual plan per agent task/run.\n- `create-ui-plan`: start a UI-first plan when the work is primarily product UI.\n- `create-visual-questions`: run a visual intake form before planning.\n- `visualize-plan`: build a visual companion from an existing text plan.\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.\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\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`. Do\nnot put shared secrets in skill files.\n";
|
|
8
|
+
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 states, 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 `/visual-questions` first when the user should answer intake\nquestions, and `/visualize-plan` when a text plan already exists.\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; batch 2-4 before finalizing. Otherwise state\n 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. Call `create-ui-plan` with a UI-specific title, brief, source, repo path, and\n structured `content`. The canvas comes first, the document second.\n2. 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.\n3. Continue below as a concise technical document \u2014 not a second copy of the\n canvas \u2014 covering concrete files, contracts, phases, risks, and validation.\n4. Call `get-plan-feedback` before implementation, after review, after a long\n pause, and before the final response. Apply changes with `update-visual-plan`,\n preferring `contentPatches` for one frame, annotation, node, tab, or block. When the user\n wants source-control friendly edits, use `patch-visual-plan-source` against\n 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<!-- SHARED-CORE:wireframe-canvas START -->\n## Wireframe & Canvas Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for how wireframes and the\ncanvas work. Do not paraphrase it per command.\n\n**The renderer owns all visual quality. You emit content, never styling.** Flex\nlayout, fonts, density, spacing, theme, and the hand-drawn wobble all live in\nthe app renderer. Never emit coordinates, CSS, pixel sizes, or raw HTML for a\nwireframe's internals. Your job is to pick a surface, compose real product\ncontent from the kit, and annotate \u2014 nothing else.\n\n**A wireframe block's data is a declarative kit tree, not geometry:**\n\n```json\n{\n \"surface\": \"desktop\",\n \"screen\": [\n { \"el\": \"browserBar\", \"title\": \"tasklist\" },\n { \"el\": \"row\", \"children\": [\n { \"el\": \"sidebar\", \"children\": [\n { \"el\": \"navItem\", \"label\": \"Inbox\", \"count\": 12, \"active\": true },\n { \"el\": \"navItem\", \"label\": \"Today\", \"count\": 4 },\n { \"el\": \"navItem\", \"label\": \"Done\" }\n ] },\n { \"el\": \"main\", \"children\": [\n { \"el\": \"title\", \"text\": \"Today\", \"script\": true },\n { \"el\": \"chips\", \"items\": [\n { \"label\": \"All\", \"active\": true }, { \"label\": \"Active\" }, { \"label\": \"Done\" }\n ] },\n { \"el\": \"section\", \"label\": \"OVERDUE\", \"tone\": \"warn\" },\n { \"el\": \"taskRow\", \"title\": \"Send invoice to Acme Co.\", \"due\": \"Yesterday\", \"dueTone\": \"warn\", \"prio\": 1 },\n { \"el\": \"taskRow\", \"title\": \"Reply to design feedback\", \"due\": \"Today\", \"prio\": 2 }\n ] }\n ] }\n ]\n}\n```\n\nThe renderer maps each node to a flex kit component and applies one whole-frame\nwobble. Layout is always flex: `row`, `col`, `sidebar`, and `main` set the flex\ndirection; everything aligns by construction, so you never get overlap or drift.\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- `desktop`: a full 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- `browser`: a page that needs a browser chrome frame around it.\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**Node vocabulary (`el` values).** Every node is `{ el, ...props, children? }`:\n\n- Layout: `screen`, `row`, `col`, `sidebar`, `main`, `card{children}`,\n `column{title,count?,children}`, `box{children,dashed?}`, `divider`.\n- Chrome: `browserBar{title}`, `statusBar`, `searchBar`, `toolbar`.\n- Navigation: `navItem{label,count?,active?,dot?}`, `tabs`/`chips{items:[{label,active?}]}`,\n `chip{label,active?}`, `pill{label,tone?}`.\n- Content: `title{text,script?}`, `text{value,color?,weight?}`,\n `lines{n?,widths?}`, `section{label,tone?}`,\n `taskRow{title,note?,due?,dueTone?,prio?,done?}`, `kv{rows:[{k,v}]}`,\n `avatar`, `iconSquare{active?}`.\n- Inputs: `field{label?,value?,placeholder?,area?}`, `check{done?,shape?}`,\n `btn{label,solid?,full?}`, `fab{icon?}`.\n\nPut **real product content** in props: real labels, real dates, real counts,\nreal button text grounded in the actual screen or component you read. Use\n`lines`/`text` (with no `value`) only for genuine placeholder body copy \u2014 never\nfill a screen with gray placeholder bars. Buttons (`btn`, `fab`) must read as\nactionable controls.\n\n**Default crisp.** Sketchiness is a low default (a subtle single wobble over the\nwhole frame), not a heavy scribble. Do not ask for or assume a heavy sketch\nlook.\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**Patching.** Edit one wireframe node, canvas annotation, or block with targeted `contentPatches`\n(for example `update-wireframe-node`, `update-block`, `replace-blocks`) 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.\n\n**Legacy imports only.** Old or imported plans may carry coordinate-based\nregions or a full standalone HTML document; the renderer still displays them.\nNever emit geometry, regions, or a standalone HTML document for a new plan \u2014\ncompose the kit tree instead.\n<!-- SHARED-CORE:wireframe-canvas END -->\n\n<!-- SHARED-CORE:document-quality START -->\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for the document below the\ncanvas. Do not paraphrase it per command.\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**Canvas and document never duplicate each other.** The UI story lives on the\ncanvas with on-canvas annotations; the document carries the technical depth the\ncanvas cannot show \u2014 concrete file/symbol maps, API and data contracts, code\nsnippets, migration or implementation phases, risks, and validation. Repeat a\nwireframe in the document only for a genuinely new detail view or comparison.\nSkip the canvas entirely for non-visual work and write a clean rich document.\n\n**Use the right block, and make it carry substance:**\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `implementation-map` / `code-tabs` for the file map: file path, the\n symbols/components to touch, the reason, risk/coordination notes, and a\n concise syntax-highlighted snippet of the code shape \u2014 never the whole file,\n never a prose-only file list.\n- `decision` for two or three option cards with consequences. These are static\n records; do not style them like clickable tabs or chips unless the renderer\n truly supports changing the selection.\n- `diagram` for architecture, sequence, data-flow, dependency, or state\n relationships, only when it clarifies something real. Labels must not overlap\n nodes, connectors, or each 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 are callouts, not buried prose.** Surface anything unresolved in\na dedicated open-questions / needs-clarification block. Never put a\nquestions/decisions wall inside the plan narrative.\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 placeholder,\ndensity demo, or proof that custom HTML works. Prefer the native blocks; they\ncover real plans.\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<!-- SHARED-CORE:document-quality END -->\n\n<!-- SHARED-CORE:exemplar START -->\n## Good vs. Bad Exemplar\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard\ncomposed from the kit \u2014 a sidebar of real `navItem`s (`Inbox 12`, `Today 4`,\n`Done`), a `main` with a scripted `title`, real `chips`, a `section` labeled\n`OVERDUE`, and `taskRow`s carrying real titles, due dates, and priorities \u2014 one\nsubtle whole-frame wobble, correct desktop footprint, and plain-text designer\nnotes spaced off the frames pointing only at the controls that need explanation.\nBelow it, a Claude/Codex-grade document: objective and done-criteria, an\n`implementation-map` naming the real components and actions with short\nhighlighted snippets, a `decision` card weighing two real approaches, and a\nvalidation step \u2014 none of it repeating the canvas. This is the bar.\n\n**BAD.** Empty coordinate boxes placed by `x/y/width/height`, gray placeholder\nbars \"insinuating\" text, crisp double-bordered rectangles or a heavy scribble, a\nforced desktop + mobile pair for a popover, floating bordered annotation cards\nhugging the frames, and a marketing-style document with a hero heading and value\nprops that just restates what the canvas already shows. Never produce this.\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `create-ui-plan`: create the UI-first structured visual plan.\n- `create-visual-questions`: run a visual intake form before the UI plan.\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.\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\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`.\n";
|
|
9
|
+
export declare const VISUAL_QUESTIONS_SKILL_MD = "---\nname: visual-questions\ndescription: >-\n Use Agent-Native Plans to ask rich visual intake questions before creating a\n UI plan or visual plan.\nmetadata:\n visibility: both\n---\n\n# Visual Questions\n\nUse `/visual-questions` when the next best step is not a plan yet, but a\nreviewable visual intake: single-choice chips, multi-select chips, freeform\nnotes, mockup choices, sketch diagrams, and a generated answer summary that feeds\nthe next planning prompt. It composes with `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`.\n\n## When To Use\n\n- The user asks to be shown options before the agent writes a plan.\n- UI direction, form factor, layout model, feature set, or visual style is fuzzy\n enough that 2-6 answers would materially change the plan.\n- The user would benefit from choosing between visual mockups or diagrams rather\n than answering text-only prompts.\n\nGate hard: skip this for tiny, unambiguous changes. If the agent can reasonably\ninfer the answer, prefer `/ui-plan` or `/visual-plan` directly and put\nassumptions in the plan.\n\n## Workflow\n\n1. Call `create-visual-questions` with a clear title, brief, source, and repo\n path when known.\n2. Omit `questions` for the default UI intake. Provide a custom `questions` array\n only when the task has domain-specific choices.\n3. Surface the returned Plans link and ask the user to answer visually.\n4. The generated summary drives the next step: `create-ui-plan` for UI flows,\n `create-visual-plan` for general plans, `visualize-plan` when a text plan\n already exists, or `update-visual-plan` with targeted `contentPatches` to fold\n answers into an active plan.\n5. If the user leaves comments, call `get-plan-feedback` before using the answers.\n\n## Question Types\n\nSupported `questions` entries:\n\n- `single`: chip group where one option wins.\n- `multi`: chip group where multiple options can be selected.\n- `freeform`: textarea for constraints, inspirations, or things to avoid.\n- `visual`: visual options with sketch previews \u2014 use for layout direction, flow\n depth, surface choice, or diagram choices.\n\nEach option can include `label`, `value`, `description`, `recommended`,\n`preview`, and `bullets`. Valid `preview` values match the wireframe surfaces:\n`desktop`, `mobile`, `popover`, `panel`, `component`, `split`, `flow`, and\n`diagram`. Pick the preview that matches the real footprint \u2014 do not offer a\ndesktop/mobile pair for a popover, panel, or component.\n\n## Quality Bar\n\n- Ask only decision-changing questions. A beautiful form with low-value questions\n is still friction.\n- Prefer visible, answerable options over abstract prose.\n- Use visual tabs when users need to compare layout or flow shapes.\n- Keep the output calm and document-like, not a landing page.\n- The generated answer summary is not the final plan; it is the intake prompt for\n the next agent step.\n\n## Tool Guidance\n\n- `create-visual-questions`: create the interactive intake plan.\n- `get-visual-plan`: inspect the current visual question plan.\n- `get-plan-feedback`: read comments before creating or updating the next plan.\n- `create-ui-plan`: create a UI-first plan from the answers.\n- `create-visual-plan`: create a general visual plan from the answers.\n- `visualize-plan`: enrich an existing text plan after answers are gathered.\n- `export-visual-plan`: export answer plans as HTML, Markdown fallback,\n structured JSON, and MDX files when the intake needs to be checked into a repo.\n- `read-visual-plan-source` / `patch-visual-plan-source`: inspect or patch the\n MDX source if another agent is operating from checked-in plan files.\n\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`.\n";
|
|
10
|
+
export declare const VISUALIZE_PLAN_SKILL_MD = "---\nname: visualize-plan\ndescription: >-\n Convert an existing Codex, Claude Code, Markdown, or pasted plan into an\n Agent-Native Plans visual companion with diagrams, wireframes, annotations, and\n feedback.\nmetadata:\n visibility: exported\n---\n\n# Visualize Plan\n\nUse `/visualize-plan` when a plan already exists and the user wants it easier to\nreview. The native Codex or Claude Code plan can stay where it is; Agent-Native\nPlans creates a structured visual companion beside it \u2014 diagrams, wireframes,\nstate sketches, option cards, and comment prompts instead of a wall of text. It\nstill reads like a plan, not a marketing page.\n\n## Plan Discipline\n\n- **Gate hard.** A visual companion is worth it only when the source plan is\n long, risky, or hard to react to as text. If the source plan is for trivial,\n unambiguous work, skip the companion and just implement.\n- **Stay grounded and read-only.** Preserve the source plan's intent, do not\n invent codebase facts, and label anything inferred as inferred. Make no source\n edits while building or reviewing the companion.\n- **The companion is the approval gate.** Ask the user to review and approve the\n direction before you write code, and name which files/areas the work touches.\n Carry unresolved assumptions and open questions into a clear block instead of\n guessing silently.\n\n## Workflow\n\n1. Gather the existing plan text from the user's paste, a referenced file, or\n recent visible agent context. Do not invent the source plan. If no plan text\n exists and the work is UI-heavy, use `/ui-plan` instead.\n2. Call `visualize-plan` with `planText`, `title`, `brief`, `source`, and\n `repoPath` when available.\n3. Surface the returned Plans link or inline MCP App.\n4. Enrich the import with `update-visual-plan` (prefer targeted `contentPatches`):\n add a canvas with wireframes for user-visible UI, diagrams for architecture or\n data flow, option cards for real tradeoffs, and explicit open questions. Apply\n the two cores below \u2014 the companion must meet the same quality bar as a fresh\n plan, not be a thinner ruleset. Label inferred visuals as inferred. When the\n user wants source-control friendly edits, use `patch-visual-plan-source`\n against the MDX files instead of regenerating the plan.\n5. Ask the user to react, then call `get-plan-feedback` before implementing,\n after review, and before the final response.\n6. Treat imported text as source material. The structured visual plan and\n comments are the review surface; HTML is the export receipt. Do not replace a\n native plan unless the user asks.\n\n<!-- SHARED-CORE:wireframe-canvas START -->\n## Wireframe & Canvas Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for how wireframes and the\ncanvas work. Do not paraphrase it per command.\n\n**The renderer owns all visual quality. You emit content, never styling.** Flex\nlayout, fonts, density, spacing, theme, and the hand-drawn wobble all live in\nthe app renderer. Never emit coordinates, CSS, pixel sizes, or raw HTML for a\nwireframe's internals. Your job is to pick a surface, compose real product\ncontent from the kit, and annotate \u2014 nothing else.\n\n**A wireframe block's data is a declarative kit tree, not geometry:**\n\n```json\n{\n \"surface\": \"desktop\",\n \"screen\": [\n { \"el\": \"browserBar\", \"title\": \"tasklist\" },\n { \"el\": \"row\", \"children\": [\n { \"el\": \"sidebar\", \"children\": [\n { \"el\": \"navItem\", \"label\": \"Inbox\", \"count\": 12, \"active\": true },\n { \"el\": \"navItem\", \"label\": \"Today\", \"count\": 4 },\n { \"el\": \"navItem\", \"label\": \"Done\" }\n ] },\n { \"el\": \"main\", \"children\": [\n { \"el\": \"title\", \"text\": \"Today\", \"script\": true },\n { \"el\": \"chips\", \"items\": [\n { \"label\": \"All\", \"active\": true }, { \"label\": \"Active\" }, { \"label\": \"Done\" }\n ] },\n { \"el\": \"section\", \"label\": \"OVERDUE\", \"tone\": \"warn\" },\n { \"el\": \"taskRow\", \"title\": \"Send invoice to Acme Co.\", \"due\": \"Yesterday\", \"dueTone\": \"warn\", \"prio\": 1 },\n { \"el\": \"taskRow\", \"title\": \"Reply to design feedback\", \"due\": \"Today\", \"prio\": 2 }\n ] }\n ] }\n ]\n}\n```\n\nThe renderer maps each node to a flex kit component and applies one whole-frame\nwobble. Layout is always flex: `row`, `col`, `sidebar`, and `main` set the flex\ndirection; everything aligns by construction, so you never get overlap or drift.\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- `desktop`: a full 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- `browser`: a page that needs a browser chrome frame around it.\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**Node vocabulary (`el` values).** Every node is `{ el, ...props, children? }`:\n\n- Layout: `screen`, `row`, `col`, `sidebar`, `main`, `card{children}`,\n `column{title,count?,children}`, `box{children,dashed?}`, `divider`.\n- Chrome: `browserBar{title}`, `statusBar`, `searchBar`, `toolbar`.\n- Navigation: `navItem{label,count?,active?,dot?}`, `tabs`/`chips{items:[{label,active?}]}`,\n `chip{label,active?}`, `pill{label,tone?}`.\n- Content: `title{text,script?}`, `text{value,color?,weight?}`,\n `lines{n?,widths?}`, `section{label,tone?}`,\n `taskRow{title,note?,due?,dueTone?,prio?,done?}`, `kv{rows:[{k,v}]}`,\n `avatar`, `iconSquare{active?}`.\n- Inputs: `field{label?,value?,placeholder?,area?}`, `check{done?,shape?}`,\n `btn{label,solid?,full?}`, `fab{icon?}`.\n\nPut **real product content** in props: real labels, real dates, real counts,\nreal button text grounded in the actual screen or component you read. Use\n`lines`/`text` (with no `value`) only for genuine placeholder body copy \u2014 never\nfill a screen with gray placeholder bars. Buttons (`btn`, `fab`) must read as\nactionable controls.\n\n**Default crisp.** Sketchiness is a low default (a subtle single wobble over the\nwhole frame), not a heavy scribble. Do not ask for or assume a heavy sketch\nlook.\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**Patching.** Edit one wireframe node, canvas annotation, or block with targeted `contentPatches`\n(for example `update-wireframe-node`, `update-block`, `replace-blocks`) 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.\n\n**Legacy imports only.** Old or imported plans may carry coordinate-based\nregions or a full standalone HTML document; the renderer still displays them.\nNever emit geometry, regions, or a standalone HTML document for a new plan \u2014\ncompose the kit tree instead.\n<!-- SHARED-CORE:wireframe-canvas END -->\n\n<!-- SHARED-CORE:document-quality START -->\n## Document Quality Core\n\nThis section is shared, word for word, by `/visual-plan`, `/ui-plan`, and\n`/visualize-plan`. It is the single source of truth for the document below the\ncanvas. Do not paraphrase it per command.\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**Canvas and document never duplicate each other.** The UI story lives on the\ncanvas with on-canvas annotations; the document carries the technical depth the\ncanvas cannot show \u2014 concrete file/symbol maps, API and data contracts, code\nsnippets, migration or implementation phases, risks, and validation. Repeat a\nwireframe in the document only for a genuinely new detail view or comparison.\nSkip the canvas entirely for non-visual work and write a clean rich document.\n\n**Use the right block, and make it carry substance:**\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `implementation-map` / `code-tabs` for the file map: file path, the\n symbols/components to touch, the reason, risk/coordination notes, and a\n concise syntax-highlighted snippet of the code shape \u2014 never the whole file,\n never a prose-only file list.\n- `decision` for two or three option cards with consequences. These are static\n records; do not style them like clickable tabs or chips unless the renderer\n truly supports changing the selection.\n- `diagram` for architecture, sequence, data-flow, dependency, or state\n relationships, only when it clarifies something real. Labels must not overlap\n nodes, connectors, or each 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 are callouts, not buried prose.** Surface anything unresolved in\na dedicated open-questions / needs-clarification block. Never put a\nquestions/decisions wall inside the plan narrative.\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 placeholder,\ndensity demo, or proof that custom HTML works. Prefer the native blocks; they\ncover real plans.\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<!-- SHARED-CORE:document-quality END -->\n\n<!-- SHARED-CORE:exemplar START -->\n## Good vs. Bad Exemplar\n\n**GOOD.** A `/ui-plan` for a todo app: a canvas with a `desktop` artboard\ncomposed from the kit \u2014 a sidebar of real `navItem`s (`Inbox 12`, `Today 4`,\n`Done`), a `main` with a scripted `title`, real `chips`, a `section` labeled\n`OVERDUE`, and `taskRow`s carrying real titles, due dates, and priorities \u2014 one\nsubtle whole-frame wobble, correct desktop footprint, and plain-text designer\nnotes spaced off the frames pointing only at the controls that need explanation.\nBelow it, a Claude/Codex-grade document: objective and done-criteria, an\n`implementation-map` naming the real components and actions with short\nhighlighted snippets, a `decision` card weighing two real approaches, and a\nvalidation step \u2014 none of it repeating the canvas. This is the bar.\n\n**BAD.** Empty coordinate boxes placed by `x/y/width/height`, gray placeholder\nbars \"insinuating\" text, crisp double-bordered rectangles or a heavy scribble, a\nforced desktop + mobile pair for a popover, floating bordered annotation cards\nhugging the frames, and a marketing-style document with a hero heading and value\nprops that just restates what the canvas already shows. Never produce this.\n<!-- SHARED-CORE:exemplar END -->\n\n## Tool Guidance\n\n- `visualize-plan`: create the visual companion from the existing text plan.\n- `update-visual-plan`: enrich the import; prefer targeted `contentPatches` over\n replacing the whole content.\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.\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\nHosted default: connect `https://plan.agent-native.com/_agent-native/mcp`.\n";
|
|
7
11
|
type SkillsCommand = "list" | "add" | "help";
|
|
8
12
|
export interface ParsedSkillsArgs {
|
|
9
13
|
command: SkillsCommand;
|
package/dist/cli/skills.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/cli/skills.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAwBH,OAAO,EAAW,KAAK,QAAQ,EAAE,MAAM,yBAAyB,CAAC;
|
|
1
|
+
{"version":3,"file":"skills.d.ts","sourceRoot":"","sources":["../../src/cli/skills.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAwBH,OAAO,EAAW,KAAK,QAAQ,EAAE,MAAM,yBAAyB,CAAC;AAmLjE,eAAO,MAAM,qBAAqB,k0eA2RjC,CAAC;AAEF,eAAO,MAAM,gBAAgB,w6cA4Q5B,CAAC;AAEF,eAAO,MAAM,yBAAyB,krHAkFrC,CAAC;AAEF,eAAO,MAAM,uBAAuB,i2bAkQnC,CAAC;AAkSF,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;;;;OAIG;IACH,MAAM,CAAC,EAAE,MAAM,CAAC;CACjB;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;CACpB;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;CACtB;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,CAgEhE;AAyND,wBAAsB,mBAAmB,CACvC,MAAM,EAAE,gBAAgB,EACxB,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,eAAe,CAAC,CAiJ1B;AAgBD,wBAAsB,SAAS,CAC7B,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE,gBAAqB,GAC7B,OAAO,CAAC,IAAI,CAAC,CAyGf"}
|