Inspect another resource purpose
Compare skills, references, workflows, and advisory guidance.
Open this resource →Workflow explanation
Find the consequence behind the changed line.
Understand Evidence-based PR review through caller tracing, a pagination example, and findings supported by actual evidence.
Review the proposed behavior, then explain any established defect so the author can act. Explore the workflow through a bounded pagination change.
01 / Workflow explanation
Review a change by following its consequences
A proposed search-api patch changes the page cursor. The edited function is small, but several callers reuse its output for the next request.
The reviewer needs to understand what those callers expect before deciding whether the patch preserves pagination behavior.
Evidence-based PR review organizes this investigation. It aims for findings another developer can act on, with a clear trigger and a relevant location.
The scenario on this page is fictional. It illustrates review decisions and does not allege a defect in Betterloop or another real service.
The workflow depends on Delivery evidence so the final report can distinguish established findings, executed checks, and remaining uncertainty.
A successful review need not produce a finding. Its value depends on the quality of the investigation and the accuracy of its conclusions.
02 / Workflow explanation
Catalog identity for this example
| Catalog property | Recorded value |
|---|---|
| Published resource name | Evidence-based PR review |
| Catalog identifier | betterloop.pr-review |
| Type | Workflow |
| Version | 1.0.0 |
| Maintainer | Betterloop platform catalog |
| Catalog state | Ready for selection |
| Company review state | Company approval is still required for release |
| Declared clients | Claude Code and Codex |
| Dependencies | Delivery evidence, version 1.0.0 |
| Required configuration | No company-specific values are declared |
| Permissions | Selection supplies no extra authority |
03 / Workflow explanation
A fresh explanation of the workflow
Read the repository's expectations alongside the proposed patch. A changed line only becomes incorrect in relation to a behavior or contract.
Follow affected callers beyond the diff. A compatible-looking signature can still change ordering, error handling, or the meaning of a returned value.
Inspect relevant failure paths and data boundaries. Happy-path execution can leave important behavior unexamined, especially when identity or tenant scope is involved.
Establish evidence before writing a finding. A complete source trace can be sufficient when execution is unavailable, but incomplete assumptions need qualification.
Give the author a precise location and an understandable consequence. Personal preference should not be presented as a defect without a relevant repository requirement.
This is explanatory prose about WORKFLOW.md. It is not a catalog excerpt or a new instruction file delivered to the native agent.
04 / Workflow explanation
Orient the review before judging the patch
- 01
Read the requested review scope
Identify the proposed revision and the boundaries of the assignment.
- 02
Read repository instructions
Find the contracts relevant to pagination and callers.
- 03
Inspect the changed behavior
Determine how cursor creation differs from the earlier revision.
- 04
Trace consumer expectations
Follow the next-page request through representative callers.
- 05
Inspect available checks
Determine which tests exercise adjacent-page continuity.
- 06
Choose the evidence path
Use meaningful execution or a complete source trace for each concern.
05 / Workflow explanation
Investigate a skipped-result concern
In the example, the patch builds the next cursor from the item after the last displayed result. A caller then excludes the cursor item.
That combination could skip a result. Before writing a finding, inspect whether the service instead uses inclusive lookup or returns the cursor item separately.
Read the query and the caller together. Confirm the ordering contract so the apparent gap cannot be explained by a different documented cursor meaning.
Practice finding record:
Condition: the caller requests a second page using the returned cursor.
Relevant change: the cursor is built from the next undisplayed item.
Source relationship: the query excludes the cursor item.
Consequence: that item can be absent from both displayed pages.
Limit: record whether the sequence was executed or established by source inspection.Locate the finding at the changed cursor construction. The surrounding explanation should give the author enough context to reproduce or inspect the issue.
If a focused check exists, execute it and inspect the actual result. Otherwise, explain the source relationship and its untested runtime assumptions.
06 / Workflow explanation
Judge the finding before sending the report
| Review question | Evidence that helps | Reason to reconsider |
|---|---|---|
| What triggers the issue? | A particular caller action and input sequence. | The concern requires an impossible state. |
| Which contract is violated? | Documented pagination behavior or established consumers. | The behavior is permitted by the current contract. |
| How does the patch cause it? | A trace from the changed cursor to the excluding query. | The relevant behavior predates the patch without a new connection. |
| Where should the author look? | The smallest relevant changed location. | A broad file reference hides the actual cause. |
| What remains unknown? | Explicit execution limits or missing runtime facts. | The report claims certainty while those assumptions remain unresolved. |
07 / Workflow explanation
Avoid turning every concern into a finding
A possible cursor issue can disappear after caller inspection. Keep that resolution in your reasoning rather than retaining a weak comment for completeness.
Tests may also reveal an existing inclusive cursor contract. Reassess the concern when new evidence contradicts the initial interpretation.
An implementation style you would not choose can still preserve the contract. Explain a material consequence before labeling a different style as incorrect.
Finding count is a poor evaluation target. It can encourage speculative defects and hide a careful review that found no established issue.
If no findings survive investigation, report that outcome with the actual scope and important limits. Avoid claiming that the entire service is defect-free.
Keep pre-existing issues distinct from the proposed change unless the review explicitly includes them. A useful observation still needs the correct scope.
08 / Workflow explanation
Keep review and publication separate
This workflow supports a local review of a proposed change. Selecting it does not post comments, edit source, merge a pull request, or configure branch protection.
Read-only review can involve permitted diagnostic execution. Native tool permission and the task's authorization still determine what the agent may do.
Publishing findings requires the appropriate authorization. A request for analysis alone should not silently become an external comment or a modified pull request.
If the user later requests a repair, switch to the relevant implementation instructions. A review report does not establish that a patch has been applied or verified.
A repository-wide security audit also needs its own scope and workflow. This resource focuses on the proposed change and the affected behavior.
When source or checks are unavailable, identify the missing evidence. Do not replace the inaccessible implementation with an imagined one.
09 / Workflow explanation
Evaluate the workflow on a representative patch
Confirm that betterloop.pr-review 1.0.0 and Delivery evidence 1.0.0 can be retrieved from the intended reviewed release.
Use a small proposed patch with a contract you can inspect. Keep its relevant callers and tests available to the reviewing agent.
Assess whether the review follows consequences outside the diff. Read each finding beside the source relationship or check that supports it.
Inspect the final report for overstated test coverage. A passing suite does not rule out a pagination sequence absent from its assertions.
If retrieval fails, investigate release selection and dependencies. If reasoning is weak, examine whether the task provided access to the relevant contract and callers.
Use the resulting observations to decide whether the resource fits your review practice. Keep content availability and review quality as separate results.
10 / Workflow explanation
Keep the report useful for the author
Lead each established finding with the behavior that breaks. Follow it with the trigger, relevant location, and supporting evidence.
State uncertainty where it affects the conclusion. The author should know whether a problem was executed, established by source, or remains an unverified concern.
Keep routine exploration out of the main finding. A precise explanation gives the author a shorter path from review to a justified correction.
11 / Workflow explanation
Questions during a patch review
Must every finding include a failing test?
No. A complete source trace can establish a defect. Identify execution limits where they affect confidence.
What if the review finds no established defect?
Report that outcome honestly. Describe the relevant scope and unresolved checks without inventing comments.
Does selecting this workflow authorize posting the report?
No. Publication remains a separate action that needs authorization. The workflow can produce a local report.
12 / Workflow explanation
Take the example through your own review
The public explanation is a starting point for evaluation. Inspect the exact resource files selected by your company before accepting a configuration change.
Keep the catalog identity and dependency versions attached to that review. The reviewed release should supply the same content the owners examined.
Selection creates reviewable configuration content; it does not by itself approve or activate it. Follow the normal signing and team adoption process.
On the developer device, complete required native trust and session activation. Then examine resource retrieval and the representative task as separate observations.
A signed release establishes the reviewed content and scope. It does not guarantee that the native agent follows every instruction.
Use the approval workbook when the example requires additional operations. Resource advice and authority to execute a tool remain distinct decisions.