| name | self-review-gate |
| description | This skill must be used before claiming done/ready after plans, implementations, verification, prompt/workflow changes, viewer/UI changes, or skill/agent changes. It runs plan or delivery self-review, requires gaps to be fixed, and then reruns relevant checks before completion. |
| version | 0.1.0 |
Self Review Gate
Mission
Prevent shallow completion. Use this gate to review the plan or finished change before presenting it as ready. The gate is not a separate user-visible phase unless it finds issues; it is a quiet quality loop that forces fixes when the work does not yet satisfy the user's actual request.
When To Run
Run this gate automatically at these checkpoints:
- After creating a plan package or a substantial inline plan.
- Before starting implementation from a plan that was just created.
- After completing a feature, bug fix, viewer/UI change, prompt/workflow change, skill change, agent change, or CLI behavior change.
- After tests pass but before saying
done, fixed, ready, or equivalent.
- When a plan package, contract, task list, change record, experiment package, or architecture map exists and should define acceptance.
Skip only for tiny read-only answers, pure status reports, or exploratory brainstorming that does not claim delivery.
Plan Self-Review
For plans, check:
- User intent: every explicit user requirement is represented.
- Scope: affected files/modules and non-goals are clear.
- Specificity: each plan item names concrete objects and observable behavior, not generic verbs like improve or optimize alone.
- Feasibility: dependencies, blockers, cost, and rollback paths are credible.
- Verification: each task has a way to prove success.
- Traceability: requirements, plan items, tasks, and future change records can be linked.
- Risk: prompt/workflow, data, security, long-running, or UI review risks are named when relevant.
If any item fails, revise the plan before implementation or before asking the user to approve it.
Delivery Self-Review
For completed work, check:
- Intent alignment: the user-facing outcome matches what the user asked for, not just what was easy to implement.
- Completeness: each requirement has a changed file, behavior change, test/review evidence, or explicit non-goal.
- Integration: new code, schema, tests, docs, profiles, catalogs, commands, and runtime prompts are connected where needed.
- Quality: implementation follows local patterns, has no obvious dead code, accidental coupling, fragile fallback, or hidden external dependency.
- Evidence: verification commands, smoke checks, self-audit findings, or manual review results support the claim.
- Records: change/experiment/state assets describe what actually happened and do not repeat an unexecuted plan as if it were done.
- Residual risk: unresolved issues are named plainly and do not block the claimed outcome.
If any blocking issue appears, fix it and rerun the relevant verification before reporting completion.
Output Discipline
Do not dump the full checklist by default. In the final answer, summarize only:
- self-review result: passed, fixed issues, or blocked
- important corrections made because of the review
- remaining risk, if any
When the review finds no issues, one short line is enough.
Quality Bar
The gate passes only when:
- user intent, implementation, validation, and records agree
- tests passing are treated as evidence, not as the whole definition of done
- high-impact prompt/workflow changes include a prompt-quality self-audit
- UI/viewer changes include a user-perspective readability and interaction review
- skill changes include trigger quality, scope, progressive disclosure, and structural integrity review
References
Load only when a concrete output shape is needed:
references/examples.md - compact examples for plan, delivery, blocked, and final self-review summaries.
