export declare 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 \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation\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\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- 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 \u2014 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 \u2014 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 \u2014 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 \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nThat bottom form is the ONLY place that enumerates the open questions: never add\na second \"Open Questions\" heading, list, or recap of the same questions earlier\nin the document. A one-line pointer in the overview prose (\"a few decisions are\nstill open \u2014 see Open Questions below\") is fine, but do not reproduce the\nquestion list or a parallel questions/decisions section above it.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question 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** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\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 -->";
export declare const DOCUMENT_QUALITY_REFERENCE_MD = "# Plan document quality \u2014 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<!-- 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 \u2014 concrete\nfile/symbol maps, API and data contracts, code snippets, migration or\nimplementation phases, risks, and validation. For architecture/code reviews,\ninvert that: the document is the visual surface, and each recommendation\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\u2014 it returns the live registry vocabulary (type, MDX tag, placement, key fields)\nso you never emit a block the editor cannot render or round-trip:\n\n- `rich-text` for plan prose with real bold/italic/code/links and nested lists.\n- `annotated-code` for the file map: when a load-bearing file is worth\n  highlighting, prefer the annotated walkthrough over a bare `code` block \u2014 carry\n  the real, syntax-highlighted code AND anchor short margin notes to the lines\n  that actually change (the new action, the changed schema, the wiring point), so\n  the reader sees what matters and why instead of code for code's sake. Each\n  annotation is `{ lines: \"12\" | \"12-18\"; label?; note }`; keep a few high-signal\n  notes per file, not one per line. Highlight only the files worth reading; never\n  an exhaustive list of every touched file, and never a prose-only description of\n  a file. Drop to a plain `code` block only for a throwaway snippet with nothing\n  to call out. When more than one file matters, group the blocks in a vertical\n  `tabs` block (the standard tab primitive) rather than a bespoke container. If\n  the exact code is unknown, show the smallest plausible planned shape or a\n  commented stub naming what to fill in. (`code-tabs` and `implementation-map`\n  are legacy: their renderers stay for old plans, but do not author new ones.)\n- 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 \u2014 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 \u2014 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 \u2014 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 \u2014 include a relevant\n  visual unless the tab is intentionally document-only.\n- `table`, `checklist`, `callout` for scannable structure.\n\n**Open questions live at the bottom as a form when answers would change the\nplan.** Surface answerable unresolved decisions in a final `question-form`\nblock titled \"Open Questions\" so the renderer presents it as a distinct section.\nThat bottom form is the ONLY place that enumerates the open questions: never add\na second \"Open Questions\" heading, list, or recap of the same questions earlier\nin the document. A one-line pointer in the overview prose (\"a few decisions are\nstill open \u2014 see Open Questions below\") is fine, but do not reproduce the\nquestion list or a parallel questions/decisions section above it.\nUse `single` or `multi` for clear choices, `freeform` for constraints,\n`recommended: true` for the default you would pick, and option `wireframe` /\n`diagram` previews only when the options are not already visible in the top\ncanvas. `single` and `multi` questions always render a write-in field so a\nreviewer can answer with a custom option \u2014 never add an explicit \"Other\" option\nyourself; set `allowOther: false` only when a free-text answer makes no sense.\nKeep non-answerable assumptions or risks as concise `callout` blocks in\nthe relevant section. Never bury a questions/decisions wall inside the plan\nnarrative, and never ask the same question 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** \u2014 a single complete fragment\ninside a block, never `html`/`head`/`body`/`script` tags, never a generic\nplaceholder, density demo, or proof that custom HTML works. Prefer the native\nblocks for normal plans. For architecture/code reviews, use `diagram`\n`data.html` / `data.css` for rich local HTML/SVG diagrams instead of\n`custom-html`. For UI/product work, `custom-html` is never the primary home for a\nrequested mockup, UI state, or visual comparison. If UI fidelity requires\nHTML/CSS, image capture, or real React/CSS, the product fix is canvas support\nfor that artifact type, not moving the mockup into the document.\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";
export declare 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 \u2014 it is the single source of truth for the document quality bar.\nDo not write the document from memory.";
//# sourceMappingURL=document-quality.d.ts.map