Problem
skills/orchestrate/templates/session-prompt.md §3 / §O3 hands a worker:
Address the issues in .orchestration/reviews/{TASK}-r{N}.md
The coordinator sees the diff. It does not see the worker's local reasoning —
the constraint it hit, the alternative it rejected, the upstream signature it had
to match. A review written as "change X to Y" therefore forces compliance through
an information gap.
With an LLM worker this is worse than with a human reviewee, not better: the
worker will comply with a wrong directive without pushing back, because compliance
is cheap and the protocol never asks it for its reason. A human would argue.
Proposal
Fix the format of a review finding to three parts:
- Observation — what the diff does, quoted at
file:line.
- Failure scenario — the concrete inputs/state that make it wrong. A finding
that cannot state one is a preference, and belongs in a separate
non-blocking section.
- Question — "why this way?" rather than "do it this way".
And a matching worker obligation in §3/§O3: fix it, or answer with the reason and
leave it — silence is not a valid resolution either way.
Requiring part 2 also filters the reviewer: a finding without a failure scenario
usually turns out to be taste.
Why
"Reviewing code is a skill"
proposes Socratic review as its first experiment — the reviewer asks why an
approach was chosen instead of stating what is wrong, targeting the reviewee's
reasoning rather than the single line. The article aims it at junior/senior human
pairs; the compliance asymmetry makes it apply harder to an LLM worker.
Scope
Evidence status
The compliance asymmetry is [추정] — reasoned from how the worker protocol is
written, not measured on a run. The information gap it rests on is structural and
verifiable: the coordinator reads only git diff, never the worker's transcript.
Source
Problem
skills/orchestrate/templates/session-prompt.md§3 / §O3 hands a worker:The coordinator sees the diff. It does not see the worker's local reasoning —
the constraint it hit, the alternative it rejected, the upstream signature it had
to match. A review written as "change X to Y" therefore forces compliance through
an information gap.
With an LLM worker this is worse than with a human reviewee, not better: the
worker will comply with a wrong directive without pushing back, because compliance
is cheap and the protocol never asks it for its reason. A human would argue.
Proposal
Fix the format of a review finding to three parts:
file:line.that cannot state one is a preference, and belongs in a separate
non-blocking section.
And a matching worker obligation in §3/§O3: fix it, or answer with the reason and
leave it — silence is not a valid resolution either way.
Requiring part 2 also filters the reviewer: a finding without a failure scenario
usually turns out to be taste.
Why
"Reviewing code is a skill"
proposes Socratic review as its first experiment — the reviewer asks why an
approach was chosen instead of stating what is wrong, targeting the reviewee's
reasoning rather than the single line. The article aims it at junior/senior human
pairs; the compliance asymmetry makes it apply harder to an LLM worker.
Scope
skills/orchestrate/templates/session-prompt.md§3 and §O3.reviews/<task>-rN.mdtemplate shared with orchestrate: Phase 4 review is one sentence — give it a fixed four-lens pass #82.Evidence status
The compliance asymmetry is [추정] — reasoned from how the worker protocol is
written, not measured on a run. The information gap it rests on is structural and
verifiable: the coordinator reads only
git diff, never the worker's transcript.Source
Socratic dialogues)