cglearn — Practice a better workflow

01 / PREDICT

A reviewer reports nine findings. Is resolving all nine always a better outcome than investigating which ones are supported?

Your prediction

Write a brief prediction before opening the explanation.

02 / EXPLAIN

Read the lesson

Classify the finding before fixing it

A useful defect report connects a location to a failing behavior under stated conditions. A suspicious pattern may justify investigation without proving a bug. A naming preference or proposed new abstraction may be reasonable yet unrelated to the requested review. Ask what evidence would establish the claim, and classify it before changing code. A second agent can provide another perspective; it is not an authority whose confidence replaces evidence.

Give the reviewer a bounded job

Specify the diff or commit, acceptance criteria, risks and scope of the review. Ask for concrete failure paths and relevant missing tests. Keep implementation and review roles clear: identifying a risk does not itself authorize a rewrite or grant access to private systems. Repository changes made by other people may also be present, so inspect the intended review scope before treating every visible edit as part of the task.

Use uncertainty without inventing certainty

When a claim is incomplete, more than one next action can be defensible. You can ask the reviewer for the missing caller evidence or investigate the call path yourself. Both are stronger than deleting supposedly unused code based on a label alone. When evidence contradicts a finding, explain why it is dismissed. When evidence supports it, make a bounded correction and verify the behavior. Preserve unresolved risks explicitly rather than labeling them fixed.

Common mistake

Treating a reviewer’s confidence or number of findings as evidence of correctness.

03 / DEMONSTRATE

Make the request actionable

A weak starting brief: Fix every finding from the reviewer, then say the pull request is ready.

Review the selected diff against the task criteria. For each finding, identify the location, claimed failure conditions and supporting evidence. Separate demonstrated defects, unresolved risks and optional style suggestions. Investigate unsupported claims before editing; propose narrowly scoped corrections for confirmed defects and record anything still unverified.

This example is an adaptable request, not evidence that a runtime action has executed.

04 / PRACTICE

The supposedly unused option

Reviewer: “Remove retryLimit; it is never read.” The finding shows a declaration but no caller trace. The task changes a timeout message only. No reproduction is supplied.

Simulated scenario · No repository access or command execution

Which next action is defensible? More than one choice can be supported.Remove retryLimit immediately because the reviewer checked it.Ask for caller or configuration evidence showing the option is unused before deciding on a change.Inspect references and configuration consumers yourself, preserving the option until its behavior is established.Replace the retry system with a new abstraction while addressing the message.

Loading your saved lesson progress…