Stats
Actions
Tags
From quality-strategy
Turn a finished quality strategy into a shareable, glanceable visual artefact — a bespoke self-contained SVG or HTML file designed for a stated audience and purpose. Describe the view you want ("a tweetable summary of where quality stands", "a story of our quality year, told frame by frame", "a dashboard of just the payment risks for my standup") and it designs and builds that view from quality/strategy.md, poster-first, then scores itself against seven principles before presenting. Presets — social card, risk heatmap, multi-frame story, interactive dashboard, quality radar — are worked examples, not a menu. Use after /quality-strategy has produced and reviewed quality/strategy.md, when you need the strategy in a form someone can take in at a glance, screenshot, or share.
How this skill is triggered — by the user, by Claude, or both
Slash command
/quality-strategy:quality-artefactsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A finished `quality/strategy.md` is honest, but it's several hundred lines of markdown — built to be *used*, not to be *glanced at* or *shared*. This skill turns it into the missing form: a **single self-contained SVG or HTML file** a person can open, grasp in five seconds, screenshot, tweet, or walk into a standup with. The bar it aims at: the owner should *feel seen* — and be keen to share it.
A finished quality/strategy.md is honest, but it's several hundred lines of markdown — built to be used, not to be glanced at or shared. This skill turns it into the missing form: a single self-contained SVG or HTML file a person can open, grasp in five seconds, screenshot, tweet, or walk into a standup with. The bar it aims at: the owner should feel seen — and be keen to share it.
It is a generator, not a poster maker. There is no fixed template being filled in. The user describes the view they want — in their own words, for their own audience — and you design an artefact for that request and that strategy: the layout, the emphasis, the visual language, all chosen to fit. Two users asking for "a dashboard" of two different strategies should get two visibly different artefacts, because their strategies, audiences, and risks differ. The named presets further down are worked examples of design moves that have worked — start from one when it genuinely fits, but the headline capability is the freeform path.
Like /strategy-variants, this is a post-processing step: it runs after the strategy is finished and reviewed, never edits quality/strategy.md, and produces derived views with the strategy as the single source of truth. Where /strategy-variants re-writes the strategy in prose for a named reader, this skill re-renders it visually — and every honesty rule that binds the prose variants binds the pictures too.
This skill is part of the quality-strategy plugin. Before anything else, resolve two absolute paths and use them throughout:
${CLAUDE_PLUGIN_ROOT} (Claude Code expands this to an absolute path when it loads this file; read it off and note it down). The grounding file this skill reads — PHILOSOPHY.md — lives under it, as does the plugin manifest whose version you record per run.$PROJECT_DIR/quality/, and the artefact you produce goes to $PROJECT_DIR/quality/artefacts/.File references below use the $PLUGIN_ROOT and $PROJECT_DIR placeholders. Substitute the resolved absolute paths before you act on them. The Read tool does no variable expansion and resolves relative paths against the current working directory, not this skill's directory — so an unsubstituted placeholder or a bare relative path will fail.
/quality-strategy (and ideally its review) has finished — when the user wants the strategy in a glanceable or shareable form: for a tweet, a standup, a stakeholder meeting, a README badge-with-substance, a wall.quality/strategy.md, whoever wrote it.If $PROJECT_DIR/quality/strategy.md doesn't exist, stop — there is nothing to render; point the user to /quality-strategy.
Do not run it on an unfinished or unreviewed strategy: a beautiful rendering of a broken strategy is a confident-looking, misleading picture — worse than the document, because pictures are believed faster than prose. If the strategy isn't done, say so and point back to /quality-strategy / /quality-strategy-review. (If the user knowingly wants a draft visualised anyway, build it, and make the artefact itself say Draft — strategy not yet reviewed where no crop can remove it.)
$PLUGIN_ROOT/PHILOSOPHY.md — in particular quality is value to someone who matters (an artefact is pitched at a specific someone), make confidence visible, and don't use spurious precision. The artefact is the strategy's public face; if it launders away the uncertainty, it betrays the document it renders.version field from $PLUGIN_ROOT/.claude-plugin/plugin.json and note it — every run records the version it executed against (see step 5).$PROJECT_DIR/quality/strategy.md end-to-end — not just the TL;DR. The detail is where the honest qualifiers live ("M for the upload path, L for restore"), and those qualifiers are exactly what a lazy rendering flattens away.quality/test-strategy.md, quality/tooling-strategy.md, and any quality/strategy-one-pager.md / quality/strategy-client.md variants. They are optional enrichment: a request like "show what we're building next" draws on the tooling strategy's build plan; a client-facing artefact should follow the client-safe variant's framing where one exists.Everything this skill knows about a good artefact reduces to seven principles. They are the design brief during step 2 and the scorecard in step 4 — score each 0 (fails), 1 (partial), or 2 (holds), on the rendered output. Three are HARD GATES: an artefact is not presented until each gate scores 2; fix and re-render instead. One law stands above all seven: honesty beats shareability — when a principle's pursuit would shade the truth, the truth wins.
Could no other project mistake this artefact for theirs? The project's own voice, its own visual identity (a plant app earns botanical warmth; a payments tool, ledger austerity), the strategy's own sharpest sentences quoted back at the owner ("salt in the wound", "the users we burned" — mine the doc before writing new lines). Choose a deliberate palette (3–5 colours) and one or two typefaces. Anti-patterns: a template with the nouns swapped; assistant-prose tics; the generic-AI look — evenly-spaced gradient boxes, the same purple-on-white, emoji as decoration — redesign rather than polish it. The banned-tics list — honest/honestly as filler, actually, simply, crucially, essentially, delve, deep dive, journey, game-changer, it's worth noting, let's be clear — is grepped at scoring time; a hit survives only where it does real work (a legend's "honest confidence" names a property of the data; a kicker reading "MEASURED HONESTLY" does not).
One boundary the other way: the anti-hyperbole rules (principle 3 and the world-claim check) bound claims, never register — do not let them flatten the voice. Evidence-backed savagery is a feature: "The best-tested code doesn't run", "2/2 apparent instruments turned out to be decoys" land as a roast with receipts, and owners share that register because it signals command of their own codebase. Hyperbole means asserting beyond the evidence; a burn fully covered by the doc is just the truth, well-lit — so sharpen the tone to exactly the limit the evidence allows, and no further.
Cover every word on the rendered frame: the point must still land from the shape alone. A dramatic void says "we can't see here" better than a sentence; the chart IS the quote. Text tells the story — the so-what — and never describes the graphic; every legend term maps to exactly one visual treatment on its frame (instance from review: two hatched elements with different meanings on one frame made the legend meaningless — one void treatment per frame). If the text carries the meaning, the design fails this gate.
Every factual claim carries its evidence at the strength the source doc gives it — measured, surveyed, believed, unknown — and compressing a hedged claim into a bald fact is the honesty law broken. The evidence is usually the better line anyway: "of the one-star reviews that say anything, dead plants dominate — most-named cause, a reminder that never arrived" beats "the #1 reason its users quit". Operationally: an Unknown or Gated dimension (unjudgeable until an oracle — something that can judge the output — exists) is never painted on the good-to-bad colour ramp (hatching, holes, ?, an off-ramp hue — and boldly, not as a timid side note); over-confident actuals render at their evidence, not their vibe; confidence appears in the doc's own coarse vocabulary, never percentages it doesn't contain; nothing is asserted the body doesn't support, and a scoped view's title says its scope. For client- or public-facing artefacts, /strategy-variants' omit-never-lie rule applies on top — and where keeping client-affecting honesty and dropping internal candor pull against each other visually, surface the tension to the user rather than quietly choosing.
One plain sentence says what the project is and what the picture shows, before anything else asks to be understood — in a multi-frame story it opens frame 1's caption, and every other frame carries a short project tag (e.g. in its corner provenance line) so a lone screenshot still names the project. Every visible sentence survives zero project context and zero framework vocabulary: "nobody can measure this yet" beats "no oracle exists"; plain dimension names, never bare ids or release tags. This binds every surface a reader can reach — not just the share surface, but every expanded detail panel, tooltip, drawer, or secondary view a tap or hover opens: coordinates never travel without their names, anywhere a reader can reach them on a rendered surface. A bare (A, B, D, E, G) or (LN-6) in a tapped-open panel fails exactly as it would in the hero — write the name first and the coordinate in tow: "build delivery telemetry end to end (action A)" (instance from review — FAIL: an expanded panel reading "every oracle in the plan (A, B, D, E, G)", plus a "(LN-6)" test-strategy label the artefact defines nowhere; PASS: the names lead and the letters trail — "…delivery telemetry, the photo round-trip, the backup-restore drill (actions A, B, C)" — and the offline run names its drill rather than citing a bare (LN-6)). The text budget enforces the rest, and it is hard on any share or hero surface — a card, a story frame, the first viewport of a dashboard: titles ≤8 words; that surface carries its title, its one hero stat, and at most one caption of ≤2 sentences — no third sentence and no body paragraph reaches it, however well the prose works (instance from review — FAIL: a 3-sentence body paragraph rode the first viewport of a dashboard because the storytelling was strong; PASS: its lead sentence stayed as the ≤2-sentence caption, the remainder dropped into the expanded panel). Principle 6 buys no exemption: a story that needs three sentences earns them a layer down (a tapped-open panel, a lower section), not on the poster. On every other surface the budget is axis-label length, paragraphs banned.
Gaps are unmissable AND framed as self-knowledge with a first move attached — the owner shares it because of the honesty. Fails at both poles: inflation (gap painted fine) and confession (failed-audit vibes). A first-move frame passes the plain test: what we'll do + why a user would notice (instance from review — FAIL: "build the delivery ledger", an internal artifact name; PASS: "First: count every reminder we send — so a silent miss shows up in our data, not as your dead fern.").
Hero lines carry content tied to the user's stated goals or a stakeholder's delight/disappointment story — never contentless drama (instance from review — FAIL: "The thing that kills us is invisible."; PASS: "We back up. We never rehearse." — the disappointment is in the line). The paste-test: a title that would survive on another project's artefact has no content. The model frame ties its fact to a named someone's lived moment — "a dead fern, a one-star review naming the fern, a quiet uninstall" is a frame; "reliability: low" is a row. Walk the strategy's three-lens entries (delight / good-enough / dealbreaker) for the lived stories before reaching for abstractions. There should be one synthesized line the owner would quote out loud — the revelation. Revelations come in two tiers. Good: the half-knew truth — something the doc states but the owner never saw said this starkly. Above it sits the never-realised-you-cared truth — something the owner's own goals imply but they never articulated; the find the strategy work delivered back to them as a moment. When the source doc contains one of those, it is hero material: the title leads with it — the revelation becomes the hero line itself, with the supporting stat as a band beneath it. A generic framing title sitting above a revelation that's been demoted to a caption or left to be inferred is the named failure — the reader's eye lands on a scorecard, not the insight (instance from review — FAIL: a share card titled "What we've proven, and what we can't see" (framing) with the real inversion "our best-tested code isn't what kills the plant" dropped into the caption and left to be inferred from tile adjacency; PASS: that inversion promoted to the title, the quotable line as its deck, the 2/2/2 tally a supporting band). Don't bury it among the stated facts.
The headline frame stands alone as a phone screenshot; one takeaway lands in three seconds, with layers that reward attention without competing — not a wall of equal-weight cards. The poster is the unit of design: one striking graphic, one hero stat (every strategy contains one staggering true number — find it, set it in poster type; jaw-dropping-but-true is the house move), one ≤8-word title. More than one chart's worth of message → more than one frame: each frame a self-contained poster, never sharing its viewport with another frame's message, the sequence telling the arc. Colour is part of craft: a committed palette, summary grids with state-tinted tiles (instance from review: never white cards with coloured words), the radar done well — colourful, plain names on the axes, unmeasurable axes as dramatic voids. Weight this principle by declared purpose: a tweet card must nail it; a working dashboard may trade some for depth.
Shipping skills instead of code means there is no hosted layer between this skill's output and the user — no server to sanitise output, no release pipeline to catch a bad render. Output quality must hold however the user runs the skill, on whatever machine, so the self-review here is not hygiene: it is the product's quality gate. Four checks join the principle scoring, each added after a real shipped bug:
<meta charset="utf-8">; a raw SVG opens with an explicit XML declaration (<?xml version="1.0" encoding="UTF-8"?>) — a browser loading an .svg directly cannot be relied on to assume UTF-8. At review, open the artefact every way a user plausibly would — from file://, served, the .svg loaded directly — and look for mojibake or glyph breakage. Shipped bug: em-dashes and apostrophes rendered as "’ / —" because an SVG shipped without a charset declaration.From the user's request, you need three things before you can design:
/strategy-variants.Pre-read the request and the strategy, form your best hypothesis for all three, and — if any of them is genuinely ambiguous — ask once: a single message presenting your read and the open choices. Then build. Don't interrogate in rounds, and don't silently guess on audience when the request could be internal or external — that choice changes what principle 3 requires. If the user is present and answers, follow the answer; if they've said "just build something good", or you asked and got no reply, proceed on your stated hypothesis and record the choices as assumptions.
When the user brings no brief at all — a bare /quality-artefacts, or "what can you make?" — don't guess a default view. Open the gallery, with the freeform path headlined above everything else: "Describe the view you want — who's it for, what should land in five seconds — and I'll design it for your strategy." Beneath that headline, offer the worked examples as pickable starting points, each named with its move: a social card (one stat, big type, for a tweet), a risk heatmap (compact and brutal, for a skeptical room), a multi-frame story (the strategy's arc told frame by frame — and say it can roast-with-receipts), an interactive dashboard (a standup anchor), a quality radar (where do we stand overall?). They are starting points to adapt and design from, not a menu of fixed outputs — picking one still runs the full design pass against this strategy. This pickability exists only for the no-brief case: when the user did bring a brief, the presets are never routing keys — a request is a design brief to design for, not a key that selects a template, and the "worked examples, not a menu" doctrine holds for that path exactly as before.
When the ask carries no tone or register signal — neither the request nor the audience implies how sharp to be — elicit register rather than defaulting to austere. A bland prompt must not yield a bland artefact. Either fold the register choice into the gallery moment above, or ask it in the same single clarifying message: "straight for stakeholders, or shall I roast you? — receipts either way." Permission to want something fun, silly, or savage is granted explicitly, because most users don't know it's on offer and won't ask unprompted — the skill names it. (A "roast" cashes out to the evidence-backed-savagery licence in principle 1: sharpened to exactly the limit the doc supports, never beyond.) Bland-in must not become austere-out.
Design the phone-screenshot frame before anything else: the graphic that carries the message (principle 2), the hero stat and story line (principles 6 and 7), the project's visual identity (principle 1), how the uncertainty will be drawn — decided now, not as an afterthought (principle 3). Whatever interactivity or detail the request needs wraps around that frame, a layer down. Decide one-frame-or-several (principle 7), and what data carries the message: usually some slice of the risk map (Part 6) with its confidence ratings, the Dealbreakers (the must-never-fail bars), the headline from the TL;DR, the non-goals when the audience might mistake them for gaps. Resist completeness — the artefact that shows everything shows nothing. (If a frontend-design skill is available in the session, use it; the bar stands either way.)
$PROJECT_DIR/quality/artefacts/<descriptive-slug>.html or .svg. Create the directory if needed. The slug names the view: relaunch-risks-card.svg, not output1.svg. A re-run of the same view after a strategy revision rewrites the same slug in place from the current strategy — that refresh, not accumulation, is how the views stay living. Archive before overwrite: when the slug already exists, first move the old file to quality/artefacts/archive/, renamed with the version and date stamped in its own data island (e.g. relaunch-risks-card--v0.3.0--2026-06-11.svg) — the stamps make every archived artefact self-identifying. Never silently overwrite: the archive is what lets a user lay two strategy revisions side by side and see the gaps close. A multi-frame story is still one artefact and one file. If the user asked for several views, that's several runs of steps 1–5, each with its own design pass.<meta charset="utf-8"> in HTML; <?xml version="1.0" encoding="UTF-8"?> as the first line of a raw SVG.file:// with the network cable pulled. Fonts: good system stacks, or an embedded data-URI subset only if the design truly demands it.<text> elements). HTML for the interactive and multi-frame (inline CSS and vanilla inline JS only, no frameworks; for a story, full-viewport frames with CSS scroll-snap screenshot clean on their own; interactivity serves the reading, never decorates it).<script type="application/json"> data island in HTML, a <metadata> block in SVG — so an agent can re-derive what the artefact shows without parsing pixels.Review the rendered artefact, not the source. If a headless browser is available (Chromium via --headless --screenshot=<png> --window-size=<WxH> is common), render and read the screenshot yourself — every frame of a story; overflow, collisions, and a wrong first impression are visible in a render and invisible in markup. Open the artefact every way a user plausibly would — from file://, served, the .svg loaded directly — watching for mojibake or glyph breakage (render integrity). And judge the render aesthetically — spacing, alignment, balance, overflow: would a designer wince? (layout quality). Where the artefact depicts the product, check every depicted detail against the claim it serves (depiction fidelity); where it makes claims about rivals or the world, trace them to the doc or cut them (world-claim evidence). Verify mechanics as you go: no external references (http://, https://, protocol-relative // in src/href/url()/@import/xlink:href), well-formed markup (xmllint --noout, or python3 -c "import xml.dom.minidom,sys; xml.dom.minidom.parse(sys.argv[1])" <file>), the inline JS re-read.
Then walk the seven principles and score each 0/1/2 with a one-line justification. Read every visible sentence twice on the way — once as the owner (principles 1, 5, 6: does it get us? would I share it? would I quote it? — and where the doc held a never-realised-you-cared revelation, does the title carry it, or does a generic framing header sit above it?), once as a total stranger (principles 2, 4, 7: cover the text; pretend you've never heard of the project or the framework) — and do that stranger read on every surface a reader can reach, expanding every collapsible panel, tooltip, and drawer, not just the first viewport. Two gate-4 sweeps run on the rendered output: (a) share-surface sentence count — render the share surface / first viewport and confirm it carries only its title, hero stat, and one ≤2-sentence caption; a third sentence or any body paragraph there fails the budget, so fix the layout (drop it a layer down) and re-render; (b) coordinate-name sweep — open every expanded/secondary panel and confirm no coordinate (action letters like (A, B, D, E, G), dimension ids, cross-doc labels like LN-6) appears without its plain name. Principle 3's score comes from the mechanical provenance walk: every factual claim traced to the doc and checked for evidence strength. Run the other sweeps where their principles name them: the tics grep (principle 1), the legend-uniqueness check per frame (principle 2). If no renderer exists in the environment, score against the source with that limitation named — record "not rendered" in the run notes and the one-line self-score, and ask the user to glance at the artefact before sharing it.
The three hard gates — principles 2 (graphic carries it), 3 (claims wear evidence), and 4 (stranger-ready) — must each score 2 before the artefact is presented. Anything less: fix, re-render, re-score. Don't ship on the first draft's first render. Non-gate principles below 2 are a judgment call — fix them or name the shortfall to the user.
$PROJECT_DIR/quality/artefacts/.run-notes.md (append-only — create if absent, never rewrite past runs): date, the user's request, the artefact path, the plugin version executed against (from $PLUGIN_ROOT/.claude-plugin/plugin.json), the seven scores with their one-line justifications, and the assumptions made. Also stamp them into the artefact's machine-readable block (the JSON data island in HTML, the <metadata> block in SVG): "skillVersion", and "selfScore" carrying the seven 0–2 scores plus the total — invisible on the surface.$PROJECT_DIR/.skill-feedback.md, never into the artefact or the strategy.Five shapes that have worked. Each names the design move so you can adapt it — none is a template to fill in, and a freeform request that fits none of them is the skill working as intended. (When the user brings no brief, these double as the pickable gallery of step 1 — starting points to design from, never routing keys for a user who did bring one.)
Also derivable: per-stakeholder cards ("what does good mean for the agents?"), a before/after gap tracker across two strategy revisions, a one-dimension deep-dive for a decision meeting.
quality/strategy.md (and existing companions) read end-to-end, not skimmed; the plugin version noted..html or .svg was written under quality/artefacts/ (new, or the same view refreshed in place — with the old version moved to archive/ first, never silently overwritten), named for its view; it renders offline from file:// with zero external requests.quality/artefacts/.run-notes.md (request, version, scorecard, assumptions) and the data island carries skillVersion and selfScore.quality/strategy.md untouched.quality/artefacts/<descriptive-slug>.html or .svg — one bespoke, self-contained artefact per run.quality/artefacts/archive/<slug>--v<version>--<date>.* — the prior version, when the run refreshed an existing view.quality/artefacts/.run-notes.md — the appended run record (request, skill version, scorecard, assumptions).quality/strategy.md and companions are not modified by this skill.Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub tollens-ai/quality-strategy-skills --plugin quality-strategy