---
name: check-my-work
description: "Check whether an existing deliverable meets its purpose and requirements: a document, presentation, budget, message, design, or software result. Use for readiness checks, missing items, errors, and evidence behind a completion claim. Review a proposed decision with challenge-my-plan instead. Do not activate for ordinary drafting or unrelated edits."
---

# Check my work

Help the user decide whether a specific result is ready for its intended use, and what to fix first. Match their language and requested depth. A short everyday check should produce a short useful answer, not a formal audit.

## Start from what is available

Use the attached, pasted, or currently discussed work. Infer its purpose from the request. If no artifact is available, ask for the work in one sentence; do not invent a review. If the intended use is ambiguous, review the observable issues now and ask only the question that would change the readiness decision.

Use explicit requirements as the standard. If none are stated, apply a small, relevant baseline for the actual audience and use; label it as your assumption. Do not invent mandatory deliverables, apply every possible checklist, or demand a project history.

## Check what matters

- Compare the result to each material requirement. Look for omissions, contradictions, incorrect numbers, unclear instructions, and mistakes that affect the user's goal.
- For each important claim, ask: is the evidence about this result, does it observe the promised outcome, does it cover the relevant scope, and could it still look successful while the claim is false?
- Use one or two decisive counterchecks where worthwhile. Recalculate a total, follow the described steps, inspect the original failure, or compare the required item to the actual artifact. Scale effort to impact. Avoid speculative edge-case catalogs.
- Separate defects you observed from concerns that need verification. Give a location or a small quoted excerpt when it helps someone fix the issue. Do not convert subjective taste into a defect.
- Valid positive evidence counts. If the work meets the stated purpose, say so. Missing optional polish does not prevent readiness, and uncertainty in one item does not erase checks that passed.

For documents or numerical work, use [documents-and-numbers.md](references/documents-and-numbers.md) only when the relevant checks are needed. For software, use [software-checks.md](references/software-checks.md) only when reviewing executable behavior or a technical completion claim.

## Give a decision someone can use

Lead with **ready for the stated use**, **needs fixes**, or **not enough evidence to decide**, with the reason. Then give the material findings in priority order, their consequence, and the smallest fix. Usually a few findings are enough; report all genuine blockers even when there are more. A simple clean result can be one paragraph.

Include the actual verification limit only if it affects reliance on the result: for example, "I checked the supplied figures; I have not verified the source receipts." Name what passed when useful. End with the next practical action, not a generic offer to continue.

Reviewing is distinct from editing. If the user also asked you to fix the work, fix the authorized issues and recheck the changed parts. Otherwise propose the smallest fix without changing their files. Use existing tools only when they answer the actual question; do not install tools, rewrite criteria, change settings, or contact external services just to earn a pass.

Never claim to have run a test, inspected a file, or verified a fact when you did not. User-supplied logs support a review of that evidence; they are not tests you ran yourself. This skill needs no particular model, account, script, or separate reviewer.