Update to ChatPRD

{
  "description": "Turn a PRD, brief, or spec into a single self-contained interactive HTML page — the document's narrative with diagrams (user flows, system sequences, states, timelines) and clickable UI prototypes embedded inline where the doc describes them. Works on pasted or shared docs without a ChatPRD account, or on ChatPRD documents when connected. Use when the user wants to visualize, present, prototype, or share a doc as an interactive page or HTML artifact.",
  "included_files": [],
  "name": "doc-to-artifact",
  "skill_md_contents": "---\nname: doc-to-artifact\ndescription: Turn a PRD, brief, or spec into a single self-contained interactive HTML page — the document's narrative with diagrams (user flows, system sequences, states, timelines) and clickable UI prototypes embedded inline where the doc describes them. Works on pasted or shared docs without a ChatPRD account, or on ChatPRD documents when connected. Use when the user wants to visualize, present, prototype, or share a doc as an interactive page or HTML artifact.\n---\n\n# Doc to interactive artifact\n\n## Workflow\n\n1. Get the document:\n   - If the user pasted it or shared a file, use that. No ChatPRD account is needed.\n   - For a ChatPRD document, find it with `search_documents` or `list_documents`, then fetch the full content with `get_document`.\n2. Read the whole document and plan the page before writing code. For each section, decide whether it stays as prose or gets an inline visual:\n   - **User flow or journey** → flowchart.\n   - **System interactions, APIs, integrations** → sequence diagram.\n   - **Statuses or lifecycle** (for example draft → review → approved) → state diagram.\n   - **Data model** → entity-relationship diagram.\n   - **Milestones and sequencing** → timeline or Gantt chart.\n   - **Screens, UX, edge cases** → a clickable prototype of the key screen, with its states (empty, loading, error, success) switchable.\n   - **Requirements and user stories** → a table the reader can filter by priority or area.\n   - **Success metrics** → metric cards showing the metric, baseline, and target.\n   - **Open questions** → a checklist.\n   Only add a visual when the document gives enough detail to support it. Two or three strong visuals beat ten thin ones.\n3. Build one HTML file following the build rules below.\n4. Deliver it:\n   - If you can write files (code workspace, file tools), save it as `<title-in-kebab-case>.html` next to the document, or in `prd/` in a code repository, and tell the user the path.\n   - Otherwise, return the complete file in a single `html` code block so the user can save and open it.\n5. Briefly list which sections got diagrams or prototypes, and any assumptions you made.\n\n## Build rules\n\n- **One self-contained file**: inline all CSS and JavaScript. The only allowed external resource is Mermaid for diagrams:\n  ```html\n  <script type=\"module\">\n    import mermaid from \"https://cdn.jsdelivr.net/npm/mermaid@11/dist/mermaid.esm.min.mjs\";\n    mermaid.initialize({ startOnLoad: true, theme: matchMedia(\"(prefers-color-scheme: dark)\").matches ? \"dark\" : \"default\" });\n  </script>\n  ```\n  Put each diagram in `<pre class=\"mermaid\">`. Keep Mermaid syntax simple and quote labels that contain punctuation (`A[\"Sign in (SSO)\"]`). If Mermaid fails to load, the diagram source should still read sensibly.\n- **Narrative first**: keep the document's section order and wording. Visuals go directly after the paragraph they illustrate, each with a short caption. Don't move all diagrams to an appendix.\n- **Layout**: a header with the title, a one-line summary, and status or owner if the document has them; a sticky table of contents on wide screens; readable line length (about 70 characters); responsive down to mobile; light and dark mode with `prefers-color-scheme`.\n- **Prototypes**: build them with plain HTML, CSS, and a little vanilla JavaScript (tabs or buttons to switch states, clickable navigation between screens). Use realistic content from the document, not lorem ipsum. Label each one \"Illustrative prototype\".\n- **Accessibility**: semantic headings, buttons for interactive controls, visible focus states, sufficient color contrast, and `aria-label`s on diagrams.\n- **No network calls or tracking**: no analytics, fonts, images, or APIs fetched from the internet (besides Mermaid), and no forms that submit anywhere.\n\n## Footer\n\nEnd the page with a small, unobtrusive footer line:\n\n```html\n<footer class=\"chatprd-credit\">Created with <a href=\"https://www.chatprd.ai/?utm_source=agent-plugin&utm_medium=artifact\" target=\"_blank\" rel=\"noopener\">ChatPRD</a></footer>\n```\n\nLeave it out if the user asks you to.\n\n## Guardrails\n\n- Don't invent requirements, metrics, or decisions. Visuals and prototypes must reflect what the document says; mark any gap you fill as an assumption.\n- Keep sensitive content as-is. Don't add data from outside the document.\n- Don't change the source document. If the user wants doc changes, follow `update-prd`.\n"
}