The requesting-code-review Skill — A Reviewer With No Conversation History
Datarim's requesting-code-review skill dispatches an isolated reviewer agent that sees only the diff and requirements — not the author's thought process. That isolation is the point.
An agent reviewing its own work carries all the assumptions that shaped the original implementation. The requesting-code-review skill solves this by dispatching a separate reviewer agent with precisely scoped context: the diff, the requirements, and nothing else from the authoring session.
The core principle in the skill is direct: review early, review often. The reviewer gets the git SHA range (BASE_SHA to HEAD_SHA), a brief description of what was built, and a pointer to the plan or requirements. It does not get the conversation history, the false starts, or the reasoning that led to the choices made.
When to request a review
Three moments are mandatory: after each task in subagent-driven development, after completing a major feature, and before merging to the main branch. The skill also lists optional triggers — when stuck, before a refactor as a baseline check, after fixing a complex bug. The mandatory list exists because compounding is the real risk in multi-task pipelines: an issue caught at task 2 costs one fix; the same issue discovered at task 7 costs a refactor across everything built on top of it.
How the reviewer is dispatched
The skill uses a template file at requesting-code-review/code-reviewer.md with four placeholders: a description, the plan or requirements reference, the base SHA, and the head SHA. Whatever the runtime provides for spawning an isolated agent receives that template as its full input — no conversation history attached.
Feedback comes back in three tiers. Critical issues are fixed immediately. Important issues are fixed before proceeding to the next task. Minor issues are noted for later. The skill is explicit on one point: push back if the reviewer is wrong, with technical reasoning. A reviewer that cannot be challenged is not useful.
Fallback when isolation is not possible
Not every runtime can spawn a truly isolated agent. The skill gives two fallback options. The second-best is a fresh session of the same operator with only the reviewer prompt and the git diff loaded — no prior conversation. The third-best is a self-review against the same checklist. Quality drops at each fallback, but the structure still catches a meaningful share of issues.
The anti-pattern it prevents
Skipping review because a change looks simple is the specific failure the skill names. The reviewer's job is not to second-guess obvious things — it is to catch the non-obvious ones. Simple-looking changes have a way of hiding exactly those.
Read what Datarim is for the broader agent architecture, or see the reflecting skill for how review findings feed into long-term framework improvement.