Morning signal review: an AI code review checklist

A morning signal review is a short daily pass over what your coding agents did overnight, where the first reviewer checks receipts before anything merges. Run it against the same four gates every day and the first merge stops being the first incident. Skip it and the reviewer who logs in at nine inherits a pile of summaries that never say which files got touched.

This piece gives you that checklist and the four small files that make it fast. If your team runs Cursor, Anysphere's AI code editor, alongside other agents overnight, this is the pass that keeps green CI from meaning "trust me."

Why the morning reviewer pays the bill

Parallel agents feel like free speed. They are not. Someone reads the output, and that someone is usually the first person at their desk in the morning.

The trap is that the signals look healthy while accountability stays fuzzy. Dashboards are green, summaries are posted, and nobody can say which agent touched the billing folder or why. Green CI tells you the code runs. It does not tell you the change can be explained.

So the goal of the morning pass is one thing: check evidence, not vibes. Each gate below catches one common way that evidence goes missing.

Write the four files that make receipts cheap

Each failure mode gets one small file. None of them are long. Together they turn the morning pass into a series of lookups instead of a fresh investigation.

CLAUDE.md precedence clause. On shared machines, bash approvals turn into muscle memory and sessions start inventing policy mid-run. The top of CLAUDE.md states which hooks win, which folders need human eyes, and where temporary overrides live. The getting started docs cover the session half of this.

Replay sandwich. A merged green where no reviewer ever saw the transcript is a gap waiting to bite. Have AGENTS.md require an intent line, a command transcript, and a diff summary before any PR, layered onto the Codex quickstart flow. The reviewer reproduces the run from the PR instead of leaning over someone's shoulder.

Connector card. Connectors default to capability demos, and a connector that reaches data nobody listed is how blast radius grows quietly. Least privilege needs the explicit trust boundaries the MCP specification describes. Write one markdown card per server: allowed actions, forbidden actions, owner, rollback. Operators then know what "off" looks like.

Child receipt block. Chained agents play telephone: a parent returns a tidy summary that hides the paths a child actually changed. Make every child return the paths it touched, the commands it ran, and the tests that prove its regression guards. Parents stop green-lighting diffs they cannot see.

Here is a starting delegation snapshot you can drop in and adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

Our methodology is the forcing function here: a test proves the behavior, a review proves the team can explain it. The standing practice for all of this lives under AI coding governance.

Run the four gates every morning

The checklist is the same four questions, asked in the same order, against the PR alone. If you cannot answer one from the PR body, that is the signal a receipt is missing.

Then a few quick checks before you call it done:

• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent + child responsibilities.
• Red-folder paths received explicit human acknowledgement.

Some decisions stay off autopilot no matter how clean the receipts look: threat models, customer promises, and anything that moves blast radius. Those belong to a person, every time.

Common questions

• What should an AI code review checklist cover for agent output?

  Four gates. Risk routing asks which red folders were touched and who approved. Replay proof asks which commands prove regression guards. Receipt match asks whether scopes and a verification transcript sit in the PR body. Rules precedence asks which .mdc, SKILL.md, or CLAUDE.md governed behavior. Every one is answerable from the PR alone.

• How long should a morning signal review take?

  A few minutes, if the receipts are in place. It is a short pass, not a second full review. When the four files are doing their job, each item is a lookup: connector owners listed, verification output pasted, parent and child responsibilities named. The moment you have to replay a session by hand, you have found a missing receipt.

• Who approves changes that touch red-folder paths?

  A human, explicitly. Hard constraints like threat models, customer promises, and blast radius decisions belong to people, not to a green build. The checklist's whole job at that point is making the moment visible: a red-folder path gets an explicit acknowledgement instead of riding through unseen.

• Where do I put these four files?

  In the repo, at the root, next to the code they govern. CLAUDE.md, AGENTS.md, your connector cards, and the delegation snapshot all live in version control so they get reviewed like anything else. Keeping them in the repo is also what lets the morning reviewer cite a real line of precedence instead of guessing what the rules were.

Start with the table

Paste the four-gate table into your PR template today, so receipts show up before the reviewer has to ask. If your mornings still start with mystery diffs after that, book a 15-minute sync and we will fit the checklist to your repos.

Further reading

• Cursor agent docs
• Google Search Central on helpful, people-first content
• Google Search Central on generative AI content
• OpenAI Skills repository