show-your-work
Skill2 starsChanged 4 months agoMITView on GitHub
Use when the user asks to show, demo, or document completed work as a reproducible evidence document (showboat/rodney). Triggers: \"show your work\", \"make a demo\", \"demo this\", \"demonstrate the feature\", \"demonstrate the fix\", \"capture the evidence\", \"show what you built\", \"show me the results\", \"record what you did\", \"document the results\", \"showboat\", \"rodney\". For checking whether a claim is actually true (\"prove it works\"), use reality-check instead.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- dheerajjha/show-your-worktheir own version, first seen Oct 11, 2026
- ahirmaan/show-your-worktheir own version, first seen Jun 25, 2026
- muyuhill/100books-to-skillstheir own version, first seen Jun 11, 2026
- ChewbaccaRoars/pathfinder-skillstheir own version, first seen Mar 22, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- muyuhill/100books-to-skills★ 14same name
- dheerajjha/show-your-work★ 4same name
- ahirmaan/show-your-work★ 2same name
- ChewbaccaRoars/pathfinder-skills★ 2same 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 repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- adopt-agentic-workflowSkill
- branch-and-commitSkill
- byeSkill
- commit-notationSkill
- commitSkill
- dedicated-browserSkill
- handling-pull-requestsSkill
- jest-testing-conventionsSkill
- markdownSkill
- pnpmSkill
- reality-checkSkill
- schweizer-schreibweiseSkill
- test-driven-developmentSkill
- triage-ticketSkill
- typescript-strict-patternsSkill
- working-with-bitbucket-apiSkill
- working-with-bitbucket-webSkill
- working-with-jira-webSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
2
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
- Distinctive: line 69
If no PR exists or the user declines attachment, offer to share as a gist.
- Very specific: line 71
Create gist with markdown only: gh gist create [--public] <demo>.md
- Distinctive: line 72
If the demo has images:
- Very specific: line 76
Update readme.md image refs to raw URLs: https://gist.githubusercontent.com/<user>/<id>/raw/<sha>/<file>
“Common” is measured: kept by at least 6 in 10 of the 3 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.
Files
Show Your Work
Build a reproducible demo document that proves completed work — tests passing, UI correct, changes verified.
Tools: showboat (docs) + rodney or project-native tools (screenshots). Setup: ./install-dependencies.sh. Both are fetched on demand by uvx — invoke them as uvx showboat … and uvx rodney … (uvx showboat --help, uvx rodney --help).
When to Use
Reactive (work complete): Review what changed (git diff, task context), capture evidence retrospectively.
Proactive (still implementing): Add a "Demo" subsection to the plan, build the document as each step completes.
When NOT to use:
- Trivial changes (config tweaks, dependency bumps)
- User explicitly declined a demo
- Pure internal refactoring with no user-facing behavior
Workflow Checklist
- [ ] uvx showboat --help (verify tool available)
- [ ] showboat init docs/demos/YYYY-MM-DD-<slug>.md "Title"
- [ ] showboat note — what changed and why
- [ ] showboat exec — test runs, build output, key commands
- [ ] Screenshots if UI changed (see tool selection below)
- [ ] showboat verify — re-run if outputs changed
- [ ] Commit demo + images (D intention, droppable on merge)
- [ ] Offer to attach key sections to PR descriptionScreenshots
Prefer project-native tools over rodney:
| If the project uses... | Use for screenshots |
| Playwright (BDD tests, MCP debugging) | Playwright screenshot API or test artifacts |
| Cypress | Test runner output or cy.screenshot() |
| Other test runner with screenshots | Reuse existing test artifacts |
| None of the above | uvx rodney (see rodney --help) |
Embed with showboat image <doc> <image-path>.
Output Location
| Situation | Location | Committed? |
| Default | docs/demos/ | Yes |
| User specifies non-git destination | tmp/ | No |
| Project rules specify another location | Follow project rules | Depends |
Naming: YYYY-MM-DD-<slug>.md, images as *-<description>.png.
Sharing the Demo
PR attachment: Offer to embed key sections in the PR description under a ## Demo heading. Do NOT force-attach — ask first. See handling-pull-requests skill.
Gist fallback (gh is repo-agnostic — works even when the project is on Bitbucket/GitLab):
If no PR exists or the user declines attachment, offer to share as a gist. Ask visibility preference (private/public).
- Create gist with markdown only:
gh gist create [--public] <demo>.md - If the demo has images:
- Clone:
gh gist clone <id> /tmp/gist-<id> - Copy demo as
readme.md(gists listreadme.mdfirst) and images into clone git add, commit, push- Update
readme.mdimage refs to raw URLs:https://gist.githubusercontent.com/<user>/<id>/raw/<sha>/<file> - Push updated markdown, then
trash /tmp/gist-<id>
- Clone:
Gist file sort order: !#-. → digits → _ → alpha. Name the demo readme.md so it pins above image files.
Common Mistakes
| Mistake | Fix |
Skipping showboat verify | Always verify before commit |
Demo in tmp/ when it should be committed | Default to docs/demos/; tmp/ only for non-git destinations |
| Duplicating tool flags in this skill | Run --help at runtime |
Passing images to gh gist create | Binary files rejected — clone gist repo, push images via git |
| Demo file sorts below images in gist | Name the demo readme.md (gists list readme.md first) |
Integration with Other Skills
| Skill | Integration |
commit-notation | Demo commits use D intention (documentation) |
commit | One commit near the end; squash on updates; droppable if merging without demo |
handling-pull-requests | Offer to embed demo highlights in PR description |
| Plan review skills | Suggest adding a demo step when reviewing plans |
| BDD/acceptance tests | BDD/acceptance test screenshots feed into showboat documents |
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.

