$npx -y skills add fernandomenuk/canvas-flow --skill canvasflowTurn complex or visual agent responses into rich, reviewable HTML artifacts the user can annotate and send feedback on, using the canvas-flow CLI. Use when about to give a plan, comparison, diagram, table, code diff, report, or anything easier to grasp visually than as prose.
| 1 | # Canvas Flow |
| 2 | |
| 3 | Canvas Flow helps agents turn rich HTML artifacts into collaborative human review surfaces. Whenever you are about to give user a complex response that will be easier to understand via a rich / interactive page, consider using Canvas Flow. First generate an interactive HTML artifact according to user request, then run `npx -y @menukfernandoo/canvas-flow <html-file>` so the user can visually review it, annotate elements or selected text, queue prompts, and send feedback back through `npx -y @menukfernandoo/canvas-flow poll`. |
| 4 | |
| 5 | You do not need canvas-flow installed globally - invoke it with `npx -y @menukfernandoo/canvas-flow <html-file>`. |
| 6 | If canvas-flow output shows a follow-up command starting with `canvas-flow`, run it as `npx -y @menukfernandoo/canvas-flow ...` instead. |
| 7 | |
| 8 | ## Request |
| 9 | |
| 10 | $ARGUMENTS |
| 11 | |
| 12 | If the request above is non-empty, the user invoked `/canvasflow` explicitly - build an HTML artifact for that request now, following the workflow below. |
| 13 | If it is empty, infer what to visualize from the conversation. |
| 14 | |
| 15 | ## When to use |
| 16 | |
| 17 | Use canvas-flow when the user asks for a visual artifact, HTML explainer, interactive prototype, review surface, product or technical plan, comparison, report, or browser-based feedback loop |
| 18 | |
| 19 | ## Workflow |
| 20 | |
| 21 | 1. Create the HTML artifact (default location `.canvasflow/<name>.html` in the working directory). |
| 22 | 2. Run `npx -y @menukfernandoo/canvas-flow <html-file>` to open or resume a review session in the browser. |
| 23 | 3. Run `npx -y @menukfernandoo/canvas-flow poll <html-file>` to long-poll for the user's annotations, queued prompts, and browser-reported `layout_warnings`. |
| 24 | The poll stays silent until the user acts or the real browser reports fresh layout warnings - leave it running, never kill it. |
| 25 | If your harness limits how long a foreground command may run, run the poll as a background task; if it gets killed or times out anyway, just re-run it - queued feedback is never lost. |
| 26 | 4. If poll returns `layout_warnings`, follow the returned `next_step`: fix and re-check fresh error-severity findings, but proceed with a note instead of looping when every current warning is persistent or low-severity. |
| 27 | 5. Apply human feedback, then poll again with `--agent-reply "<message>"` to reply in the browser and keep the loop going. |
| 28 | 6. Run `npx -y @menukfernandoo/canvas-flow end <html-file>` when the review is finished. |
| 29 | 7. If the user ends the session from the browser instead, `npx -y @menukfernandoo/canvas-flow <html-file>` refuses to reopen it and says so - only pass `--reopen` when the user asks for further review or something genuinely important needs their visual attention. Otherwise deliver remaining updates directly in this conversation. |
| 30 | |
| 31 | ## Visual guidance |
| 32 | |
| 33 | - Use visual hierarchy to make the most important decisions, risks, tradeoffs, and next actions obvious at a glance |
| 34 | - Use visual structure such as sections, cards, tables, diagrams, annotated snippets, and side-by-side comparisons instead of long prose |
| 35 | - Choose typography, spacing, color, and layout deliberately so the artifact has a clear point of view |
| 36 | - Prevent horizontal overflow at every nesting level: nested grid/flex children also need minmax(0, 1fr) tracks and min-width: 0, especially when badges, labels, or status text use wide pixel or monospace fonts; wrap, truncate, or contain long unbreakable text deliberately |
| 37 | - When the artifact would describe existing or current UI or state, show it instead: capture screenshots of the real pages (run the app read-only if needed) and embed them, rather than explaining the current look in prose; reserve prose for what cannot be shown such as rationale, trade-offs, and open questions |
| 38 | |
| 39 | ## Playbooks |
| 40 | |
| 41 | Run `npx -y @menukfernandoo/canvas-flow playbook <id>` for focused, detailed guidance on any of these. |
| 42 | One artifact often combines several playbooks (for example a plan that includes a comparison and a diagram), so MUST open each matching playbook before writing HTML. |
| 43 | For flows, architecture, state, or sequence diagrams, do not hand-build boxes-and-arrows from div/flexbox; open the diagram playbook and use Mermaid unless SVG is needed for richly annotated nodes. |
| 44 | |
| 45 | - `diagram` - Map relationships, flows, state, and architecture |
| 46 | - `table` - Turn dense records into scan-friendly review surfaces |
| 47 | - `comparison` - Show options, tradeoffs, and current vs target behavior |
| 48 | - `plan` - Explain a product or technical plan before implementation |
| 49 | - `code` - Render source code, code files, patches, PR diffs, and before/afte |