show-me-your-work
Skill9 starsChanged 3 months agoMITView on GitHub
Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /skill:show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.
We split this skill into the rules it gives an agent
4 rules. 2 are common, 1 is distinctive, and 1 is very specific to this project.
2
Common
Most of the 58 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 36
Write each entry the way you'd tell a teammate what you did.
- Common: line 52
Prefer evidence produced by committed scripts over hand-made one-offs, so a reviewer can re-run it (the encode-lessons-in-structure …
- Distinctive: line 58
Every row maps to a real action.
- Very specific: line 78
Read top to bottom, follow the evidence pointers, spot-check.
“Common” is measured: kept by at least 6 in 10 of the 58 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 me your work
For work a human reviews after the fact, a decision trail lets them reconstruct what was decided, why, and on what evidence, without rerunning the work or reading the whole transcript. Keep one canonical log so the trail is consistent and a future agent can find it.
The format
A single TSV file, one row per decision. TSV because GitHub renders it as a sortable table, column -s$'\t' -t and spreadsheets read it, and a row appends with one command. Cells stay single-line. Evidence is a pointer, not prose.
Copy references/decision-log-template.tsv (the header row) to start a clean log. Columns:
- ts. ISO8601 timestamp. The timeline axis.
- phase. The phase or workstream.
- decision. What was chosen or done, one line.
- why. The reason in plain words. If a principle drove it, say it plainly (
explored options first, this was a one-way door), not as a jargon tag. - evidence. A link or path that proves it: commit SHA, PR number,
file:line, or an artifact, trace, or screenshot path. Never a paragraph. - result. The outcome or predicate state:
tests green,reverted,pixel-diff 0,INCONCLUSIVE,open.
An example, plain-spoken so a reviewer reads it at a glance. This is illustration only; don't copy these rows into a real log.
ts phase decision why evidence result
2026-05-24T09:02:00Z frame counted the work first, about 100 components and roughly 75 hours wanted to know the size before starting a long run commit 3a9f1c2 found 5 things to sort out before starting
2026-05-24T09:40:00Z harness took screenshots of the old version before changing anything so we can compare old against new and catch any visual change scripts/snapshot.sh, baseline/ saved 120 reference screenshots
2026-05-24T11:15:00Z widget moved the widget styles over without changing how it looks keep the change small and the result identical commit 7c21e0a, pixel-diff 0 looks identical, tests pass
2026-05-24T12:30:00Z widget threw out a helper's work because its screenshots were blank checked the real files instead of trusting its summary worktree reset reverted, tightened the instructions for next timeLogging a row
Write each entry the way you'd tell a teammate what you did. Plain words, concrete actions, no AI speak or abstract jargon (the unslop skill applies to log text too). A reviewer should understand each row without decoding it.
Use the helper so rows stay well-formed: scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>. It stamps ts, writes the header on first use, strips stray tabs/newlines, and prefixes any cell starting with =, +, -, or @ with a single quote so a reviewer opening the log in a spreadsheet doesn't trigger formula execution. A bare printf appending a row works too, but mind those same bytes if cells come from generated or user-supplied text.
Log decision points and checkpoints, not every action: a fork chosen, a unit completed with its verification result, a pivot or revert with its trigger, a blocker surfaced, a gate fixed. For loop runs, one row per iteration. Skip the trivial and self-evident.
Where it lives
By default the log is a working artifact, not committed. Keep it at decisions.tsv in the work dir, or .audit/<task-slug>.tsv when several efforts run at once, and leave it out of git. Most work doesn't need a committed trail; the local log still keeps the run honest and can be discarded after.
Commit it only when the work is ambitious enough that a reviewer needs the trail to trust the result: a large cross-language port, a multi-week migration, anything where confidence has to be shown rather than assumed. A committed log renders as a table in the PR.
Rules
- One row is one decision or checkpoint. If it doesn't fit on one line, the decision isn't crisp yet.
- Append-only. A wrong call gets a new row that supersedes it. Never edit or delete history.
- Prefer evidence produced by committed scripts over hand-made one-offs, so a reviewer can re-run it (the encode-lessons-in-structure principle skill).
Audit the log against the transcript
At the end of the run, before handing back, check the log told the truth. Read $PI_SESSION_FILE for this run. For an earlier same-project session, use pstack_sessions; do not glob Pi's global session directory. Walk the log against what actually happened:
- Every row maps to a real action. Cut invented or aspirational entries.
- Each row's evidence resolves and shows what the row claims.
- A fork, pivot, or abandoned approach that shaped the work but isn't logged is a gap. Add it.
- Drop padding. If nobody would audit a row, it doesn't earn its place.
Fix the log, not the story. If the work diverged from what a row claims, the row is wrong.
Cross-model review of the trail
Before handing back, you must spawn a subagent on a different model family from the one that did the work. Self-review is not a substitute; the point is fresh eyes you cannot bring yourself. The subagent reads the audit trail and the run's transcript, then flags what the user should pay attention to. Not a redo of the work, a scan for what's suboptimal or risky.
- Decisions logged with weak or absent evidence.
- Verification steps skipped or claimed without proof in the transcript.
- Choices that look risky in hindsight (premature, scope-creeping, papering over a symptom).
- Gaps the user would otherwise miss on a casual skim.
Every reply for a run that produced a trail ends with an "Attention" section. Lead with the reviewer's model on its own line (reviewed by <model>), then list each flag pointing to specific rows or moments. "No flags" is a valid value; the model name is not. The self-audit asks if the log told the truth; this asks what the user should still scrutinize even when it did.
Reviewing the trail
Read top to bottom, follow the evidence pointers, spot-check. GitHub renders a committed TSV as a table; column -s$'\t' -t decisions.tsv renders it in a terminal. A row whose evidence doesn't resolve, or whose result is unverified, is the audit catching a gap.
Composing this skill
Other skills route their audit trail here instead of inventing one. Reference it by name and let it own the format; don't restate the columns.
Other versions59 projects use a version of this.
Word for word · 0
None found.
Edited · 55
- backnotprop/pstack★ 3.3k63% same
- jtaroreh/agystack★ 12859% same
- uzairansaruzi/p3-stack★ 12663% same
- dsebban/skills★ 7159% same
- The-AIE/the-gibson★ 4365% same
- timharris707/skills★ 4352% same
- overextended/skills★ 2244% same
- Scino/fstack★ 1896% same
- creedants/pstack-t3★ 1754% same
- mariusflorescu/pstack-t3★ 958% same
45 more not listed
Wrote their own version · 4
- TheOnlyFusionCube/potetos-for-everyone★ 18same name
- jonmumm/skills★ 2same name
- kinqsradio/orbyn-fullstack-skills★ 1same name
- 3metaJun/mstack★ 0same 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.
Used alongsideProjects with it also use poteto-help, principle-explain-the-number and 9 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.
ianclearySkillpoteto-help
Guides users through pstack setup, /poteto-mode, and picking the skill, playbook, or principle for a task. Type /poteto-help with a question.
Also in 9 projects that use this
juancamiloqhzSkillprinciple-explain-the-number
Apply before you trust, report, or act on a number you measured: a speedup, a regression, a throughput, a latency, or an eval result. Find what limits it, and rule out that it measured something other than the work you think.
Also in 18 projects that use this
Xia-AtaraxiaSkillmake-bot-ui
Builds a small web page whose buttons wake an agent over a webhook: a local server keeps the sender key server-side and POSTs JSON to a webhook-triggered routine, and the page is exposed on the existing Tailscale node. Use for \"make a bot UI\", \"a dashboard with buttons that trigger the agent\", \"wake the bot from a page\", handing a webhook sender key to the server without pasting it in chat, or putting that UI on the tailnet. Not for general frontend work - use principle-frontend; not for tailnet health or reachability - use tailscale.
Also in 17 projects that use this
jtarorehSkillpoteto-mode
poteto's agent style for concise, detailed responses, deliberate subagents, unslopped prose, simple code, and verified work. Use for poteto, /poteto-mode, or requests to work in this style.
Also in 5 projects that use this
Xia-AtaraxiaSkillbenchmark-checklist
Vets performance measurements for the limiter, tuning, physical limits, errors, repeatability, relevance, and proof that timed work happened. It applies to 'check this benchmark', 'report this speedup', measured regressions, and choosing a library or configuration from numbers. It reports spread and gaps before drawing a conclusion. Not for general testing policy or choosing test oracles - use principle-testing.
Also in 19 projects that use this
alexnthnzSkillin-your-own-words
Restate in your own words what you think the user's goals are and what problem they're trying to solve. Use for /keel:in-your-own-words.
Also in 8 projects that use this
In this repository43 other files it gives its agents.
- architectSkill
- arenaSkill
- automate-meSkill
- blast-radiusSkill
- broSkill
- create-verification-skillSkill
- figure-it-outSkill
- howSkill
- interrogateSkill
- maintain-verification-skillSkill
- no-commentsSkill
- poteto-modeSkill
- principle-boundary-disciplineSkill
- principle-build-the-leverSkill
- principle-encode-lessons-in-structureSkill
- principle-exhaust-the-design-spaceSkill
- principle-experience-firstSkill
- principle-fix-root-causesSkill
- principle-foundational-thinkingSkill
- principle-guard-the-context-windowSkill
- principle-laziness-protocolSkill
- principle-make-operations-idempotentSkill
- principle-migrate-callers-then-delete-legacy-apisSkill
- principle-minimize-reader-loadSkill
- principle-model-the-domainSkill
- principle-never-block-on-the-humanSkill
- principle-outcome-oriented-executionSkill
- principle-prove-it-worksSkill
- principle-redesign-from-first-principlesSkill
- principle-separate-before-serializing-shared-stateSkill
- principle-sequence-verifiable-unitsSkill
- principle-subtract-before-you-addSkill
- principle-type-system-disciplineSkill
- recallSkill
- reflectSkill
- setup-pstackSkill
- swarmSkill
- tddSkill
- teachSkill
- technical-writingSkill
- typescript-best-practicesSkill
- unslopSkill
- whySkill
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.

