Render the patch-edit run's accumulated changes as a reviewable diff, surface it through a GenUI choice surface, and persist the user's accept / reject decision into the artifact manifest.
66
80%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./plugins/_official/atoms/diff-review/SKILL.mdSpec §20.3 / §21.3.2: a code-migration / tune-collab handoff is worthless without a human-reviewable diff. This atom is the "present the patch, capture the decision" stage.
plan/steps.json for context per file.project-cwd/
└── review/
├── diff.patch # unified diff (git apply-shaped)
├── summary.md # human-friendly per-file walkthrough
├── decision.json # { decision: 'accept' | 'reject' | 'partial', accepted_files: [...], rejected_files: [...], reviewer: 'user' | 'agent' }
└── meta.json # { generatedAt, atomDigest, planRevision }The atom raises a choice GenUI surface with the three top-level
decisions (accept / reject / partial). On partial the user
flips per-file decisions through follow-up surfaces.
The atom completes when decision.json has a non-empty decision.
Acceptance writes handoffKind: 'patch' (or 'deployable-app'
when a successful build-test is on file) into the eventual
artifact manifest; rejection rolls back the patch via git restore
or the equivalent in the code-import-bound repo path.
decision.json that lacks accepted_files /
rejected_files on partial decisions.plan/steps.json's union of
files[] — the patch boundary is a contract.Implemented by the daemon runner in
apps/daemon/src/plugins/atoms/diff-review.ts, with GenUI decisions persisted
by apps/daemon/src/plugins/atoms/diff-review-genui-bridge.ts.
f2760fd
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.