prettify
Skill1 starsChanged 4 months agoApache-2.0View on GitHub
Use when the user wants to turn a message, document, or provided text into a polished, self-contained visual HTML infographic saved to a local file.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- yournextstore/yournextstoretheir own version, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- yournextstore/yournextstore★ 5.5ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- feature-development-workflowSkill
- gh-release-train-mergeSkill
- github-project-boardSkill
- implement-issueSkill
- nist-buildSkill
- nist-designSkill
- nist-planSkill
- nist-releaseSkill
- nist-respondSkill
- nist-testSkill
- plan-to-issueSkill
- pr-from-branchSkill
- release-candidate-reviewSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
If the user provides or points at text/a file, that's the source.
- Very specific: line 26
One
.htmlfile: All CSS in a single inline <style>. - Very specific: line 72
Semantic color & labeling: If you color-code, define the meaning.
- Distinctive: line 101
After writing the file, keep it short:
- Distinctive: line 110
Don't paste the HTML into chat and don't re-summarize the source.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Prettify
Turn source content into a single, self-contained HTML infographic that looks like it was designed on purpose — then hand back the command to open it.
This skill deliberately gives you no fixed template. Don't fill in a prescribed layout. Read the content, decide what it's really about, and design the page that best communicates that. Trust your taste. The bar is "a polished product/landing infographic," not "markdown with nicer fonts."
Source content
- If the user provides or points at text/a file, that's the source.
- Otherwise use the last substantive assistant message.
Preserve every meaningful point. You may reorder, group, retitle, and condense for visual flow — but never invent facts or quietly drop real content.
The one hard constraint: self-contained & offline
- One
.htmlfile. All CSS in a single inline<style>. No external anything — no CDNs, no web fonts, no remote images, no network requests. It must render perfectly with no internet. - Favor pure HTML + CSS + inline SVG. Reach for a little inline JS only if it genuinely serves the content (most infographics need none). Keep it print-safe and responsive (stack gracefully on narrow screens).
Everything below is about quality, not rules to check off.
What makes one of these good
Think about what elevated the best versions of this:
- Design, not decoration. A cohesive visual system — a small palette (CSS
variables help), consistent spacing, a clear type hierarchy (eyebrow → headline →
subhead → body), generous whitespace, restrained rounded cards/shadows. Always
use a dark colour scheme — a deep, near-black background (not pure
#000), light/desaturated body text, slightly raised dark cards with subtle borders, and one vivid accent chosen to pop against the dark. Stay dark regardless of subject; tune the accent to the mood. One accent, used with intent. Diagrams that carry real information — this is what separates a great infographic from a styled list, and it's the bar you're most likely to miss. Build at least one diagram that is bespoke to this content — one that would make no sense pasted onto a different topic. Let the content choose its shape:
- a process or decision → a stepped flow with the branch conditions labeled, not just boxes;
- "X calls/maps to Y" → a two-column wiring/mapping diagram with connectors;
- categories or impact → a color-coded map with a legend so color means something;
- tradeoffs → before/after or side-by-side panels;
- magnitudes → honest stat cards. Build these from HTML/CSS/SVG; make them legible, not ornamental. Whenever you color-code, draw the legend — undefined color is decoration.
Anti-pattern to refuse: a row of numbered badges + a two-column tick-list + a few generic cards as the centerpiece. Those are reusable widgets — they look identical regardless of topic, so the page reads as a template even though you wrote no template. A checklist of the page's own section titles (or of this skill's own constraints) is decoration, not a diagram. Litmus test: if your main visual would survive a find-and-replace of the subject, it isn't carrying information — redesign it.
- Scannable hierarchy. Someone should grasp the gist in ten seconds and be able to drill in. Sections with clear headers, lead-ins, and visual rhythm.
- Semantic color & labeling. If you color-code, define the meaning. Use chips/
tags/
<code>for identifiers, paths, and statuses. - Restraint and polish. Cohesion beats novelty. Give the page one clear focal point — decide what the eye should hit first, and keep everything else calm enough that it can. On a dark canvas saturated colour is loud; spend it like money. When you colour-code a field whose values are mostly "baseline/unchanged," render those quietly (low saturation, close to the background, a small dot or thin edge) and reserve full-strength colour for the exceptional or changed value. If every cell is bright, nothing stands out and the reader doesn't know where to look. Align things. Don't crowd. Make it feel finished.
Match ambition to the material: a dense plan deserves several custom diagrams; a short note might be one elegant hero plus a single sharp diagram of its core idea. Scale the amount, never the craft — even a thin source earns one genuinely bespoke visual, not a grid of stock cards. Don't force structure the content doesn't have, and don't flatten structure it does.
Output
Save to /tmp with a descriptive, timestamped name:
TS=$(date +%Y%m%d-%H%M%S)
OUT="/tmp/prettify-${TS}.html"Final response
After writing the file, keep it short:
- One sentence naming the file and what you made.
- A fenced
bashblock with exactly the open command, e.g.:
open /tmp/prettify-<timestamp>.htmlDon't paste the HTML into chat and don't re-summarize the source.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

