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 for every task. Read 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. 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 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.