agentleFS
Sign inStart free
t1mericksont1merickson/skills/show-me/SKILL.md

show-me

Skill1 starsChanged 2 months agoMITView on GitHub

Show work, a decision, a state, a comparison, or an idea visually instead of in prose. Use when invoked as /show-me, and offer it unprompted when the user must judge or pick something that is easier to see than read (glyphs, layouts, options, file sets, data, before/after). Not for picking a new UI direction with no design yet (use mock-and-pick), and not for short answers that read fine as text.

79 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use maintain-formal-verification-skill, create-formal-verification-skill and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TheOnlyFusionCubeSkill

    maintain-formal-verification-skill

    Bring a project's formal verification back in line with the code after the code changes: find the commits that touched verified code, update the model, harness, or properties to describe the code as it is now, rerun, and say whether each failure is drift in the verification or a bug in the code. Use for /maintain-formal-verification-skill, \"is the model still true to the code\", or after merges and refactors that touched verified code without rechecking it.

    Also in 4 projects that use this

  • TheOnlyFusionCubeSkill

    create-formal-verification-skill

    Generate a project-local skill that formally verifies the code where a bug costs the most and tests reach the least, in any language, with whichever verification tool fits. Use for /create-formal-verification-skill, \"model-check this race\", \"prove this invariant\", or when concurrency, retries, state machines, parsers, or unsafe code need more than tests.

    Also in 4 projects that use this

  • AnthropicSkill

    eli5

    Explain a topic like I'm a 5 year old. Use when the user types /eli5 <topic> or asks for a dead-simple picture explainer of how something works.

    Also in 10 projects that use this

  • drafaelSkill

    in-your-own-words

    Restate the user's goals and the problem they are trying to solve to check understanding. Manual invocation only; use when the user explicitly invokes in-your-own-words or requests this understanding check. Do not solve the task or rewrite the assistant's last answer.

    Also in 4 projects that use this

  • jaydubya818Skill

    create-verification-skill

    Use when a repository needs a repeatable driver that proves real UI, CLI, or service behavior.

    Also in 8 projects that use this

  • jaydubya818Skill

    maintain-verification-skill

    Use when a project's verification driver or feature map may be stale.

    Also in 7 projects that use this

  • +1 more from TheOnlyFusionCube
  • +1 more from jaydubya818

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 73 edited versions we read keep these.

  • 3

    Distinctive

    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
  1. Very specific:

    Not for: a new UI direction with no design yet (that is mock-and-pick), yes/no questions, or answers that fit in two sentences.

    line 14
  2. Distinctive:

    Use the first that fits. Native beats new.

    line 18
  3. Very specific:

    The thing itself: If the work is an app or page, build it and open it.

    line 20
  4. Distinctive:

    No dashboards, nav, theming, or build step.

    line 38
  5. Distinctive:

    When they paste picks back, act on them.

    line 44

“Common” is measured: kept by at least 6 in 10 of the 73 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

show-me

The user judges by looking. Markdown tables, file trees, and lists of dial values are not legible to them. When something needs their eyes or their pick, put the real thing in front of them.

When to use

  • /show-me, with or without a topic. No topic means: show whatever is open right now (the current decision, the work just done, the state of the thing).
  • Unprompted: offer it in one line when a decision or comparison is about to go out as a wall of text. If the user already asked for visuals in this session, skip the offer and just do it.
  • Not for: a new UI direction with no design yet (that is mock-and-pick), yes/no questions, or answers that fit in two sentences.

Where to show it

Use the first that fits. Native beats new.

  1. The thing itself. If the work is an app or page, build it and open it. Native apps: make run. Web: the project's existing dev server, opened in Chrome.
  2. The project's own viewer. Font projects: Bench, through the kit skill. Design work on a Paper canvas: the canvas, through paper-mcp. Any existing viz page, preview, or viewer already in the repo.
  3. One HTML file in the project. Save it at <project>/show-me/<topic>.html. Not /tmp, not a chat artifact, not markdown. Open it yourself: open -a "Google Chrome" /absolute/path/to/show-me/<topic>.html

Open it yourself every time. Never hand the user a path or a command to open it.

What goes on the page

  • Real content. Actual glyphs in the actual font, real window captures (via window-capture), real data, real file thumbnails. Never a description of the thing in place of the thing.
  • Decisions: options side by side. Each gets a label and one plain line on what picking it means. Add a way to pick: checkboxes or radio buttons plus a "Copy picks" button that copies a short text line the user can paste back.
  • State or progress: what is done, what is not, what is broken, as a grid or list of the real items, not a summary.
  • Comparisons: same scale, same order, aligned so differences jump out.
  • Style per web-design-defaults: black and white, system font, no decoration.

Keep it small

  • One page. The smallest thing that makes it legible.
  • No dashboards, nav, theming, or build step. A single self-contained HTML file is the default.
  • Reuse and update the same file for the same topic instead of making new ones.

After showing

  • Say in one line what is on screen and what you need from the user. Then stop and wait if it is a decision.
  • When they paste picks back, act on them.
  • Files in show-me/ are scratch. Once the decision lands, move them to quarantine (never rm) unless the user wants to keep them. Ask before committing them.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free