# Coding-Agent Change Attribution and Test Evidence Review

Amo ID: AMO-P-000276
Version: 1.0.0
Public URL: https://amo.ng/prompts/coding-agent-change-attribution-and-test-evidence-review

Summary: Review a coding-agent change set against its instructions, transcript, diff, and test evidence to determine whether the agent’s completion claims are supportable.

Use this for: Use this to attribute coding-agent changes, separate intended edits from drift, and verify whether test evidence supports merge claims.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: review

## Best Use Cases

1. Agent-Generated Pr Provenance Review
2. Instruction-To-Diff Compliance Check
3. Test Evidence Reconciliation
4. Unexplained Code Drift Register
5. Merge Readiness Recommendation
6. Agent Completion Claim Audit

## Prompt Body

Review the coding-agent change set and run evidence for provenance, instruction compliance, and support for completion claims. Focus on what can be observed from the supplied repository, diff, transcript, and test evidence. Do not perform a generic PR review unless it is necessary to attribute a material change or assess whether a completion claim is supported.

Context to provide:
- Repository scope and task: [Repository scope and task]
- Relevant files and instructions: [Relevant files and instructions]
- Observed evidence: [Observed evidence]
- Constraints and authorized changes: [Constraints and authorized changes]
- Environment details without secrets: [Environment details without secrets]
- Verification commands and acceptance criteria: [Verification commands and acceptance criteria]

Review rules:
1. Inspect the relevant files, diffs, transcript, and test evidence first before drawing conclusions.
2. Distinguish observation from inference. Mark unsupported assumptions as missing information.
3. Do not claim that a file, command, test, approval, system, or external source was inspected or completed unless there is evidence in the provided materials or you actually inspected or ran it in the available environment.
4. Attribute each material change to one of these categories:
   - Directly instructed
   - Reasonably necessary to satisfy the instruction
   - Incidental but explainable
   - Unexplained drift
   - Potentially harmful or out of scope
5. Treat a change as material if it affects behavior, public API, data model, security posture, dependency surface, build/test configuration, generated artifacts, migrations, operational behavior, or protected behavior listed by the release owner.
6. Preserve existing behavior as the default expectation. Flag behavior changes that are not explicitly instructed or clearly necessary.
7. Avoid broad rewrites and style-only judgments unless they obscure attribution, create risk, or conflict with project conventions.
8. If you identify a defect and decide to edit code, first identify the likely root cause, then apply the smallest safe change that preserves existing behavior. Do not perform broad rewrites. Run syntax checks and tests where available, then summarize files changed and verification results. If editing is not requested or not safe, provide proposed changes only.
9. Run or recommend syntax checks and tests where available and proportionate. If you cannot run them, state exactly what evidence is missing and what the test owner or release owner should run.
10. Do not recommend merge solely because the agent said the work was complete. Completion claims must be reconciled against observable diff and test evidence.

Deliverable:

## 1. Review Scope and Evidence Used
List the materials actually inspected:
- Instructions reviewed
- Transcript or completion notes reviewed
- Files or diffs reviewed
- Tests, logs, or command outputs reviewed
- Repository context used
- Evidence not provided or not inspectable

## 2. Agent Completion Claims
Create a table with these columns:
- Claim made by agent
- Evidence offered by agent
- Evidence independently visible in supplied materials or environment
- Supported, partially supported, unsupported, or contradicted
- Notes for release owner or test owner

## 3. Instruction-to-Diff Trace
Map the original instruction to the observed changes.

Use this table:
- Instruction requirement
- Related files or hunks
- How the change satisfies the requirement
- Evidence level: direct, inferred, weak, or missing
- Compliance assessment

Call out any instruction requirement that appears unimplemented, only partially implemented, or implemented through an unexpected approach.

## 4. Change Attribution Ledger
Create a ledger for each material changed area.

Use this table:
- File or component
- Material change observed
- Attribution category
- Evidence supporting attribution
- Behavior or interface impact
- Risk level: low, medium, high
- Owner who should verify: release owner, test owner, security reviewer, data owner, product owner, or other specific accountable role

## 5. Unexplained-Change Register
List all changes that cannot be clearly tied to the instruction or necessary implementation path.

For each item include:
- File or hunk
- What changed
- Why attribution is unclear
- Potential consequence
- What evidence would resolve it
- Recommended handling: accept with owner verification, revert, isolate into separate change, or investigate before merge

## 6. Test Evidence Reconciliation
Assess whether the supplied tests and logs support the completion claims.

Include:
- Commands claimed to have run
- Commands evidenced by logs or terminal output
- Pass/fail status shown by evidence
- Coverage relevance to the changed behavior
- Gaps, skipped tests, stale outputs, or ambiguous timestamps
- Additional checks the test owner should run before merge

If you run any commands, list:
- Command
- Purpose
- Result
- Relevant output summary
- Any limitations

If no commands were run, say so explicitly.

## 7. Risk and Protected Behavior Review
Evaluate only the risks that arise from attribution, instruction compliance, or evidence gaps.

Cover applicable areas:
- Behavior drift
- Public API or contract change
- Data migration or persistence risk
- Authentication, authorization, or secrets handling
- Dependency or build-system changes
- Generated files or lockfiles
- Test configuration changes
- Operational or deployment implications

## 8. Merge Recommendation
Choose one recommendation:
- Merge: evidence supports the agent’s claims and material changes are attributable
- Merge after owner verification: residual gaps are narrow and assigned to accountable owners
- Do not merge yet: unsupported claims, unexplained drift, insufficient tests, or high-risk uncertainty remain
- Rework required: changes are out of scope, unsafe, or not traceable to the instruction

Include:
- Recommendation
- Primary reasons
- Required pre-merge checks
- Owners responsible for verification
- Conditions that would change the recommendation

## 9. Completion Check
Before finalizing, confirm:
- Relevant files and evidence were inspected first
- Material changes were attributed
- Intended edits were separated from incidental or unexplained drift
- Agent claims were reconciled with test evidence
- Missing evidence and uncertainty were explicitly stated
- Any commands run are reported with results, or lack of execution is stated
- Any files changed by you are summarized, with syntax/test verification results where available

## Variables to Replace

1. Repository scope and task
2. Relevant files and instructions
3. Observed evidence
4. Constraints and authorized changes
5. Environment details without secrets
6. Verification commands and acceptance criteria

## How to Use

Use this in Codex with the repository or PR available. Paste the original agent instruction, the agent transcript or completion notes, the diff or changed files, test logs, command outputs, merge target, and any protected behavior. Replace every bracketed placeholder, then run the prompt. Afterward, have the release owner validate the merge recommendation and the test owner confirm any missing or rerun test evidence before merge.

## Example Use Case

A release owner receives a coding-agent PR that claims it fixed a checkout retry bug and passed tests. They run this prompt in Codex with the diff, transcript, and CI logs to identify which changes were instructed, which dependency and formatting changes are unexplained, whether the claimed tests actually ran, and whether the PR should merge or return for rework.

## Tags

1. codex
2. merge-readiness
3. code-review
4. verification
5. repository-aware-coding
6. audit-evidence
7. evidence-based-testing
8. change-control

## Dates

Published: 2026-08-19
Updated: 2026-08-19