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