# Show The Work > Recover, verify, and turn observable work into a clear human progress story, proof-led explainer, handoff page, or partner-ready research note. Use when a user asks to show what was done, explain how a result was reached, continue a prior session, summarize progress with an honest percentage, build a page someone can forward or defend on a call, or keep updates in the concise factual voice of verified fact plus next action. This skill never exposes hidden chain-of-thought and never sends or publishes without explicit approval. - Skill: `seryozh/show-the-work` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add seryozh/show-the-work` - Raw SKILL.md: https://api.skillmd.com/api/skills/seryozh/show-the-work/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: Seryozh (https://skillmd.com/u/seryozh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/seryozh/show-the-work --- # Show the work Tell the story of work that can be checked: actions, artifacts, sources, failures, corrections, and current limits. Never present private reasoning traces or hidden chain-of-thought as the product. Read [references/voice.md](references/voice.md) for every task. Read [references/evidence-story.md](references/evidence-story.md) when producing a page, report, memo, or other proof-led artifact. Names in backticks are base skill names, not invocation tokens. Resolve the exact runtime-visible identity before invoking one. Prefer the current skill's namespace when present. If no unique matching skill is visible, use the stated direct fallback instead of guessing. ## Define the finish line Write a short internal contract before building: - reader and decision; - one sentence the artifact must support; - evidence required; - private or external boundary; - judged surface; - proof of done; - hard blockers. When `own-the-outcome` is installed, use it for consequential work. Otherwise establish the full finish-line contract above directly. Keep the contract in the work folder rather than burdening the user with process. ## Restore actual state When the request refers to a prior task, session, artifact, or decision, recover the original request, current working directory, governing files, latest built artifact, superseded drafts, source assets, and open blockers. Use `recover-codex-context` when that companion skill is installed; otherwise inspect the available history and artifacts directly. Treat a write to a template as incomplete until the final artifact is rebuilt. Treat a screenshot as stale after any downstream content or CSS edit. A missing or failed lookup is `UNKNOWN`, never evidence of absence. ## Separate authority and audit - Give one owner write authority over each mutable artifact. - Keep critics read-only. Return findings as `claim`, `CONFIRMED | CONTRADICTED | UNVERIFIABLE`, evidence, severity, and correction. - Choose audit lanes by risk. External evidence packages usually need claims, numbers, disclosure, and reader-view checks. Add method validation when the method itself supports trust. - Use an independent second pass for blocker claims when fresh agents are available. A regression recheck in the same context is useful but not independent. - Continue building only the structure that does not depend on disputed facts. Hold uncertain facts as gated placeholders. ## Build the observable story Lead with the fact that changes the reader's decision. Explain the mechanism in plain words, show one clean example, and include a strong rejected candidate or counterexample when it exists. Keep `Confirmed`, `Not known`, and `Next proof` visible. For every evidence visual: 1. Open the original. 2. Name the exact claim it must prove. 3. Crop only the load-bearing passage while retaining enough provenance. 4. Inspect the crop visually. 5. Match caption and alt text to what is actually visible. 6. Rebuild the crop if any number, qualifier, or source marker disappeared. Derive the visual language from the subject. When `artifact-design` is installed, use it for a dedicated design pass; otherwise preserve any supplied design system and establish a restrained hierarchy, palette, typography, spacing, and responsive behavior directly. When `humanizer` is installed, use it for outgoing prose; otherwise apply the complete manual voice pass in [references/voice.md](references/voice.md). Do not let either pass add facts. ## Build and verify deterministically - Separate readable content from media or data substitution when a build step helps. - Make one command reproduce the final artifact and print its assets and output size. - Run [scripts/story_lint.py](scripts/story_lint.py) on outgoing HTML or Markdown. Add task-specific `--ban`, `--require`, and `--allow-token` values. - Render after the final edit. For responsive pages, inspect phone, tablet, and desktop. Check both themes when supported. - Verify asset loads, links, overflow, contrast, focus, alt text, and unresolved placeholders on the actual surface. - Save the deliverable in a durable user-facing output location, not scratch or a temporary folder. If any correction changes content or layout, repeat build, lint, disclosure scan, and rendered QA. Do not reuse an earlier receipt. ## Report readiness honestly Compute percentages from passed acceptance gates, not time spent or file count. Show separate percentages when research completion and artifact readiness are different. Use these weighted gates unless the task defines better ones: - state recovery and input freeze: 10; - claim and number verification: 20; - narrative and evidence mapping: 15; - final build integrity: 15; - responsive and accessibility QA: 15; - disclosure and privacy review: 10; - handoff package and approval: 15. Score a gate 0, 0.5, or 1 and multiply by its weight. Unknown counts as 0. Any hard blocker makes the verdict `NOT READY` even if the percentage is high. If the underlying work has no valid denominator, do not invent a research percentage. Distinguish: - **artifact-ready:** the file itself has passed; - **review-ready:** the exact package is ready for the user's review; - **send-ready:** recipient, subject, body, attachments, formatting, and current approval are all confirmed; - **sent:** the external system confirms the action occurred. Never collapse these states. ## Protect the release boundary Before any external send or publication, show the user the exact recipient, subject, body, attachments, formatting, and artifact. Wait for explicit approval. Renew approval after any change. Scan for private CRM material, opt-outs, credentials, local paths, internal targets, deadlines, exclusions, unsupported claims, and named negative examples. If an earlier artifact was already sent with restricted material, verify that independently and tell the user before further polish. Do not send a correction on your own.