Workbench Review QA

Use this skill for code review, workflow review, QA verification, release checks, and issue closeout.

Verdicts

• PASS: objective is met and evidence is sufficient.
• FLAG: useful progress, but a non-blocking issue or missing evidence remains.
• BLOCK: objective is not met, unsafe, unverifiable, or materially wrong.

Review Method

1. Identify the promised objective.
2. Inspect the real output, diff, issue comments, runtime state, or checked-out repo.
3. Compare evidence against the objective.
4. Verify the smallest real path that proves the claim.
5. Report findings first, ordered by severity.
6. Check command syntax and live-resource ownership when the work involves Multica CLI mutations.
7. If duplicate comments or artifacts exist, identify the primary artifact and explain why.
8. For GOAL_MODE: yes or /goal work, compare the closeout against the locked objective and every required closeout gate.

Findings Format

For problems, return:

• severity,
• location or evidence,
• why it matters,
• required fix or next verification.

For clean reviews, return:

• verdict,
• VERDICT_SUMMARY: three lines or fewer,
• evidence checked,
• residual risk or test gap.

Every SDD review should include VERDICT_SUMMARY so the next agent can continue from the review header without re-reading the full review body.

Auto Review Sweeper

For automatic in_review handoffs, use this exact block on each reviewed target:

AUTO_REVIEW
TARGET: <identifier>
VERDICT: PASS | FLAG | BLOCK
VERDICT_SUMMARY: three lines or fewer
EVIDENCE: concrete issue/comment/run IDs, commands, or file paths checked
STATUS_ACTION: done | kept in_review | blocked | no_change
NEXT_ACTION: exact next owner/action, or none

• PASS may move the target issue to done only when the original goal is satisfied and no required follow-up remains.
• FLAG leaves the issue in in_review with a bounded next action.
• BLOCK sets the issue to blocked with blocking evidence.
• If evidence is still arriving, leave the issue unchanged and mark it pending in the sweep summary.

QA Rules

• Do not accept done based on paraphrase alone.
• Distinguish content failures from workflow/tooling failures.
• If repo access is needed, prefer the issue's project-bound GitHub repo resource and report the commit/branch inspected.
• For Goal Mode tasks, PASS requires evidence for the locked objective plus all relevant build/test/help-smoke/docs-or-report/git-status gates, or an explicit rationale for each non-applicable gate.
• Treat file://<LOCAL_WORKBENCH_REPO> as laptop-local fallback only; remote runtimes must flag it as invalid unless explicitly mounted.
• Keep evidence concise and reproducible.
• Verify Workbench Max remains untouched when a task says it must be preserved.