Agent Output Review
Use this skill to catch the failure modes that appear when an AI agent produces something plausible but incomplete. The goal is not to be harsh; it is to protect the user from shipping ghost features, fake integrations, missing instructions, and brittle assumptions.
What To Review
Review the output against the user's actual goal, not just surface quality:
- Does it solve the requested problem?
- Does it work in the target environment?
- Are there fake, stubbed, or decorative features presented as real?
- Are dependencies, secrets, permissions, or setup steps missing?
- Are security and privacy risks obvious to the user?
- Is the output maintainable by someone else later?
Workflow
- Restate the intended outcome in one sentence.
- Build an evidence map:
- Files changed or artifacts produced.
- Commands that should verify the result.
- User-facing flows that should work.
- External services, credentials, or assumptions.
- Look for agent-specific failure modes:
- Hallucinated APIs, package names, flags, or config keys.
- UI buttons that do not do anything.
- Example data hardcoded as if it were real.
- Tests that assert implementation details but not user value.
- README claims that outrun the actual feature.
- Missing error handling around network, auth, files, or payments.
- Verify what can be verified:
- Run tests, lint, build, or typecheck when available.
- Open the app in a browser when UI is involved.
- Inspect generated files for placeholders and TODOs.
- Check that install and usage instructions match the code.
- Classify the result:
- Accept: usable with minor notes.
- Accept after fixes: valuable but has clear blockers.
- Reject/rework: misleading, unsafe, or not actually functional.
Output Format
## Review Verdict
Accept / Accept after fixes / Rework.
## What Was Verified
- Command, file, or flow checked.
## Blocking Issues
- Severity: issue, evidence, and fix.
## Hallucination Or Completeness Risks
- Claim or feature that may not be real.
## Missing User Value
- What the output still needs before it solves the original problem.
## Recommended Next Patch
Smallest change that turns this from plausible to useful.
Judgment Rules
- Treat untested user-facing behavior as unknown, not done.
- Do not reward volume; reward working paths, clear docs, and honest limitations.
- Point to evidence whenever possible.
- Be especially skeptical of integrations, auth, billing, browser automation, and generated README claims.
- If the output is good, say so plainly and still name the remaining risk.
1---2name: agent-output-review3description: Use when reviewing AI-generated code, apps, workflows, skills, PRDs, GitHub repos, or automation outputs before accepting or publishing them. Trigger this whenever the user asks whether an agent's work is actually usable, complete, safe, non-hallucinated, or ready to merge.4---56# Agent Output Review78Use this skill to catch the failure modes that appear when an AI agent produces something plausible but incomplete. The goal is not to be harsh; it is to protect the user from shipping ghost features, fake integrations, missing instructions, and brittle assumptions.910## What To Review1112Review the output against the user's actual goal, not just surface quality:1314- Does it solve the requested problem?15- Does it work in the target environment?16- Are there fake, stubbed, or decorative features presented as real?17- Are dependencies, secrets, permissions, or setup steps missing?18- Are security and privacy risks obvious to the user?19- Is the output maintainable by someone else later?2021## Workflow22231. Restate the intended outcome in one sentence.242. Build an evidence map:25 - Files changed or artifacts produced.26 - Commands that should verify the result.27 - User-facing flows that should work.28 - External services, credentials, or assumptions.293. Look for agent-specific failure modes:30 - Hallucinated APIs, package names, flags, or config keys.31 - UI buttons that do not do anything.32 - Example data hardcoded as if it were real.33 - Tests that assert implementation details but not user value.34 - README claims that outrun the actual feature.35 - Missing error handling around network, auth, files, or payments.364. Verify what can be verified:37 - Run tests, lint, build, or typecheck when available.38 - Open the app in a browser when UI is involved.39 - Inspect generated files for placeholders and TODOs.40 - Check that install and usage instructions match the code.415. Classify the result:42 - Accept: usable with minor notes.43 - Accept after fixes: valuable but has clear blockers.44 - Reject/rework: misleading, unsafe, or not actually functional.4546## Output Format4748```markdown49## Review Verdict5051Accept / Accept after fixes / Rework.5253## What Was Verified5455- Command, file, or flow checked.5657## Blocking Issues5859- Severity: issue, evidence, and fix.6061## Hallucination Or Completeness Risks6263- Claim or feature that may not be real.6465## Missing User Value6667- What the output still needs before it solves the original problem.6869## Recommended Next Patch7071Smallest change that turns this from plausible to useful.72```7374## Judgment Rules7576- Treat untested user-facing behavior as unknown, not done.77- Do not reward volume; reward working paths, clear docs, and honest limitations.78- Point to evidence whenever possible.79- Be especially skeptical of integrations, auth, billing, browser automation, and generated README claims.80- If the output is good, say so plainly and still name the remaining risk.
aimonj0729-ai