// Blog / team workflow
How to review PR impact for coding agents
A coding-agent PR should not only show what changed. It should show which module boundary, trust state, and evidence were affected.
// direct answer
Short answer
Review PR impact by mapping changed files to modules, checking trust and freshness state, listing affected critical paths, verifying source and tests, and surfacing repair items in a PR summary. The goal is to make the agent's context auditable by the reviewer.
Review AI-generated PRs with context about module impact, trust, and evidence.
// real failure mode
The failure mode
A small PR can cross a module boundary the agent did not understand.
The diff might pass superficial review while relying on stale context or missing tests.
Reviewers need a compact way to see what the agent thought it touched and what trust state surrounded that area.
// review model
The repo-local fix
.knowledge can generate a PR-facing summary of trust, health, and repair state.
The reviewer can compare changed files against module cards, evidence, and critical paths before approving the diff.
Inspector Pro can turn that into a visual PR impact card, but the open core still keeps the underlying artifacts in the repo.
// concrete example
A three-file PR across a suspect boundary
An agent changes a runtime file, a policy file, and a test helper. The diff is small, but the module boundary is suspect.
The PR impact review should flag the boundary, require source and tests, and show which evidence was checked.
If evidence is missing, the reviewer sees that as review debt instead of discovering it after merge.
// repo proof
Repo proof to inspect
.knowledge/maintenance/pr_summary.md
The PR summary compresses trust, health, and repair state into reviewer-facing context.
- Review handoff
- Checking changed context
- Replacing code review
- Approving untested behavior
.knowledge/maps/file_criticality.json
Criticality maps help the reviewer see whether changed files touch risky paths.
- Prioritizing review
- Finding critical-path changes
- Assuming non-critical means safe
.knowledge/modules/*.json
Module cards help map changed files to ownership and trust state.
- Boundary review
- Finding affected modules
- Skipping current source reads
.knowledge/evidence/*.json
Evidence shows which checks or files back the agent's assumptions.
- Review traceability
- Finding missing checks
- Assuming old checks still pass
// command transcript
Commands and expected checks
node .knowledge/tools/generate-pr-summary.js - expected
- A PR-facing trust and repair summary is generated.
- inspect next
- .knowledge/maintenance/pr_summary.md
node .knowledge/tools/doctor.js - expected
- Knowledge health is checked before review handoff.
- inspect next
- .knowledge/maintenance/quality_report.json
node .knowledge/tools/build-routing-bundle.js - expected
- Routing reflects current module boundaries before the review.
- inspect next
- .knowledge/maintenance/routing_bundle.json
What the reviewer needs before approval
// field guide
PR impact review checklist
| Review area | Question | Action |
|---|---|---|
| Changed files | Which modules are touched? | Map files to module cards. |
| Trust | Are affected modules trusted? | Re-read source when trust is weak. |
| Tests | What proves behavior? | Run or inspect relevant tests. |
| Evidence | What backs the agent's plan? | Check evidence files or note gaps. |
| Repair | What uncertainty remains? | Assign or document before merge. |
// guardrails
What the agent should not trust blindly
- Never approve a behavior-changing PR from summary alone.
- Treat suspect or low-confidence modules as mandatory source-review zones.
- If the agent cannot identify tests, make that visible in the PR summary.
// common mistakes
Common mistakes
- Reviewing only the diff and not the module boundary.
- Letting an agent summarize tests it did not inspect.
- Hiding unresolved repair items from the reviewer.
// quick FAQ
FAQ
Is PR impact review only for large changes?
No. Small changes can cross risky boundaries. The workflow can be lightweight, but it should still map files, trust, evidence, and tests.
Can the PR summary be generated automatically?
Yes, the open core can generate a PR summary from repository artifacts. Human review still decides whether the diff is acceptable.
// page-specific next step
Use this page for AI-generated PRs
Require the agent to attach module impact, trust state, evidence, tests, and repair items before reviewer handoff.