@agent-native/core 0.97.0 → 0.98.0

package/dist/cli/skills-content/document-quality.js

@@ -0,0 +1,195 @@
+export const DOCUMENT_QUALITY_CORE = `<!-- SHARED-CORE:document-quality START -->
+
+**The document is a serious technical plan, not marketing.** Write it the way a
+strong Claude or Codex implementation plan reads: outcome-first, prose-first,
+self-contained, and specific. State the objective and what "done" means, the
+scope and non-goals, the proposed approach with the key decisions and their
+rationale, ordered steps that name real files, symbols, actions, and data
+shapes, the risks, and a closing verification step (tests, build, or a checkable
+behavior). Replace vague prose with specifics; never ship a step like "make it
+work." No hero art, gradients, logos, nav bars, slogans, value props, giant
+landing-page headings, or marketing cards unless the user explicitly asks.
+
+**Every published plan must stand alone.** Even when the agent is revising an
+existing plan, the output is a plan to do the work, not a changelog of the
+conversation. Do not write phrases like "preserve the previous plan", "do not
+drop the old idea", "as discussed above", "this revision", "unlike the prior
+version", or "correction from the earlier plan". Fold the right decisions into
+the plan as normal objective, architecture, scope, and roadmap prose. A reviewer
+who opens the plan from a link with no chat history should understand it. Avoid
+negative framing that only makes sense against absent context ("not the old
+mode", "not just X") unless the contrast is defined in the plan and genuinely
+helps; state the positive model directly.
+
+**Make abstract plans instantly legible.** If the idea is broad, strategic, or
+intended for a third-party reviewer, put one concrete product snapshot near the
+top before dense architecture, mode tables, manifests, or roadmaps. For
+UI-capable concepts, that snapshot is usually a top-canvas app state plus a
+short paragraph that says what the user sees and what changes under the hood.
+Then put mechanics, data flow, sync boundaries, and implementation detail in
+separate diagrams or document sections.
+
+**Preserve the user's level of abstraction.** A motivating use case is not
+automatically the architecture. When the prompt describes a broader framework,
+product mode, or reusable primitive, separate the reusable core from specific
+apps, providers, customers, scripts, or launch examples. Use the concrete
+example to make the plan understandable, then make clear which parts are core,
+which are app-specific adapters, and which are future examples.
+
+**When top visuals exist, they and the document never duplicate each other.**
+For UI work, the UI story lives in the top visual surface: canvas artboards for
+static inspection, plus prototype tabs when the flow should be functional. The
+document carries the technical depth the visuals cannot show — concrete
+file/symbol maps, API and data contracts, code snippets, migration or
+implementation phases, risks, and validation. For architecture/code reviews,
+invert that: the document is the visual surface, and each recommendation
+carries its own nearby inline \`diagram\` / \`data-model\` block plus file
+evidence (the \`diagram\` bullet below owns how to author those diagrams).
+Repeat a wireframe in the document only for a genuinely new detail view or
+comparison. Skip the visual surface entirely for non-visual work and write a
+clean rich document. For a simple binary UI visual choice, show the two
+directions in the canvas only; do not repeat the same options as body
+wireframes or prose. Put the actual choice in the bottom "Open Questions" form.
+
+**Use the right block, and make it carry substance.** For the authoritative,
+machine-checked list of block types and their data schemas, call \`get-plan-blocks\`
+— it returns the live registry vocabulary (type, MDX tag, placement, key fields)
+so you never emit a block the editor cannot render or round-trip:
+
+- \`rich-text\` for plan prose with real bold/italic/code/links and nested lists.
+- \`annotated-code\` for the file map: when a load-bearing file is worth
+  highlighting, prefer the annotated walkthrough over a bare \`code\` block — carry
+  the real, syntax-highlighted code AND anchor short margin notes to the lines
+  that actually change (the new action, the changed schema, the wiring point), so
+  the reader sees what matters and why instead of code for code's sake. Each
+  annotation is \`{ lines: "12" | "12-18"; label?; note }\`; keep a few high-signal
+  notes per file, not one per line. Highlight only the files worth reading; never
+  an exhaustive list of every touched file, and never a prose-only description of
+  a file. Drop to a plain \`code\` block only for a throwaway snippet with nothing
+  to call out. When more than one file matters, group the blocks in a vertical
+  \`tabs\` block (the standard tab primitive) rather than a bespoke container. If
+  the exact code is unknown, show the smallest plausible planned shape or a
+  commented stub naming what to fill in. (\`code-tabs\` and \`implementation-map\`
+  are legacy: their renderers stay for old plans, but do not author new ones.)
+- For a decision: if the reviewer must still pick between a genuinely-open
+  either/or, put it in the bottom Open Questions \`question-form\` as a \`single\`
+  question — one option per real alternative, each with a short detail and
+  \`recommended: true\` on the one you would choose; do not also restate the same
+  choice elsewhere. If you have already committed to an approach, state it as
+  settled prose or a \`callout\` with \`tone="decision"\`, optionally with a
+  \`columns\` block for a side-by-side comparison of the options you weighed — not
+  as a confusing mid-document form for a question you have already answered.
+- \`columns\` for side-by-side before/after or current/target comparisons where
+  each side needs real nested blocks; label the columns clearly and avoid
+  stacking comparison blocks vertically when parallel reading is the point.
+- \`diagram\` for two-dimensional architecture, dependency, data-flow, or state
+  relationships, only when it clarifies something real. Prefer standard
+  two-dimensional layouts — paired before/after panels, layered diagrams,
+  swimlanes, dependency maps, matrices, or grouped regions; do not default to
+  left-to-right chains, and use a line only when the relationship is truly a
+  sequence. Do not use a body \`diagram\` as the primary artifact for a requested
+  product canvas, light storyboard, UI flow, screen flow, or wireframe; those
+  belong in the top canvas as artboards with \`Screen\` wireframes first. Use
+  diagrams below that canvas only for architecture, data flow, or implementation
+  mechanics. For architecture/code
+  diagrams, prefer \`data.html\` / \`data.css\` with semantic HTML and inline SVG so
+  the diagram can use panels, layers, matrices, arrows, annotations, and
+  responsive layout directly. Author diagram HTML with renderer-owned primitives
+  like \`.diagram-panel\`, \`.diagram-card\`, \`.diagram-node\`, \`.diagram-box\`,
+  \`.diagram-pill\`, \`.diagram-muted\`, and \`[data-rough]\`; they map to the plan's
+  Tailwind theme variables through \`--wf-ink\`, \`--wf-muted\`, \`--wf-line\`,
+  \`--wf-paper\`, \`--wf-card\`, \`--wf-accent\`, \`--wf-accent-soft\`, \`--wf-warn\`, and
+  \`--wf-ok\`, and switch to Excalifont plus rough.js outlines in sketchy mode. Do not
+  set \`font-family\` and do not hard-code hex, rgb, or hsl colors in diagram HTML
+  or CSS. Choose the outer \`frame\` intentionally: use \`show\` when the diagram
+  stands alone in a recap, comparison, or prose section; use \`hide\` when the
+  diagram sits inside docs chrome, columns, tabs, cards, a canvas surface, or
+  already has visible \`.diagram-panel\` / \`.diagram-box\` structure. Leave room
+  for the sketch font: keep labels short, give nodes generous width, and place
+  boundary/annotation labels in unused space instead of over nodes; labels must
+  not overlap nodes, connectors, or each other. For small text/SVG changes to an
+  existing HTML diagram, use \`patch-diagram-html\` with a unique
+  \`find\`/\`replace\` snippet instead of resending the whole \`data.html\` string.
+  Use legacy \`nodes\` / \`edges\` only for small previews or truly
+  sequential flows. In architecture/code plans, prefer a repeated section rhythm:
+  recommendation title, confidence and category badges, code-path evidence, a
+  local before/after or current/target spatial diagram, then concise
+  Problem/Solution/Why text.
+- \`tabs\` for multiple states, directions, or comparisons. A tab that reveals
+  only prose usually means the plan is under-specified — include a relevant
+  visual unless the tab is intentionally document-only.
+- \`table\`, \`checklist\`, \`callout\` for scannable structure.
+
+**Open questions live at the bottom as a form when answers would change the
+plan.** Surface answerable unresolved decisions in a final \`question-form\`
+block titled "Open Questions" so the renderer presents it as a distinct section.
+That bottom form is the ONLY place that enumerates the open questions: never add
+a second "Open Questions" heading, list, or recap of the same questions earlier
+in the document. A one-line pointer in the overview prose ("a few decisions are
+still open — see Open Questions below") is fine, but do not reproduce the
+question list or a parallel questions/decisions section above it.
+Use \`single\` or \`multi\` for clear choices, \`freeform\` for constraints,
+\`recommended: true\` for the default you would pick, and option \`wireframe\` /
+\`diagram\` previews only when the options are not already visible in the top
+canvas. \`single\` and \`multi\` questions always render a write-in field so a
+reviewer can answer with a custom option — never add an explicit "Other" option
+yourself; set \`allowOther: false\` only when a free-text answer makes no sense.
+Keep non-answerable assumptions or risks as concise \`callout\` blocks in
+the relevant section. Never bury a questions/decisions wall inside the plan
+narrative, and never ask the same question twice.
+
+For complex plans, do not end without an open-question audit. If architecture,
+scope, UX, data shape, rollout, provider mapping, or ownership still depends on
+a choice, either commit to a recommendation with rationale or add it to the
+bottom form with a recommended default. A complex plan with no open questions is
+fine only when every meaningful decision has been explicitly made.
+
+**Verification must exercise the real workflow.** The final verification section
+should go beyond typecheck/unit tests when the plan changes UI, local files,
+sync, providers, browser behavior, or multi-app flows. Include at least one
+end-to-end smoke that matches the user journey, such as a fresh repo/folder,
+real manifest or data fixture, browser interaction, save/sync action, and an
+on-disk or database assertion. Name the command or manual browser path when it
+is known.
+
+**\`custom-html\` is a bounded escape hatch only** — a single complete fragment
+inside a block, never \`html\`/\`head\`/\`body\`/\`script\` tags, never a generic
+placeholder, density demo, or proof that custom HTML works. Prefer the native
+blocks for normal plans. For architecture/code reviews, use \`diagram\`
+\`data.html\` / \`data.css\` for rich local HTML/SVG diagrams instead of
+\`custom-html\`. For UI/product work, \`custom-html\` is never the primary home for a
+requested mockup, UI state, or visual comparison. If UI fidelity requires
+HTML/CSS, image capture, or real React/CSS, the product fix is canvas support
+for that artifact type, not moving the mockup into the document.
+When \`custom-html\` is genuinely needed, author it against the sandbox-provided
+theme tokens (\`--wf-paper\`, \`--wf-card\`, \`--wf-ink\`, \`--wf-muted\`,
+\`--wf-line\`, \`--wf-radius\`, and the matching \`--plan-*\` aliases). Do not hardcode
+hex/rgb/hsl light palettes such as white cards with dark ink; the same fragment
+must read in dark mode without a plan-specific patch.
+
+**Before handoff, open the plan and check it.** Fix overlap, excessive
+whitespace, clipped fragments, misleading inactive controls, poor contrast, and
+unreadable diagrams before asking for approval. Check the top canvas in the
+current Plan theme, especially dark mode: white mockup panels, low-contrast
+muted text, or invisible controls are defects. If a frame only works in one
+theme, rewrite the HTML with \`--wf-*\` tokens and semantic helper classes before
+surfacing the plan.
+
+<!-- SHARED-CORE:document-quality END -->`;
+export const DOCUMENT_QUALITY_REFERENCE_MD = `# Plan document quality — single source of truth
+
+This file is the canonical quality bar for the plan document below the canvas:
+how it reads, which blocks to use, how open questions are surfaced, and the
+pre-handoff check. Read it in full before authoring the plan document; it is the
+quality bar. Do not write the document from memory or paraphrase these rules per
+mode.
+
+${DOCUMENT_QUALITY_CORE}
+`;
+export const DOCUMENT_QUALITY_REFERENCE_POINTER = `The document is a serious technical plan, not marketing: outcome-first,
+prose-first, self-contained, built from the right native blocks, with open
+questions in a single bottom \`question-form\` and a pre-handoff visual check.
+Before authoring the plan document, READ \`references/document-quality.md\` in this
+skill directory — it is the single source of truth for the document quality bar.
+Do not write the document from memory.`;
+//# sourceMappingURL=document-quality.js.map

package/dist/cli/skills-content/document-quality.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"document-quality.js","sourceRoot":"","sources":["../../../src/cli/skills-content/document-quality.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;0CAiLK,CAAC;AAE3C,MAAM,CAAC,MAAM,6BAA6B,GAAG;;;;;;;;EAQ3C,qBAAqB;CACtB,CAAC;AAEF,MAAM,CAAC,MAAM,kCAAkC,GAAG;;;;;uCAKX,CAAC","sourcesContent":["export const DOCUMENT_QUALITY_CORE = `<!-- 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**Every published plan must stand alone.** Even when the agent is revising an\nexisting plan, the output is a plan to do the work, not a changelog of the\nconversation. Do not write phrases like \"preserve the previous plan\", \"do not\ndrop the old idea\", \"as discussed above\", \"this revision\", \"unlike the prior\nversion\", or \"correction from the earlier plan\". Fold the right decisions into\nthe plan as normal objective, architecture, scope, and roadmap prose. A reviewer\nwho opens the plan from a link with no chat history should understand it. Avoid\nnegative framing that only makes sense against absent context (\"not the old\nmode\", \"not just X\") unless the contrast is defined in the plan and genuinely\nhelps; state the positive model directly.\n\n**Make abstract plans instantly legible.** If the idea is broad, strategic, or\nintended for a third-party reviewer, put one concrete product snapshot near the\ntop before dense architecture, mode tables, manifests, or roadmaps. For\nUI-capable concepts, that snapshot is usually a top-canvas app state plus a\nshort paragraph that says what the user sees and what changes under the hood.\nThen put mechanics, data flow, sync boundaries, and implementation detail in\nseparate diagrams or document sections.\n\n**Preserve the user's level of abstraction.** A motivating use case is not\nautomatically the architecture. When the prompt describes a broader framework,\nproduct mode, or reusable primitive, separate the reusable core from specific\napps, providers, customers, scripts, or launch examples. Use the concrete\nexample to make the plan understandable, then make clear which parts are core,\nwhich are app-specific adapters, and which are future examples.\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 — 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\ncarries its own nearby inline \\`diagram\\` / \\`data-model\\` block plus file\nevidence (the \\`diagram\\` bullet below owns how to author those diagrams).\nRepeat a wireframe in the document only for a genuinely new detail view or\ncomparison. Skip the visual surface entirely for non-visual work and write a\nclean rich document. For a simple binary UI visual choice, show the two\ndirections in the canvas only; do not repeat the same options as body\nwireframes or prose. Put the actual choice 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— 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 — 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- For a decision: if the reviewer must still pick between a genuinely-open\n  either/or, put it in the bottom Open Questions \\`question-form\\` as a \\`single\\`\n  question — one option per real alternative, each with a short detail and\n  \\`recommended: true\\` on the one you would choose; do not also restate the same\n  choice elsewhere. If you have already committed to an approach, state it as\n  settled prose or a \\`callout\\` with \\`tone=\"decision\"\\`, optionally with a\n  \\`columns\\` block for a side-by-side comparison of the options you weighed — not\n  as a confusing mid-document form for a question you have already answered.\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. Prefer standard\n  two-dimensional layouts — paired before/after panels, layered diagrams,\n  swimlanes, dependency maps, matrices, or grouped regions; do not default to\n  left-to-right chains, and use a line only when the relationship is truly a\n  sequence. Do not use a body \\`diagram\\` as the primary artifact for a requested\n  product canvas, light storyboard, UI flow, screen flow, or wireframe; those\n  belong in the top canvas as artboards with \\`Screen\\` wireframes first. Use\n  diagrams below that canvas only for architecture, data flow, or implementation\n  mechanics. 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. Choose the outer \\`frame\\` intentionally: use \\`show\\` when the diagram\n  stands alone in a recap, comparison, or prose section; use \\`hide\\` when the\n  diagram sits inside docs chrome, columns, tabs, cards, a canvas surface, or\n  already has visible \\`.diagram-panel\\` / \\`.diagram-box\\` structure. Leave room\n  for the sketch font: keep labels short, give nodes generous width, and place\n  boundary/annotation labels in unused space instead of over nodes; labels must\n  not overlap nodes, connectors, or each other. For small text/SVG changes to an\n  existing HTML diagram, use \\`patch-diagram-html\\` with a unique\n  \\`find\\`/\\`replace\\` snippet instead of resending the whole \\`data.html\\` string.\n  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.\n- \\`tabs\\` for multiple states, directions, or comparisons. A tab that reveals\n  only prose usually means the plan is under-specified — 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 — 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 — 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 twice.\n\nFor complex plans, do not end without an open-question audit. If architecture,\nscope, UX, data shape, rollout, provider mapping, or ownership still depends on\na choice, either commit to a recommendation with rationale or add it to the\nbottom form with a recommended default. A complex plan with no open questions is\nfine only when every meaningful decision has been explicitly made.\n\n**Verification must exercise the real workflow.** The final verification section\nshould go beyond typecheck/unit tests when the plan changes UI, local files,\nsync, providers, browser behavior, or multi-app flows. Include at least one\nend-to-end smoke that matches the user journey, such as a fresh repo/folder,\nreal manifest or data fixture, browser interaction, save/sync action, and an\non-disk or database assertion. Name the command or manual browser path when it\nis known.\n\n**\\`custom-html\\` is a bounded escape hatch only** — 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.\nWhen \\`custom-html\\` is genuinely needed, author it against the sandbox-provided\ntheme tokens (\\`--wf-paper\\`, \\`--wf-card\\`, \\`--wf-ink\\`, \\`--wf-muted\\`,\n\\`--wf-line\\`, \\`--wf-radius\\`, and the matching \\`--plan-*\\` aliases). Do not hardcode\nhex/rgb/hsl light palettes such as white cards with dark ink; the same fragment\nmust read in dark mode without a plan-specific patch.\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. Check the top canvas in the\ncurrent Plan theme, especially dark mode: white mockup panels, low-contrast\nmuted text, or invisible controls are defects. If a frame only works in one\ntheme, rewrite the HTML with \\`--wf-*\\` tokens and semantic helper classes before\nsurfacing the plan.\n\n<!-- SHARED-CORE:document-quality END -->`;\n\nexport const DOCUMENT_QUALITY_REFERENCE_MD = `# Plan document quality — single source of truth\n\nThis file is the canonical quality bar for the plan document below the canvas:\nhow it reads, which blocks to use, how open questions are surfaced, and the\npre-handoff check. Read it in full before authoring the plan document; it is the\nquality bar. Do not write the document from memory or paraphrase these rules per\nmode.\n\n${DOCUMENT_QUALITY_CORE}\n`;\n\nexport const DOCUMENT_QUALITY_REFERENCE_POINTER = `The document is a serious technical plan, not marketing: outcome-first,\nprose-first, self-contained, built from the right native blocks, with open\nquestions in a single bottom \\`question-form\\` and a pre-handoff visual check.\nBefore authoring the plan document, READ \\`references/document-quality.md\\` in this\nskill directory — it is the single source of truth for the document quality bar.\nDo not write the document from memory.`;\n"]}

package/dist/cli/skills-content/exemplar.d.ts

@@ -0,0 +1,4 @@
+export declare const EXEMPLAR_CORE = "<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A UI-first 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 `callout`\nwith `tone=\"decision\"` stating the chosen approach with a `columns` block\nweighing the two real options behind it,\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 broad product-architecture plan opens with a plain recommendation\nand one concrete app state before the abstraction. The first canvas artboard is\npure product UI that matches the current app shell; nearby notes explain the\nuser-visible delta. A separate diagram below shows the mechanics, such as file\nor data flow. The document then separates the reusable core from app/provider\nadapters and examples, covers contracts, folder or schema shape, sync\nboundaries, roadmap, non-goals, a bottom Open Questions form for unresolved\ndecisions, and a verification section with at least one realistic end-to-end\nsmoke. A reviewer who was not in the chat gets the idea from the top snapshot\nbefore reading the technical plan.\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; a product wireframe that mixes a real screen\nwith repo names, file-contract arrows, architecture explanations, or a made-up\npermanent inspector; and a plan that describes itself as a revision of a prior\nconversation instead of a standalone proposal. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->";
+export declare const EXEMPLAR_REFERENCE_MD = "# Good vs. bad exemplar \u2014 single source of truth\n\nThis file is the canonical worked example of a great plan (and the anti-patterns\nto avoid). Read it alongside the document-quality and canvas references before\nauthoring a plan; it is the bar these plans must clear.\n\n<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A UI-first 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 `callout`\nwith `tone=\"decision\"` stating the chosen approach with a `columns` block\nweighing the two real options behind it,\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 broad product-architecture plan opens with a plain recommendation\nand one concrete app state before the abstraction. The first canvas artboard is\npure product UI that matches the current app shell; nearby notes explain the\nuser-visible delta. A separate diagram below shows the mechanics, such as file\nor data flow. The document then separates the reusable core from app/provider\nadapters and examples, covers contracts, folder or schema shape, sync\nboundaries, roadmap, non-goals, a bottom Open Questions form for unresolved\ndecisions, and a verification section with at least one realistic end-to-end\nsmoke. A reviewer who was not in the chat gets the idea from the top snapshot\nbefore reading the technical plan.\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; a product wireframe that mixes a real screen\nwith repo names, file-contract arrows, architecture explanations, or a made-up\npermanent inspector; and a plan that describes itself as a revision of a prior\nconversation instead of a standalone proposal. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->\n";
+export declare const EXEMPLAR_REFERENCE_POINTER = "For a worked example of the bar \u2014 a great UI-first plan and `/visual-plan`, plus\nthe anti-patterns to avoid \u2014 READ `references/exemplar.md` in this skill\ndirectory before authoring a plan.";
+//# sourceMappingURL=exemplar.d.ts.map

package/dist/cli/skills-content/exemplar.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"exemplar.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/exemplar.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,aAAa,uvHAuDQ,CAAC;AAEnC,eAAO,MAAM,qBAAqB,+gIAOjC,CAAC;AAEF,eAAO,MAAM,0BAA0B,6MAEJ,CAAC"}

package/dist/cli/skills-content/exemplar.js

@@ -0,0 +1,68 @@
+export const EXEMPLAR_CORE = `<!-- SHARED-CORE:exemplar START -->
+
+**GOOD.** A UI-first plan for a todo app: a canvas with a \`desktop\` artboard whose
+\`data.html\` is a real flex layout — a sidebar of links (\`Inbox 12\`, \`Today 4\`,
+\`Done\`), a main column with an \`<h1>Today</h1>\`, accent \`.wf-pill\`s for the
+filters, a muted section label \`OVERDUE\`, and \`.wf-card\` task rows carrying real
+titles, due dates, and a primary \`button.primary\` — styled only through bare
+elements, helper classes, and \`--wf-*\` tokens, so the renderer applies the
+correct desktop footprint, theme, and one subtle whole-frame wobble. Plain-text
+designer notes sit spaced off the frame, pointing only at the controls that need
+explanation. Below it, a Claude/Codex-grade document: objective and
+done-criteria, a few \`code\` blocks (grouped in a vertical \`tabs\` block when
+more than one) showing the real shape of the load-bearing files, a \`callout\`
+with \`tone="decision"\` stating the chosen approach with a \`columns\` block
+weighing the two real options behind it,
+and a validation step — none of it repeating the canvas. If the task also
+changes a multi-step completion flow, the same top area includes a Prototype tab
+whose screens use the same labels and states as the canvas artboards, with
+\`data-goto\` controls for the sequence. This is the bar.
+
+**GOOD.** A broad product-architecture plan opens with a plain recommendation
+and one concrete app state before the abstraction. The first canvas artboard is
+pure product UI that matches the current app shell; nearby notes explain the
+user-visible delta. A separate diagram below shows the mechanics, such as file
+or data flow. The document then separates the reusable core from app/provider
+adapters and examples, covers contracts, folder or schema shape, sync
+boundaries, roadmap, non-goals, a bottom Open Questions form for unresolved
+decisions, and a verification section with at least one realistic end-to-end
+smoke. A reviewer who was not in the chat gets the idea from the top snapshot
+before reading the technical plan.
+
+**GOOD.** A \`/visual-plan\` for a backend architecture review: no top canvas.
+The document opens with context and a legend, then repeats recommendation cards:
+title, confidence/category badges, a monospace grid of real file paths, one
+inline two-dimensional before/after or layered architecture diagram, and terse
+Problem/Solution/Why bullets using the codebase's vocabulary. The diagram uses
+space to show boundaries, layers, and ownership; it is not a default
+left-to-right chain. The plan ends with a top recommendation and a bottom
+question-form only if the next architecture direction is genuinely open. This is
+better than a top canvas because each diagram is local to the claim it supports.
+
+**BAD.** A \`data.html\` with hard-coded hex colors, a \`font-family\`, or fixed
+pixel width/height; gray placeholder bars "insinuating" text on a non-skeleton
+frame; a forced desktop + mobile pair for a popover; floating bordered
+annotation cards hugging the frames; a fresh hand-authored kit-tree \`screen\`
+instead of \`html\`; a multi-step UI flow with only static frames and no prototype
+tab; a mockup escaped into a document \`custom-html\` block; and a marketing-style
+document with a hero heading and value props that just restates what the canvas
+already shows. Also bad: an architecture-only plan forced into a top canvas of
+labeled boxes with overlapping text, where the actual code evidence and
+recommendations live elsewhere; a product wireframe that mixes a real screen
+with repo names, file-contract arrows, architecture explanations, or a made-up
+permanent inspector; and a plan that describes itself as a revision of a prior
+conversation instead of a standalone proposal. Never produce this.
+
+<!-- SHARED-CORE:exemplar END -->`;
+export const EXEMPLAR_REFERENCE_MD = `# Good vs. bad exemplar — single source of truth
+
+This file is the canonical worked example of a great plan (and the anti-patterns
+to avoid). Read it alongside the document-quality and canvas references before
+authoring a plan; it is the bar these plans must clear.
+
+${EXEMPLAR_CORE}
+`;
+export const EXEMPLAR_REFERENCE_POINTER = `For a worked example of the bar — a great UI-first plan and \`/visual-plan\`, plus
+the anti-patterns to avoid — READ \`references/exemplar.md\` in this skill
+directory before authoring a plan.`;
+//# sourceMappingURL=exemplar.js.map

package/dist/cli/skills-content/exemplar.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"exemplar.js","sourceRoot":"","sources":["../../../src/cli/skills-content/exemplar.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,aAAa,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;kCAuDK,CAAC;AAEnC,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;EAMnC,aAAa;CACd,CAAC;AAEF,MAAM,CAAC,MAAM,0BAA0B,GAAG;;mCAEP,CAAC","sourcesContent":["export const EXEMPLAR_CORE = `<!-- SHARED-CORE:exemplar START -->\n\n**GOOD.** A UI-first plan for a todo app: a canvas with a \\`desktop\\` artboard whose\n\\`data.html\\` is a real flex layout — 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\\` — 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 \\`callout\\`\nwith \\`tone=\"decision\"\\` stating the chosen approach with a \\`columns\\` block\nweighing the two real options behind it,\nand a validation step — 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 broad product-architecture plan opens with a plain recommendation\nand one concrete app state before the abstraction. The first canvas artboard is\npure product UI that matches the current app shell; nearby notes explain the\nuser-visible delta. A separate diagram below shows the mechanics, such as file\nor data flow. The document then separates the reusable core from app/provider\nadapters and examples, covers contracts, folder or schema shape, sync\nboundaries, roadmap, non-goals, a bottom Open Questions form for unresolved\ndecisions, and a verification section with at least one realistic end-to-end\nsmoke. A reviewer who was not in the chat gets the idea from the top snapshot\nbefore reading the technical plan.\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; a product wireframe that mixes a real screen\nwith repo names, file-contract arrows, architecture explanations, or a made-up\npermanent inspector; and a plan that describes itself as a revision of a prior\nconversation instead of a standalone proposal. Never produce this.\n\n<!-- SHARED-CORE:exemplar END -->`;\n\nexport const EXEMPLAR_REFERENCE_MD = `# Good vs. bad exemplar — single source of truth\n\nThis file is the canonical worked example of a great plan (and the anti-patterns\nto avoid). Read it alongside the document-quality and canvas references before\nauthoring a plan; it is the bar these plans must clear.\n\n${EXEMPLAR_CORE}\n`;\n\nexport const EXEMPLAR_REFERENCE_POINTER = `For a worked example of the bar — a great UI-first plan and \\`/visual-plan\\`, plus\nthe anti-patterns to avoid — READ \\`references/exemplar.md\\` in this skill\ndirectory before authoring a plan.`;\n"]}

package/dist/cli/skills-content/help.d.ts

@@ -0,0 +1,2 @@
+export declare const HELP = "npx @agent-native/core@latest skills\n\nUsage:\n  npx @agent-native/core@latest skills list\n  npx @agent-native/core@latest skills status [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--json]\n  npx @agent-native/core@latest skills update [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--dry-run] [--json]\n  npx @agent-native/core@latest skills add assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray [--client codex|claude-code|cowork|cursor|opencode|github-copilot|all] [--scope user|project] [--mode hosted|local-files|self-hosted] [--mcp-url <url>] [--no-connect] [--with-github-action] [--yes] [--dry-run] [--json]\n  npx @agent-native/core@latest skills add <manifest-or-app-dir|skill-repo> [--skill <name>] [--client ...] [--yes]\n\nExamples:\n  npx @agent-native/core@latest skills add assets\n  npx @agent-native/core@latest skills add content --mode local-files\n  npx @agent-native/core@latest skills add design-exploration\n  npx @agent-native/core@latest skills add visual-edit\n  npx @agent-native/core@latest skills add visual-plan\n  npx @agent-native/core@latest skills add visual-recap\n  npx @agent-native/core@latest skills add visualize-repo\n  npx @agent-native/core@latest skills add visual-recap --with-github-action\n  npx @agent-native/core@latest skills add visual-plan --mode local-files\n  npx @agent-native/core@latest skills add visual-plan --mode self-hosted --mcp-url https://my-plan-app.example.com\n  npx @agent-native/core@latest skills status visual-plan\n  npx @agent-native/core@latest skills update visual-plan\n  npx @agent-native/core@latest skills update scaffold --project\n  npx @agent-native/core@latest skills add visual-plan --no-connect\n  npx @agent-native/core@latest skills add context-xray --client all\n  npx @agent-native/core@latest skills add assets --client claude-code\n  npx @agent-native/core@latest skills add assets --mcp-url https://my-app.ngrok-free.dev\n  npx @agent-native/core@latest skills add ./dist/assets-skill --client codex\n  npx @agent-native/core@latest skills add BuilderIO/skills --client codex --scope project\n  npx @agent-native/core@latest skills add BuilderIO/skills --with-github-action\n\nThe add command installs the SKILL.md instructions, registers the app-backed\nMCP connector, and then authenticates it in one step so you do not hit an OAuth\nwall on the first tool call. Hosted installs can configure Claude Code, Codex,\nClaude Cowork, Cursor, OpenCode, and GitHub Copilot / VS Code; local-files\ninstruction installs target the shared .agents skill path used by Codex, Pi,\nCursor, OpenCode, Copilot, and similar agents, plus Claude Code's native skill\npath when selected. Pass --client to narrow it. Authentication reuses\n\"npx @agent-native/core@latest connect\": OAuth-capable clients (Claude Code,\nCursor, OpenCode, GitHub Copilot / VS Code) get URL-only entries and authenticate\ninside that host, while Codex / Cowork run the browser device-code flow. In a\nnon-interactive shell or CI the auth step is skipped and the exact\n\"npx @agent-native/core@latest connect <url> --client all\" command is printed instead.\n\nRunning \"npx @agent-native/skills@latest add ...\" uses this same shared install\nflow with the broader BuilderIO skills catalog enabled. Pass --no-connect to\nregister MCP where possible without authenticating (leave auth to the host or run\n\"npx @agent-native/core@latest connect\" later). Pass --mcp-url to register that connector against\na custom origin (an ngrok tunnel, a local dev server, or a self-hosted\ndeployment) instead of the built-in hosted default \u2014 a bare origin gets the\nstandard /_agent-native/mcp path appended. Use app-skill pack for marketplace\nbundles and custom adapter output.\n\nWhen installing visual-plan, visual-recap, or visualize-repo interactively, the\nCLI asks where Plans artifacts should live: hosted Plans for shareable\nlinks/comments, local files for \"No sharing, all local.\", or a\nself-hosted/custom Plan app URL.\nPass --mode to choose directly. Local-files mode skips MCP registration and\nauth and installs instructions that default to a no-auth block catalog fetch,\nMDX folders, and the localhost bridge viewer.\n\nWhen installing content with --mode local-files, the CLI installs Content\ninstructions and writes or updates agent-native.json with repo-backed Markdown /\nMDX roots for docs, blog, content, and resources. Use a local Content app, Agent\nNative Desktop, or another trusted local bridge for Content actions to read and\nwrite those files.\n\nWhen installing visual-recap interactively, the CLI offers to add the optional PR\nVisual Recap GitHub Action. Pass --with-github-action to write it directly, then\nrun \"npx @agent-native/core@latest recap setup\" / \"npx @agent-native/core@latest recap doctor\" to configure and\nverify GitHub Actions. Docs: https://www.agent-native.com/docs/pr-visual-recap.\n\nThe status/update commands inspect copied Agent Native skill folders and refresh\ntheir instruction files from the current @agent-native/core package. In generated\napps/workspaces, \"skills update scaffold --project\" refreshes the framework\nskills copied into the scaffold and repairs AGENTS.md / CLAUDE.md and\n.agents/skills / .claude/skills compatibility links.";
+//# sourceMappingURL=help.d.ts.map

package/dist/cli/skills-content/help.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"help.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/help.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,IAAI,k8KA4EoC,CAAC"}

package/dist/cli/skills-content/help.js

@@ -0,0 +1,78 @@
+export const HELP = `npx @agent-native/core@latest skills
+
+Usage:
+  npx @agent-native/core@latest skills list
+  npx @agent-native/core@latest skills status [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--json]
+  npx @agent-native/core@latest skills update [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--dry-run] [--json]
+  npx @agent-native/core@latest skills add assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray [--client codex|claude-code|cowork|cursor|opencode|github-copilot|all] [--scope user|project] [--mode hosted|local-files|self-hosted] [--mcp-url <url>] [--no-connect] [--with-github-action] [--yes] [--dry-run] [--json]
+  npx @agent-native/core@latest skills add <manifest-or-app-dir|skill-repo> [--skill <name>] [--client ...] [--yes]
+
+Examples:
+  npx @agent-native/core@latest skills add assets
+  npx @agent-native/core@latest skills add content --mode local-files
+  npx @agent-native/core@latest skills add design-exploration
+  npx @agent-native/core@latest skills add visual-edit
+  npx @agent-native/core@latest skills add visual-plan
+  npx @agent-native/core@latest skills add visual-recap
+  npx @agent-native/core@latest skills add visualize-repo
+  npx @agent-native/core@latest skills add visual-recap --with-github-action
+  npx @agent-native/core@latest skills add visual-plan --mode local-files
+  npx @agent-native/core@latest skills add visual-plan --mode self-hosted --mcp-url https://my-plan-app.example.com
+  npx @agent-native/core@latest skills status visual-plan
+  npx @agent-native/core@latest skills update visual-plan
+  npx @agent-native/core@latest skills update scaffold --project
+  npx @agent-native/core@latest skills add visual-plan --no-connect
+  npx @agent-native/core@latest skills add context-xray --client all
+  npx @agent-native/core@latest skills add assets --client claude-code
+  npx @agent-native/core@latest skills add assets --mcp-url https://my-app.ngrok-free.dev
+  npx @agent-native/core@latest skills add ./dist/assets-skill --client codex
+  npx @agent-native/core@latest skills add BuilderIO/skills --client codex --scope project
+  npx @agent-native/core@latest skills add BuilderIO/skills --with-github-action
+
+The add command installs the SKILL.md instructions, registers the app-backed
+MCP connector, and then authenticates it in one step so you do not hit an OAuth
+wall on the first tool call. Hosted installs can configure Claude Code, Codex,
+Claude Cowork, Cursor, OpenCode, and GitHub Copilot / VS Code; local-files
+instruction installs target the shared .agents skill path used by Codex, Pi,
+Cursor, OpenCode, Copilot, and similar agents, plus Claude Code's native skill
+path when selected. Pass --client to narrow it. Authentication reuses
+"npx @agent-native/core@latest connect": OAuth-capable clients (Claude Code,
+Cursor, OpenCode, GitHub Copilot / VS Code) get URL-only entries and authenticate
+inside that host, while Codex / Cowork run the browser device-code flow. In a
+non-interactive shell or CI the auth step is skipped and the exact
+"npx @agent-native/core@latest connect <url> --client all" command is printed instead.
+
+Running "npx @agent-native/skills@latest add ..." uses this same shared install
+flow with the broader BuilderIO skills catalog enabled. Pass --no-connect to
+register MCP where possible without authenticating (leave auth to the host or run
+"npx @agent-native/core@latest connect" later). Pass --mcp-url to register that connector against
+a custom origin (an ngrok tunnel, a local dev server, or a self-hosted
+deployment) instead of the built-in hosted default — a bare origin gets the
+standard /_agent-native/mcp path appended. Use app-skill pack for marketplace
+bundles and custom adapter output.
+
+When installing visual-plan, visual-recap, or visualize-repo interactively, the
+CLI asks where Plans artifacts should live: hosted Plans for shareable
+links/comments, local files for "No sharing, all local.", or a
+self-hosted/custom Plan app URL.
+Pass --mode to choose directly. Local-files mode skips MCP registration and
+auth and installs instructions that default to a no-auth block catalog fetch,
+MDX folders, and the localhost bridge viewer.
+
+When installing content with --mode local-files, the CLI installs Content
+instructions and writes or updates agent-native.json with repo-backed Markdown /
+MDX roots for docs, blog, content, and resources. Use a local Content app, Agent
+Native Desktop, or another trusted local bridge for Content actions to read and
+write those files.
+
+When installing visual-recap interactively, the CLI offers to add the optional PR
+Visual Recap GitHub Action. Pass --with-github-action to write it directly, then
+run "npx @agent-native/core@latest recap setup" / "npx @agent-native/core@latest recap doctor" to configure and
+verify GitHub Actions. Docs: https://www.agent-native.com/docs/pr-visual-recap.
+
+The status/update commands inspect copied Agent Native skill folders and refresh
+their instruction files from the current @agent-native/core package. In generated
+apps/workspaces, "skills update scaffold --project" refreshes the framework
+skills copied into the scaffold and repairs AGENTS.md / CLAUDE.md and
+.agents/skills / .claude/skills compatibility links.`;
+//# sourceMappingURL=help.js.map

package/dist/cli/skills-content/help.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"help.js","sourceRoot":"","sources":["../../../src/cli/skills-content/help.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,IAAI,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;qDA4EiC,CAAC","sourcesContent":["export const HELP = `npx @agent-native/core@latest skills\n\nUsage:\n  npx @agent-native/core@latest skills list\n  npx @agent-native/core@latest skills status [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--json]\n  npx @agent-native/core@latest skills update [assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray|scaffold] [--client codex|claude-code|pi|all] [--scope user|project] [--dry-run] [--json]\n  npx @agent-native/core@latest skills add assets|content|design-exploration|visual-edit|visual-plan|visual-recap|visualize-repo|context-xray [--client codex|claude-code|cowork|cursor|opencode|github-copilot|all] [--scope user|project] [--mode hosted|local-files|self-hosted] [--mcp-url <url>] [--no-connect] [--with-github-action] [--yes] [--dry-run] [--json]\n  npx @agent-native/core@latest skills add <manifest-or-app-dir|skill-repo> [--skill <name>] [--client ...] [--yes]\n\nExamples:\n  npx @agent-native/core@latest skills add assets\n  npx @agent-native/core@latest skills add content --mode local-files\n  npx @agent-native/core@latest skills add design-exploration\n  npx @agent-native/core@latest skills add visual-edit\n  npx @agent-native/core@latest skills add visual-plan\n  npx @agent-native/core@latest skills add visual-recap\n  npx @agent-native/core@latest skills add visualize-repo\n  npx @agent-native/core@latest skills add visual-recap --with-github-action\n  npx @agent-native/core@latest skills add visual-plan --mode local-files\n  npx @agent-native/core@latest skills add visual-plan --mode self-hosted --mcp-url https://my-plan-app.example.com\n  npx @agent-native/core@latest skills status visual-plan\n  npx @agent-native/core@latest skills update visual-plan\n  npx @agent-native/core@latest skills update scaffold --project\n  npx @agent-native/core@latest skills add visual-plan --no-connect\n  npx @agent-native/core@latest skills add context-xray --client all\n  npx @agent-native/core@latest skills add assets --client claude-code\n  npx @agent-native/core@latest skills add assets --mcp-url https://my-app.ngrok-free.dev\n  npx @agent-native/core@latest skills add ./dist/assets-skill --client codex\n  npx @agent-native/core@latest skills add BuilderIO/skills --client codex --scope project\n  npx @agent-native/core@latest skills add BuilderIO/skills --with-github-action\n\nThe add command installs the SKILL.md instructions, registers the app-backed\nMCP connector, and then authenticates it in one step so you do not hit an OAuth\nwall on the first tool call. Hosted installs can configure Claude Code, Codex,\nClaude Cowork, Cursor, OpenCode, and GitHub Copilot / VS Code; local-files\ninstruction installs target the shared .agents skill path used by Codex, Pi,\nCursor, OpenCode, Copilot, and similar agents, plus Claude Code's native skill\npath when selected. Pass --client to narrow it. Authentication reuses\n\"npx @agent-native/core@latest connect\": OAuth-capable clients (Claude Code,\nCursor, OpenCode, GitHub Copilot / VS Code) get URL-only entries and authenticate\ninside that host, while Codex / Cowork run the browser device-code flow. In a\nnon-interactive shell or CI the auth step is skipped and the exact\n\"npx @agent-native/core@latest connect <url> --client all\" command is printed instead.\n\nRunning \"npx @agent-native/skills@latest add ...\" uses this same shared install\nflow with the broader BuilderIO skills catalog enabled. Pass --no-connect to\nregister MCP where possible without authenticating (leave auth to the host or run\n\"npx @agent-native/core@latest connect\" later). Pass --mcp-url to register that connector against\na custom origin (an ngrok tunnel, a local dev server, or a self-hosted\ndeployment) instead of the built-in hosted default — a bare origin gets the\nstandard /_agent-native/mcp path appended. Use app-skill pack for marketplace\nbundles and custom adapter output.\n\nWhen installing visual-plan, visual-recap, or visualize-repo interactively, the\nCLI asks where Plans artifacts should live: hosted Plans for shareable\nlinks/comments, local files for \"No sharing, all local.\", or a\nself-hosted/custom Plan app URL.\nPass --mode to choose directly. Local-files mode skips MCP registration and\nauth and installs instructions that default to a no-auth block catalog fetch,\nMDX folders, and the localhost bridge viewer.\n\nWhen installing content with --mode local-files, the CLI installs Content\ninstructions and writes or updates agent-native.json with repo-backed Markdown /\nMDX roots for docs, blog, content, and resources. Use a local Content app, Agent\nNative Desktop, or another trusted local bridge for Content actions to read and\nwrite those files.\n\nWhen installing visual-recap interactively, the CLI offers to add the optional PR\nVisual Recap GitHub Action. Pass --with-github-action to write it directly, then\nrun \"npx @agent-native/core@latest recap setup\" / \"npx @agent-native/core@latest recap doctor\" to configure and\nverify GitHub Actions. Docs: https://www.agent-native.com/docs/pr-visual-recap.\n\nThe status/update commands inspect copied Agent Native skill folders and refresh\ntheir instruction files from the current @agent-native/core package. In generated\napps/workspaces, \"skills update scaffold --project\" refreshes the framework\nskills copied into the scaffold and repairs AGENTS.md / CLAUDE.md and\n.agents/skills / .claude/skills compatibility links.`;\n"]}

package/dist/cli/skills-content/index.d.ts

@@ -0,0 +1,23 @@
+/**
+ * Barrel for the large embedded-markdown string constants used by
+ * `agent-native skills` (SKILL.md bodies, shared reference docs, and the CLI
+ * help text). Split out of `skills.ts` so that file can lead with real CLI
+ * logic instead of ~3,000 lines of data. Content is purely relocated here —
+ * no bytes were changed.
+ */
+export * from "./help.js";
+export * from "./assets-skill.js";
+export * from "./content-skill.js";
+export * from "./design-exploration-skill.js";
+export * from "./design-visual-edit-skill.js";
+export * from "./plan-setup-auth.js";
+export * from "./wireframe.js";
+export * from "./canvas.js";
+export * from "./document-quality.js";
+export * from "./exemplar.js";
+export * from "./connection.js";
+export * from "./local-files.js";
+export * from "./visual-plan-skill.js";
+export * from "./visual-recap-skill.js";
+export * from "./visualize-repo-skill.js";
+//# sourceMappingURL=index.d.ts.map

package/dist/cli/skills-content/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/index.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,cAAc,WAAW,CAAC;AAC1B,cAAc,mBAAmB,CAAC;AAClC,cAAc,oBAAoB,CAAC;AACnC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,+BAA+B,CAAC;AAC9C,cAAc,sBAAsB,CAAC;AACrC,cAAc,gBAAgB,CAAC;AAC/B,cAAc,aAAa,CAAC;AAC5B,cAAc,uBAAuB,CAAC;AACtC,cAAc,eAAe,CAAC;AAC9B,cAAc,iBAAiB,CAAC;AAChC,cAAc,kBAAkB,CAAC;AACjC,cAAc,wBAAwB,CAAC;AACvC,cAAc,yBAAyB,CAAC;AACxC,cAAc,2BAA2B,CAAC"}

package/dist/cli/skills-content/index.js

@@ -0,0 +1,23 @@
+/**
+ * Barrel for the large embedded-markdown string constants used by
+ * `agent-native skills` (SKILL.md bodies, shared reference docs, and the CLI
+ * help text). Split out of `skills.ts` so that file can lead with real CLI
+ * logic instead of ~3,000 lines of data. Content is purely relocated here —
+ * no bytes were changed.
+ */
+export * from "./help.js";
+export * from "./assets-skill.js";
+export * from "./content-skill.js";
+export * from "./design-exploration-skill.js";
+export * from "./design-visual-edit-skill.js";
+export * from "./plan-setup-auth.js";
+export * from "./wireframe.js";
+export * from "./canvas.js";
+export * from "./document-quality.js";
+export * from "./exemplar.js";
+export * from "./connection.js";
+export * from "./local-files.js";
+export * from "./visual-plan-skill.js";
+export * from "./visual-recap-skill.js";
+export * from "./visualize-repo-skill.js";
+//# sourceMappingURL=index.js.map

package/dist/cli/skills-content/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../src/cli/skills-content/index.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,cAAc,WAAW,CAAC;AAC1B,cAAc,mBAAmB,CAAC;AAClC,cAAc,oBAAoB,CAAC;AACnC,cAAc,+BAA+B,CAAC;AAC9C,cAAc,+BAA+B,CAAC;AAC9C,cAAc,sBAAsB,CAAC;AACrC,cAAc,gBAAgB,CAAC;AAC/B,cAAc,aAAa,CAAC;AAC5B,cAAc,uBAAuB,CAAC;AACtC,cAAc,eAAe,CAAC;AAC9B,cAAc,iBAAiB,CAAC;AAChC,cAAc,kBAAkB,CAAC;AACjC,cAAc,wBAAwB,CAAC;AACvC,cAAc,yBAAyB,CAAC;AACxC,cAAc,2BAA2B,CAAC","sourcesContent":["/**\n * Barrel for the large embedded-markdown string constants used by\n * `agent-native skills` (SKILL.md bodies, shared reference docs, and the CLI\n * help text). Split out of `skills.ts` so that file can lead with real CLI\n * logic instead of ~3,000 lines of data. Content is purely relocated here —\n * no bytes were changed.\n */\nexport * from \"./help.js\";\nexport * from \"./assets-skill.js\";\nexport * from \"./content-skill.js\";\nexport * from \"./design-exploration-skill.js\";\nexport * from \"./design-visual-edit-skill.js\";\nexport * from \"./plan-setup-auth.js\";\nexport * from \"./wireframe.js\";\nexport * from \"./canvas.js\";\nexport * from \"./document-quality.js\";\nexport * from \"./exemplar.js\";\nexport * from \"./connection.js\";\nexport * from \"./local-files.js\";\nexport * from \"./visual-plan-skill.js\";\nexport * from \"./visual-recap-skill.js\";\nexport * from \"./visualize-repo-skill.js\";\n"]}

package/dist/cli/skills-content/local-files.d.ts

@@ -0,0 +1,2 @@
+export declare const LOCAL_FILES_REFERENCE_MD = "# Local-files privacy mode \u2014 single source of truth\n\nThis file is the canonical contract for fully local, no-database planning and\nrecaps. It is shared word for word by `/visual-plan` and `/visual-recap`. Read it\nin full before using local-files mode; do not call any hosted Plan tool for a\nlocal plan/recap except the schema-only block-catalog lookup described below.\n\n<!-- SHARED-CORE:local-files START -->\n\n**When to use it.** Use local-files privacy mode when the user explicitly asks\nfor no DB writes, no hosted Plan database writes, no Plan MCP publish, fully local\nfiles, offline/private work, or repo-owned/source-controlled artifacts, or when\n`AGENT_NATIVE_PLANS_MODE=local-files` is set. Also use it when a user or repo\npolicy says the work must stay under their own brand, domain, source control, or\ninfrastructure. In this mode the plan/recap data must never be sent to the Plan\nMCP server or the Plan app action surface. This is the only exception to the\nalways-publish rule in `references/connection.md`.\n\nThe local-files contract:\n\n- **Read context locally.** Read source, diff, and stat context from local files\n  and shell commands only. For recaps, the\n  `npx @agent-native/core@latest recap collect-diff`, `scan`, and\n  `build-prompt --local-files` helpers are safe \u2014 they operate on local files and\n  do not write to the Plan database.\n- **Fetch the block catalog first** (it sends no plan content). Use the MCP\n  `get-plan-blocks` tool if it is already available, or run\n  `npx @agent-native/core@latest plan blocks --out plan-blocks.md` and read that\n  file before authoring MDX; it calls the public no-auth `get-plan-blocks` route.\n  Use `--format schema` when you need exact nested fields. If network access is\n  unavailable, use the bundled `references/*.md` and rely on `plan local check` to\n  catch invalid tags. Copy the catalog examples verbatim for the fields the\n  registry table cannot encode: `checklist` items need `id` and `label`;\n  `question-form` questions need `id`, `title`, and `mode`, and each option needs\n  `id` and `label`; and `Code` / `AnnotatedCode` / `Diff` are whitespace-sensitive\n  \u2014 encode multiline code as JSON string attributes such as `code={\"const x =\\n  y\"}`\n  (a static template literal is accepted only when it has no `${...}`\n  interpolation). `plan local check` is a quick OFFLINE lint (a subset of the\n  renderer schema), so a green `check` does not guarantee the plan renders;\n  `plan local verify` is the authoritative validation against the real renderer\n  schema.\n- **Write a local MDX folder.** Use `plans/<slug>/` to check the artifact into the\n  repo, or a repo-ignored/temporary folder such as `.agent-native/plans/<slug>/`\n  or `/tmp/agent-native-plans/<slug>/` when it should not be checked in. The\n  folder holds `plan.mdx`, optional `canvas.mdx`, optional `prototype.mdx`, and\n  optional `.plan-state.json`. For a recap, set `kind: \"recap\"` and\n  `localOnly: true` in the frontmatter/state. Use that exact folder as\n  `<plan-dir>` in every command below.\n- **Check, then serve.** Run\n  `npx @agent-native/core@latest plan local check --dir <plan-dir>` before any\n  preview, then\n  `npx @agent-native/core@latest plan local serve --dir <plan-dir> --kind <plan|recap> --open`\n  (use `--kind plan` for plans, `--kind recap` for recaps). Report the local\n  bridge URL from stdout or `<plan-dir>/.plan-url`; treat `.plan-url` as a local\n  token file and do not commit it. The URL opens the hosted Plan UI but reads from\n  the localhost bridge on this machine, so it is not shareable across machines. On\n  macOS `--open` prefers Chromium browsers; if Safari opens, switch to\n  Chrome/Chromium because Safari can block the hosted HTTPS page from fetching the\n  HTTP localhost bridge. If the Plan app itself is running locally with the same\n  `PLAN_LOCAL_DIR`, the `/local-plans/<slug>` route is also valid. In a truly\n  offline environment, hand off the `<plan-dir>` path after `plan local check` and\n  note that interactive preview requires network access to the hosted Plan UI or a\n  running local Plan app.\n- **Headless verify.** Run\n  `npx @agent-native/core@latest plan local verify --dir <plan-dir> --kind <plan|recap>`.\n  It starts the bridge, checks the private-network preflight and JSON payload, AND\n  validates the content against the real renderer schema via the Plan app's\n  `validate-local-plan-source` action. A non-`ok` result with\n  `validation.valid: false` lists the renderer's exact schema-path issues (e.g.\n  `blocks[1].data.tabs[0]...`); fix those before handing off. If `validation.ran`\n  is `false`, the Plan app did not expose the validate endpoint (older/unreachable\n  deploy) \u2014 point `--app-url` at a current Plan app (e.g. a local\n  `http://localhost:8096`) for the authoritative check. If the browser hangs on\n  \"Loading plan\", fetch the `bridgeUrl` from the verify/serve JSON to read the\n  concrete validation error.\n- **Never call hosted tools for that plan/recap.** Do not call\n  `create-visual-plan`, `create-ui-plan`, `create-prototype-plan`,\n  `create-plan-design`, `create-visual-recap`, `create-visual-questions`,\n  `import-visual-plan-source`, `update-visual-plan`, `patch-visual-plan-source`,\n  `get-plan-feedback`, `export-visual-plan`, `set-resource-visibility`, or any\n  other hosted Plan tool \u2014 except the schema-only block-catalog lookup above.\n- **Feedback is file/chat feedback.** Update the MDX files directly, rerun\n  `plan local check`, and rerun `serve` or `verify` when that preview path is\n  available. Summarize the new local URL when one exists; otherwise summarize the\n  checked `<plan-dir>` path. Hosted comments, sharing, screenshots, history, usage\n  attachment, and publish/export receipts are unavailable until the user\n  explicitly opts into publishing.\n\nLocal-files mode only prevents plan/recap content from reaching the Agent-Native\nPlan database. It does not by itself make the coding agent's language model local;\nfor that stronger boundary the host agent/model must also be local or otherwise\napproved by the user.\n\n<!-- SHARED-CORE:local-files END -->\n";
+//# sourceMappingURL=local-files.d.ts.map

package/dist/cli/skills-content/local-files.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"local-files.d.ts","sourceRoot":"","sources":["../../../src/cli/skills-content/local-files.ts"],"names":[],"mappings":"AAAA,eAAO,MAAM,wBAAwB,4kMA8FpC,CAAC"}