show-me-your-work
Skill0 starsChanged 38 days 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 /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away.
67 other projects use a version of this, 58 of them edited.
Adopted by
Most recently taken up by
- Yeachan-Heo/oh-my-claude-sisyphustheir own version, first seen Nov 8, 2026
- caidanw/skillsedited, first seen Nov 8, 2026
- Yeachan-Heo/oh-my-claudecodetheir own version, first seen Nov 8, 2026
- endqwerty/endstackedited, first seen Nov 8, 2026
- tristanphvn/keeledited, first seen Nov 8, 2026
- hidenobunagai/astackedited, first seen Nov 8, 2026
Used with
Projects with it also use ketchup-video, make-bot-ui and 5 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.
tristanphvnSkillketchup-video
Catch the user up like /keel:ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /keel:ketchup-video.
Also in 14 projects that use this
eryzerzSkillmake-bot-ui
Use when building a custom UI (page, dashboard, buttons) that should wake a Grok Bot over a webhook, when the user must provide a webhook sender key, or when exposing that UI on Tailscale.
Also in 20 projects that use this
instructureSkillketchup
Rebuild context after /clear by analyzing uncommitted changes across Canvas LMS and all plugin repositories
Also in 25 projects that use this
drafaelSkillin-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 24 projects that use this
TheOnlyFusionCubeSkillmaintain-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 18 projects that use this
TheOnlyFusionCubeSkillcreate-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 19 projects that use this
- +1 more from TheOnlyFusionCube
Other versions67 projects use a version of this.
Word for word · 0
None found.
Edited · 58
- backnotprop/pstack★ 3.8k89% same
- jtaroreh/agystack★ 12851% same
- uzairansaruzi/p3-stack★ 12688% same
- dsebban/skills★ 7183% same
- The-AIE/the-gibson★ 4491% same
- timharris707/skills★ 4434% same
- overextended/skills★ 2268% same
- creedants/pstack-t3★ 1876% same
- painhardcore/pstack★ 1883% same
- Scino/fstack★ 1864% same
48 more not listed
Wrote their own version · 9
- Yeachan-Heo/oh-my-claude-sisyphus★ 41ksame name
- Yeachan-Heo/oh-my-claudecode★ 41ksame name
- TheOnlyFusionCube/potetos-for-everyone★ 21same name
- kinqsradio/orbyn-fullstack-skills★ 4same name
- orbyn-dev/orbyn-fullstack-skills★ 4same name
- requie/endostack★ 4same name
- jonmumm/skills★ 2same name
- johnnygreco/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.
In this repository49 other files it gives its agents.
- architectSkill
- arenaSkill
- automate-meSkill
- benchmark-checklistSkill
- blast-radiusSkill
- broSkill
- correctSkill
- create-verification-skillSkill
- figure-it-outSkill
- howSkill
- interrogateSkill
- maintain-verification-skillSkill
- no-commentsSkill
- poteto-helpSkill
- poteto-modeSkill
- principle-attack-the-premiseSkill
- principle-boundary-disciplineSkill
- principle-build-the-leverSkill
- principle-encode-lessons-in-structureSkill
- principle-exhaust-the-design-spaceSkill
- principle-experience-firstSkill
- principle-explain-the-numberSkill
- 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-test-behavior-not-implementationSkill
- principle-type-system-disciplineSkill
- recallSkill
- reflectSkill
- setup-pstackSkill
- swarmSkill
- tddSkill
- teachSkill
- technical-writingSkill
- typescript-best-practicesSkill
- unslopSkill
- whySkill
The file
We split this skill into the rules it gives an agent
7 rules. 4 are common, 2 are distinctive, and 1 is very specific to this project.
4
Common
Most of the 64 edited versions we read keep these.
2
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 10
Keep one canonical log.
- Common: line 37
Write each entry the way you'd tell a teammate what you did.
- Common: line 49
Commit it only when the work is ambitious enough that a reviewer needs the trail to trust the result.
- Common: line 54
Prefer evidence produced by committed scripts over hand-made one-offs (the encode-lessons-in-structure principle skill).
- Distinctive: line 60
Check that every row maps to a real decision or action.
- Distinctive: line 61
Check that each row's evidence resolves and shows what the row claims.
- Very specific: line 79
Read top to bottom, follow the evidence pointers, spot-check.
“Common” is measured: kept by at least 6 in 10 of the 64 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
Claude Code: read Cursor terms in this skill through
claude-code/runtime.md(tools, subagents, models, transcripts).
Keep one canonical log.
The format
A single TSV file, one row per decision. 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.
- 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, 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.
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).
Use the helper 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. 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.
A run is one agent conversation, including its later turns and any summary of it. A pickup, a replacement agent, or a new chat starts a new run. When a run adds to a log that already has rows, its first row has phase start, and so does its first row after another run's start row. So a run that comes back to a log in a later turn first reads the log's last rows to see whether another run wrote since. A start row names the ts range of the rows before it that this run did not write, and its evidence names this run, such as its agent id. Use phase start for nothing else.
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.
Commit it only when the work is ambitious enough that a reviewer needs the trail to trust the result.
Rules
- 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 (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 this run's transcript under the active workspace's transcript directory (~/.claude/projects/<project>/) (see pstack's claude-code/runtime.md). Don't glob across ~/.claude/projects/*/. That reads unrelated private chats. Walk this run's rows against what actually happened. Each stretch of them begins at one of this run's start rows, or at the first row if this run created the log, and ends at the next start row of another run:
- Check that every row maps to a real decision or action.
- Check that 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.
Correct the log, not the story. The audit never edits or removes a row, even an invented one. When a row records neither a real decision nor a real action, or its claim or evidence is wrong, add a row that supersedes it with what actually happened and a pointer that resolves. This audit does not check rows outside this run's stretches. If this run's own work shows one of them is wrong, supersede it like any wrong call.
Cross-model review of the trail
Before handing back, run one reviewer on a different model family when available: external codex/gemini seats follow the delegate routing in claude-code/runtime.md; otherwise spawn Agent with subagent_type: pstack:read-only, explicit model: sonnet and effort: medium. Resolve overrides from the live delegation-kit table when present, normalizing inheritance aliases to sonnet/medium. Self-review is not a substitute. 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.
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.
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.
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.

