wb-flow

Appearance

/wbValid — Practical ​

The forms ​

/wbValid <plan-file> # status check (no validation)
/wbValid <plan-file> --id=2 # validate task 2
/wbValid <plan-file> --id=1,2,3 # validate tasks 1, 2, 3
/wbValid <plan-file> * # validate all "Done but not Valid" tasks
/wbValid <plan-file> --id>2&&--id<=5 # AND logic: tasks 3, 4, 5
/wbValid <plan-file> --id<2||--id>5 # OR logic

When to run ​

  • Right after /wbWork finished a batch. Validation should be the next thing — never let Done-but-not-Valid rows pile up.
  • Before merging a branch. Any unvalidated row is a known-untested change.
  • Before /wbRelease. A package with Done-but-not-Valid rows is not release-ready.

When not to run ​

  • With the same model that ran /wbWork. This is the single most important rule — see the verdict section below.
  • On a task whose Done cell is still ⬜. There's nothing to validate. Run /wbWork first.
  • On a task whose Valid cell is already ✅. It's frozen; re-validating wastes the call.

What it does, in order ​

  1. Locates the plan (same lookup as /wbWork).
  2. Parses intent.
  • No flags → status check: lists tasks that are ✅ Done but ⬜ Valid. No mutations.
  • With --id or * → validation mode.
  1. For each target task:
  • Reads tasks/task_<ID>/task_<ID>_report_<TARGET>_<YYYYMMDD>.md — the worker's claim.
  • Inspects the actual codebase to verify the claim.
  • Appends a PASS or FAIL section to the bottom of the worker's report (does not overwrite).
  1. Updates the plan:
  • PASS → ☐ Valid becomes ✅<br>ValidatorModelName.
  • FAIL → Done cell resets to ⬜, Valid stays ⬜. The user is told to re-run /wbWork --id=<ID>.
  1. Tells you what's next — usually /wbRelease if all rows now pass, or specific failed IDs if some didn't.

What you get back ​

For each validated task:

  • PASS → an appended ## ✅ Validation by <model> section in the worker's report. Plan row gets the green check.
  • FAIL → an appended ## ❌ Validation by <model> section explaining what was wrong. Plan row's Done resets; the failure history is preserved at the bottom of the worker's report.

What /wbValid will refuse to do ​

  • Re-validate a ✅ Valid task. Validated work is frozen. Reset the plan manually if you really want a re-run.
  • Validate a task with no worker report. No artifact = nothing to validate. Run /wbWork first.
  • Modify the worker's report mid-document. Validation always appends to the bottom; the worker's claim and the validator's verdict stay separated.

Flags & shortcuts ​

Long formShortcut
--id-i

--id accepts: comma lists (--id=1,2,3), comparators (--id>2, --id<=5, --id!=4), boolean composition (&&, ||), and the wildcard token * (no flag — bare * arg = "all done-but-not-valid tasks"). Universal: -h / --help / --h print this manual.

The mistake to avoid ​

Running /wbValid with the same model that ran /wbWork. This is the echo chamber: the model sees its own report, recognizes its own writing, and validates by familiarity instead of by inspection. The whole point of the Plan→Work→Valid split is to introduce an adversarial second opinion. Skip the second model and you've just re-run the worker twice.

The corollary: when the plan was generated by the same model that's about to validate it, the chain breaks at the planning step instead of the validation step. Same fix: rotate models across the three phases.

Recommended pairing:

  • /wbWork → the agent the AI agent (precise worker)
  • /wbValid → the AI agent or the AI agent (different model, deep reasoning)