You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
skills/orchestrate/SKILL.md:479-482 is the entire Phase 4 review method:
Review each worktree diff (git -C <wt> diff <integ>...HEAD); if a session's
tests look weak, cross-call test-quality-auditor yourself.
No checklist, no wiki grounding, no obligation to look across worktrees. The only
mechanised part is test quality — code correctness and design get whatever the
coordinator improvises.
Proposal
Replace the sentence with a fixed pass of four lenses:
Plan conformance — diff against the plan's decision→page map and the brief's <scope_boundaries> / <out_of_scope>. A decision silently made differently at
implement time is a defect even when the code works.
Execution-environment reality — for any newly introduced flag, subcommand,
API or dependency: confirm it exists in the version present where the code
actually runs (CI image, the worker's runtime, the user's shell), not on the
machine that wrote it.
Multi-object write ordering — any change writing 2+ files/objects/rows
without a transaction, and any ordering a concurrent reader can observe
mid-flight.
Lens 4 is coordinator-only leverage: the coordinator is the single reviewer that
sees every worktree at once. A worker reviewing its own worktree structurally
cannot see a cross-task ordering hazard.
Why these four
Lenses 3 and 4 are the two defect classes from "Reviewing code is a skill"
that the LLM reviewer missed and the human caught (--progress-seconds absent in
the CI's older AWS CLI; a tarball uploaded before its sidecar checksum, so a reader
that fails closed breaks if the job dies between the two writes).
Problem
skills/orchestrate/SKILL.md:479-482is the entire Phase 4 review method:No checklist, no wiki grounding, no obligation to look across worktrees. The only
mechanised part is test quality — code correctness and design get whatever the
coordinator improvises.
Proposal
Replace the sentence with a fixed pass of four lenses:
<scope_boundaries>/<out_of_scope>. A decision silently made differently atimplement time is a defect even when the code works.
reviewer reached that the plan never named.
API or dependency: confirm it exists in the version present where the code
actually runs (CI image, the worker's runtime, the user's shell), not on the
machine that wrote it.
without a transaction, and any ordering a concurrent reader can observe
mid-flight.
Lens 4 is coordinator-only leverage: the coordinator is the single reviewer that
sees every worktree at once. A worker reviewing its own worktree structurally
cannot see a cross-task ordering hazard.
Why these four
Lenses 3 and 4 are the two defect classes from
"Reviewing code is a skill"
that the LLM reviewer missed and the human caught (
--progress-secondsabsent inthe CI's older AWS CLI; a tarball uploaded before its sidecar checksum, so a reader
that fails closed breaks if the job dies between the two writes).
Scope
skills/orchestrate/SKILL.mdPhase 4.skills/orchestrate/templates/forreviews/<task>-rN.md(shared with orchestrate: review comments to a worker must carry a failure scenario and a question, not a directive #84).Evidence status
The gap is verified (the quoted lines are the whole method). The four-lens
decomposition is a design proposal.
Source