Final Diff Review
Definition
Read the exact final diff before delivery. Confirm every changed line belongs to the feature, has been verified, and does not hide accidental or unrelated work.
Questions To Ask
- Which files changed, and why?
- Are any changes unrelated to the feature?
- Are there secrets, local config, generated artifacts, or debug code?
- Do tests and docs match the final behavior?
- Are user changes preserved and excluded from the commit if unrelated?
Existing Project Comparison
- Compare the final diff against
FEATURE_DELIVERY.md, tests, docs, and known project rules.
- Check deleted files, migrations, public APIs, dependency changes, and lockfiles with extra care.
- Verify the diff keeps naming, formatting, and architecture consistent with nearby code.
Suggestive Plan
- Inspect changed-file summary.
- Read the full diff for files in scope.
- Classify each change as feature, test, doc, generated, unrelated, or risky.
- Fix or exclude accidental changes.
- Record the final diff review in
FEATURE_DELIVERY.md.
Example
Before committing invoice resend, confirm route, service, tests, and docs changed; exclude a local .env edit and an unrelated formatting pass.
Vocabulary
- Diff: exact changed lines compared with the base version.
- Unrelated change: edit not needed for the feature outcome.
- Generated artifact: tool-produced file that may not belong in source control.
- Delivery risk: issue that could break users or make maintenance harder.
Expected Outcome
Produce a reviewed final diff with only intended changes, no secrets or accidental artifacts, known risks documented, and commit-ready files identified.
1---2name: final-diff-review3description: Review the final local diff before delivery, commit, or push. Use when checking changed files for accidental edits, unrelated changes, secrets, generated artifacts, missing tests, stale docs, design regressions, and user-work preservation.4---56# Final Diff Review78## Definition910Read the exact final diff before delivery. Confirm every changed line belongs to the feature, has been verified, and does not hide accidental or unrelated work.1112## Questions To Ask1314- Which files changed, and why?15- Are any changes unrelated to the feature?16- Are there secrets, local config, generated artifacts, or debug code?17- Do tests and docs match the final behavior?18- Are user changes preserved and excluded from the commit if unrelated?1920## Existing Project Comparison2122- Compare the final diff against `FEATURE_DELIVERY.md`, tests, docs, and known project rules.23- Check deleted files, migrations, public APIs, dependency changes, and lockfiles with extra care.24- Verify the diff keeps naming, formatting, and architecture consistent with nearby code.2526## Suggestive Plan27281. Inspect changed-file summary.292. Read the full diff for files in scope.303. Classify each change as feature, test, doc, generated, unrelated, or risky.314. Fix or exclude accidental changes.325. Record the final diff review in `FEATURE_DELIVERY.md`.3334## Example3536Before committing invoice resend, confirm route, service, tests, and docs changed; exclude a local `.env` edit and an unrelated formatting pass.3738## Vocabulary3940- Diff: exact changed lines compared with the base version.41- Unrelated change: edit not needed for the feature outcome.42- Generated artifact: tool-produced file that may not belong in source control.43- Delivery risk: issue that could break users or make maintenance harder.4445## Expected Outcome4647Produce a reviewed final diff with only intended changes, no secrets or accidental artifacts, known risks documented, and commit-ready files identified.
harsh817