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.
Collected from public GitHub. Every version is saved exactly as it was and never changes. Install it at an exact version with the mdr tool, and every file is checked before it reaches your agent. The main file is checked against the SHA-256 fingerprint recorded here, and the others against the fingerprints GitHub keeps for its source commit. The automatic checks below grade the latest version, and the same checks always give the same file the same grade.
What the file says
# 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`.
…
The line at the top of this page pins the label git:20260827.04830a9, which is what most people want. This one pins the sha256 fingerprint of the contents instead, so it survives a label being moved. Either way the exact version is written to mdr.lock, and mdr install downloads and checks those contents again, so it installs them exactly or stops with an error.
GET https://markdownregistry.com/api/v1/artifacts/art_nrph3yjnrlxlyzeb
GET https://markdownregistry.com/api/v1/resolve?ref=painhardcore/pstack/show-me-your-work
GET https://markdownregistry.com/api/v1/blob/14f9c28ea0d4daa8acff9197d7f064ab18454013ed7b69d091f0b024278d4e72
Your AI assistant does the legwork. You hear about the deals worth your word. Hand yours the standing instructions at modelranch.com and it joins the network that reads files like this one.
painhardcore/pstack · .opencode/skills/architect/SKILL.md · Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use…
painhardcore/pstack · .opencode/skills/arena/SKILL.md · Spawn N parallel candidates at the same task, pick a base, graft the strongest parts of the losers into it. Use for…
painhardcore/pstack · .opencode/skills/blast-radius/SKILL.md · Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe…
painhardcore/pstack · .opencode/skills/create-verification-skill/SKILL.md · Generate a project-local verification skill that drives your app the way a user does — any language, framework, or…
painhardcore/pstack · .opencode/skills/figure-it-out/SKILL.md · Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a…
painhardcore/pstack · .opencode/skills/how/SKILL.md · Explain how a subsystem works, trace a runtime flow, or determine where code and ownership belong before making a…
painhardcore/pstack · .opencode/skills/interrogate/SKILL.md · Use for "interrogate", "adversarial review", "multi-model review", "challenge this", "stress test this code", "find…
painhardcore/pstack · .opencode/skills/principle-boundary-discipline/SKILL.md · Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI…
cursor/plugins · pstack/skills/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
cursor/plugins · harness/pstack/claude-code/skills/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
michael-denyer/pstack-claude · plugins/pstack/skills/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
backnotprop/pstack · skills/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
timharris707/skills · plugins/clickai-codex/skills/run/show-me-your-work/SKILL.md · For autonomous multi-phase or unattended work, a reviewer needing an evidence trail, or an explicit…
timharris707/skills · skills/run/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: one append-only TSV log, one row per decision…
j-star-films-studios/vibecode-protocol-suite · assets/.agent/skills/code-intelligence/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
creedants/pstack-t3 · t3/overrides/show-me-your-work/SKILL.md · Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why…
