Stats
Actions
Tags
From ank
Produce a visual HTML implementation plan for a feature BEFORE writing any code. Use this skill whenever the user invokes /ank:visualise-plan, asks for an "implementation plan", says "plan this out before you build it", asks you to "visualise the plan", or otherwise signals they want to review the approach as a document before code is written. The skill assumes all clarifying questions about the feature have already been answered in this conversation — its job is to crystallise that context into a single reviewable HTML file at docs/plan/<feature-slug>.html and then HARD STOP, waiting for the user to type "approved" (or send edits) before any implementation begins.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ank:visualise-planThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The user has just finished walking you through what they want to build. You probably know more about this feature right now than at any later point in the conversation. Your job is to **freeze that understanding into a single HTML document** they can scroll through on a phone or laptop, push back on, and only then green-light.
The user has just finished walking you through what they want to build. You probably know more about this feature right now than at any later point in the conversation. Your job is to freeze that understanding into a single HTML document they can scroll through on a phone or laptop, push back on, and only then green-light.
You are not implementing yet. You are not allowed to implement yet.
By the time this skill triggers, the user has already answered the questions you needed answered — about the feature's behavior, constraints, edge cases, scope. Do not re-interrogate them. If something genuinely critical is missing, write the plan with your best assumption, flag the assumption in the Future scope section, and let the user correct you in their review pass. Asking another round of questions before producing the plan defeats the point of the skill.
A single self-contained HTML file at:
docs/plan/<feature-slug>.html
<feature-slug> is a short kebab-case name for the feature (e.g. comment-threads, bulk-export, oauth-pkce). If the user gave you a name, use theirs.
The file is self-contained: no external CSS, no external JS, no image hosts. Everything inline. The reviewer should be able to open it offline.
A starter template lives at references/template.html in this skill. Read it before writing. It defines the visual style — the Botanical Almanac aesthetic (deep forest-green ink on bone paper, terracotta accent), monospace headings on serif body, the bubble row, and the architectural SVG conventions — and you should match that style precisely. The template is a scaffold, not a straitjacket: add sections if the feature needs them, drop a section if it genuinely doesn't apply (but say why in a one-liner rather than silently omitting).
A row of small rounded chips showing the at-a-glance stats. Pick the ones that actually matter for this feature; typical ones:
Aim for 4–6 bubbles. Anything that takes more than a few words doesn't belong in a bubble — put it in a section.
Slice the work into independently reviewable chunks, rendered as a timeline: left-aligned date column, vertical rail with bullet dots in the middle, content on the right. The first milestone (the foundation slice that's actively about to start) uses a filled green dot; later ones add class="upcoming" to the .milestone for the terracotta-ring dot.
For each milestone:
.when ("Week 1 · Mon–Tue", or just "Slice 1")<h3> inside .bodyOrder them so each slice is shippable on its own (even if behind a flag). The reviewer is going to use this section to decide whether to break the work into separate PRs.
This is the section the reviewer cares about most. It shows how the new feature plugs into the existing codebase — which existing modules get called, what new modules get introduced, and the direction of data and method calls.
Render it as an inline SVG inside the .flow container. The visual language is architectural: thick rectangular boxes, deliberate placement, no decoration, no curves-for-curves'-sake, no soft shadows on diagram elements. The template provides these classes — use them:
class="node" (ink stroke, 2.5px). Always show the ones the new feature touches.class="node-new" (terracotta stroke, 2.5px). Visually distinct from existing.class="node-label" (mono, 12px) — the module/file name (e.g. <CommentComposer>, comments.create).class="node-sub" (mono, 10px) — its package or path (e.g. apps/web, packages/api).class="stroke-solid" — synchronous request/response, direct method calls.class="stroke-dash" — async, fire-and-forget, realtime fan-out, queued work.class="edge-label" — the operation name ("optimistic insert", "broadcast", "INSERT").Layout rules:
If the feature has two distinct paths (write path + read path, or sync + async), put them side by side in the same SVG with a short legend underneath. The template already includes a default legend ("Solid = request/response. Dashed = async / fire-and-forget. Terracotta border = new module.") — keep it, but feel free to add a feature-specific line.
A reviewer should be able to trace a request from UI → API → persistence → fan-out by following the arrows, and know which files to open during code review.
A visual of what the feature looks like to a user. Render it in plain HTML/CSS inside the .mock container — not a screenshot, not an external image. Lo-fi is fine; pixel-perfect is wasted effort here. Goals:
For purely backend features, skip this section but say so explicitly with a one-line "No UI surface — backend only."
A flat list, grouped by operation. For each file:
add / update / remove)Don't list every test file or every type definition — list the files a reviewer should open to understand the change. If a file's only purpose is "barrel export," skip it.
The 1–3 snippets most likely to be done wrong if left unspecified. Examples of what belongs here:
Examples of what does NOT belong here:
Each snippet gets a caption with its file path, then a <pre class="code"> block. Keep snippets short — under ~25 lines each. If a snippet is longer than that, it's probably doing too much.
What's deliberately out of scope, what assumptions you made, and what's worth revisiting after v1. For each item:
This is also where you flag any assumption you had to make because the conversation didn't pin it down. Flagging it here is much better than blocking on another round of questions.
The template at references/template.html is the source of truth for style. The palette and treatment is fixed — do not improvise alternate colors or "modernize" the look:
#f5f0e1 (bone paper) · panels #fbf8ec (slightly lighter) · prompt panel #f1ead5 · bubbles #fff#1a2e1f (deep forest green) for all primary text and strokes#5a6b5a (muted green-gray) for secondary text, sublabels, captions#d8cfb4 — thin 1px borders for cards/panels/dividers#b4541a (terracotta) — used only for: the Prompt label, new-module borders in the data flow, upcoming-milestone dot rings, and optional code keyword tint. Don't sprinkle it elsewhere."Iowan Old Style", "Palatino Linotype", Palatino, Georgia, serif). H1 is 40px/600, H2 is 26px/600, H3 is 17px/600 — the serif weight does the work. Monospace (ui-monospace, "JetBrains Mono", Menlo, monospace) is reserved for: the eyebrow line, section-number chips, bubble labels/values, file paths, tags, code, SVG text, and <code> spans.--rule border, 8–12px radius, no offset shadow. The previous "clay shadow" look has been retired in favor of cleaner cards..prompt-box (soft paper-soft background, rounded) with a small terracotta uppercase "PROMPT" label above the paragraph. Not a left-bar italic quote.01, 02, …) render as a small monospace chip with --tag-bg background, placed inline next to the <h2> via a .section-head flex row.add → #2d5938 (deep green), update → #856104 (amber), remove → #8a3320 (rust).After you write the file:
Written: docs/plan/<feature-slug>.html.Review the plan and reply with "approved" to start implementation, or send edits and I'll revise the plan.
If the user replies with anything other than an explicit approval ("approved", "ship it", "go ahead", "lgtm proceed"), treat it as edits to the plan — revise the HTML and stop again. Repeat until they approve. Only then proceed to implementation.
This stop is not negotiable. If the user prepends "skip the plan, just build it" to their initial request, that's a separate flow and this skill shouldn't have triggered in the first place — back out gracefully.
If you find yourself wanting to ask the user "what about X?" before writing the plan, ask whether X is something the plan itself can surface. Usually it is — write the plan with your best assumption, put the assumption in Future scope, and let the user correct it during review. The whole value of this skill is that the HTML is the conversation; questions you ask in chat are questions that won't be visible when the user scrolls back to the plan later.
npx claudepluginhub ananthanandanan/skills --plugin ankGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.