show-me-your-work
cursor/plugins
Maintain a reviewable decision log (TSV) for long-running or autonomous work, with one row per decision.
What is show-me-your-work?
A structured audit trail for work that runs unattended or requires human review. Records each decision (what, why, evidence, result) in a single TSV file so reviewers can follow the reasoning and verify outcomes without re-running the work.
- Log decisions and checkpoints as a TSV with timestamp, phase, decision, reasoning, evidence pointer, and result
- Append-only audit trail that captures forks, pivots, reversions, and blockers without editing history
- Helper script to safely write rows, auto-stamping timestamps and escaping special characters
- Support for cross-model review: spawn a subagent on a different model to flag weak evidence, skipped verification, or risky choices
- Audit mechanism to walk the transcript and verify each logged row maps to a real decision with valid evidence
How to install show-me-your-work
npx skills add https://github.com/cursor/plugins --skill show-me-your-workHow to use show-me-your-work
- 1.Copy the template header row from `references/decision-log-template.tsv` to create `decisions.tsv` (or `.audit/<task-slug>.tsv` for multiple concurrent efforts)
- 2.After each decision or checkpoint, call `scripts/log.sh <logfile> <phase> <decision> <why> <evidence> <result>` with plain-language descriptions and a pointer to evidence (commit SHA, PR, file:line, artifact path)
- 3.At the end of the run, audit the log: read your transcript in `agent-transcripts/`, walk each logged row to verify it matches what actually happened, and add new rows to supersede any that are wrong or incomplete
- 4.Spawn a subagent on a different model family to review the trail and flag weak evidence, skipped verification, or risky choices
- 5.Commit the log only when the work is ambitious enough that a reviewer needs the trail to trust the result; otherwise keep it as a local working artifact
Use cases
- Long-running autonomous agent work where you need to trust the result without re-running it
- Multi-phase or multi-agent projects where later runs pick up where earlier ones left off and need to see what was decided
- Code refactors or large changes where a reviewer needs to understand the reasoning and spot-check outcomes
- Debugging or investigation work where you want to capture why each hypothesis was tested and what it revealed
- Compliance or audit scenarios where you must prove the decision trail for a complex result
- Developers running long unattended agent tasks
- Teams reviewing work done by autonomous agents or in separate sessions
- Project leads auditing multi-phase work or handoffs between team members
- Anyone building reproducible decision trails for complex or high-stakes changes
show-me-your-work FAQ
Log decision points and checkpoints: a fork chosen, a unit completed with verification, a pivot or revert with its trigger, a blocker surfaced, or a gate fixed. Skip trivial or self-evident actions. For loop runs, log one row per iteration.
No. The log is append-only. If a row is wrong, add a new row that supersedes it with what actually happened and a pointer to the evidence that proves the correction.
A pointer that resolves: a commit SHA, PR number, file:line reference, or path to an artifact, trace, or screenshot. Never prose or a paragraph. Evidence proves the claim in the decision column.
Keep it local by default as a working artifact. Commit it only when the work is ambitious enough that a reviewer needs the trail to trust the result.
Each new run or agent conversation starts with a `start` row (phase=start) that names the timestamp range of prior rows it did not write. This lets later runs see what earlier ones did and avoid duplicating work.
Full instructions (SKILL.md)
Source of truth, from cursor/plugins.
name: show-me-your-work description: "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." disable-model-invocation: true
Show me your work
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 time
Logging 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 agent-transcripts/ directory (the system prompt names the path). Don't glob across ~/.cursor/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, spawn a subagent on a different model family from the one that did the work. 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.
Related skills
More from cursor/plugins and the wider catalog.

swarm
Fan out N parallel workers, drain them, and return one consolidated report.

tdd
Write focused regression tests before fixing bugs with clear, cheap test paths.

teach
Explain code and systems plainly by combining how and why analysis into one clear account.

technical-writing
Layered technical-writing standard: Diátaxis structure, Google style, STE rules, Global English syntax.

thermo-nuclear-code-quality-review
Extremely strict code quality review focused on maintainability, abstraction, and structural simplification.

thermo-nuclear-review
Comprehensive security and correctness audit of branch changes for bugs, breaking changes, and vulnerabilities.