figure-audit
Skill3 starsChanged 3 months agoMITView on GitHub
Decide whether a given article should get a figure at all — additive, performative, or none — against a five-type taxonomy where each type has a hard entry requirement. Use when Shane says "should this post have a diagram", "audit these articles for figures", "does this need a chart", or before commissioning any illustration for written work. Do NOT use to build the figure once approved (use the design artifact skills), to audit an existing figure's styling, or for social artifacts, which are decorative by design.
In this repository18 other files it gives its agents.
- design-blog-heroSkill
- design-business-cardSkill
- design-carousel-slideSkill
- design-instagram-postSkill
- design-landing-pageSkill
- design-linkedin-postSkill
- design-link-in-bioSkill
- design-newsletter-headerSkill
- design-planSkill
- design-quote-cardSkill
- design-systemSkill
- design-twitter-cardSkill
- design-ui-componentsSkill
- design-youtube-channel-artSkill
- design-youtube-thumbnailSkill
- pdf-htmlSkill
- pdf-paginatedSkill
- screenshot-htmlSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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
- Very specific: line 16
Prefer none. Reaching for a figure to fill space is the failure mode.
- Very specific: line 42
Read the project's DESIGN.md figure section — if it defines a different taxonomy, that file wins over the table above.
- Distinctive: line 43
Read the article in full. Not the intro, not a grep.
- Distinctive: line 44
Test each of the five types against its entry requirement, in order.
≈ “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
Skill: /figure-audit [article path]
Answer whether a figure earns its place, applying the standard that most articles should get none — the value is in the rejections, not the approvals.
Don't: invent the data a figure would need; if the article does not contain the numbers, the verdict is not additive, full stop. Don't approve a figure that restates the thesis in boxes — that is the exact failure this guards against. Don't audit several articles in one agent; it starts pattern-matching the second against the first and stops reading.
The standard
If the page is no worse without the figure, cut the figure.
Prefer none. Reaching for a figure to fill space is the failure mode.
The taxonomy
A figure may ONLY be one of these five types, and ONLY if it meets its entry requirement.
| Figure | Use it for | REQUIRES |
| Dimensioned diagram | A claim about proportion, or where a line sits | Two regions and a measured split you can defend |
| Cycle | A process with a genuine return edge | Three or more stages AND a real loop back |
| Record chart | A claim about the author's own history or data | A file it reconciles to, named in the caption |
| Detail | Clarifying one step of an assembly | A step that is actually unclear without it |
| Footed table | Anything with numbers, including pricing | Figures that add up, shown adding up |
Hard limits: max one figure per article, max three callouts per figure. Zero figures is a perfectly good answer.
Rules
- No invented data.
groundedInmust quote or cite something actually in the article. - Record chart needs a real file it reconciles to. Do not claim reconciliation you cannot verify.
- Cycle needs a genuine return edge. A linear process with steps is not a cycle.
- Dimensioned diagram needs a defensible measured split — an explicit percentage or ratio stated in the article. A vibes-based split is not defensible.
- Prefer
none.
Steps
- Read the project's
DESIGN.mdfigure section — if it defines a different taxonomy, that file wins over the table above. - Read the article in full. Not the intro, not a grep.
- Test each of the five types against its entry requirement, in order. Stop at the first that genuinely passes.
- Return the verdict.
Output
slug: <slug>
verdict: additive | performative | none
figureType: <one of the five, or null>
depicts: <name the actual regions / stages / values — not "the process">
entryRequirement: <how it is met, or which requirement each type failed>
groundedIn: <quote or cite from the article>none still fills entryRequirement — say which requirement each type failed. A bare "none" is not reviewable.
Fan-out
One agent per article, in parallel, each blind to the others. When auditing a set, follow with a single skeptic pass over the collected verdicts to catch a reviewer who drifted lenient.
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.