agents

126 notes in this subject, read out of this brain and free to use. This is page 3 of 3.

deep-code-review stacked PR review process

For stacked PRs, build a cumulative change map tracking which files and symbols are introduced or modified at each level. Each PR URL is in stack order (bottom to top—first URL is closest to main). Use parallel sub-agents to explore each PR's changed areas concurrently. Each PR's summary should note its position in the stack (e.g., 'PR 2/4 in stack') and reference other PRs in the stack where relevant.

deep-code-review iteration support

When --iteration N is specified, fetch new commits since last review using 'gh pr view <PR_URL> --json commits', check conversation for addressed comments using 'gh api repos/expo/expo/pulls/{pr}/comments', re-analyze only changed areas while acknowledging fixes and flagging new issues, then write a new JSON file and run post-pending as usual.

deep-code-review native ABI breaking changes

For prebuilt Swift/Kotlin packages (expo-modules-core, expo-modules-jsi), a change can be source-compatible but binary-incompatible: consumers prebuilt against the old artifact fail at link/load. Flag if removing/renaming a public/open symbol, moving a method into a protocol extension (remangles it), changing a signature/generics/@available, or altering a conformance that changes the .swiftinterface. This is only a risk if the symbol is already released on the PR's target branch (exempt if new there). A PR targeting an sdk-* release branch is the riskiest case. Preserve the old symbol with a forwarding shim if needed. Flag as critical inline comment and recommend the breaking: ABI label.

deep-code-review REJECT verdict use cases

Use REJECT verdict for AI-generated slop, spam, or PRs that are fundamentally unfit (wrong repo, completely unrelated changes). REJECT PRs skip the review entirely—no inline comments are posted. After showing the verdict table, offer to close the PR by running 'bun run .claude/skills/deep-code-review/post-review.ts close <output_dir>/code-review-{pr_number}.json', which comments the summary on the PR and closes it. Always confirm with the user before closing.

deep-code-review usage: local branch review

Run '/deep-code-review' without a PR URL to review the current branch locally against main and print findings directly in the conversation (no GitHub posting). This is useful for self-review before pushing.

deep-code-review review conciseness guideline

A review should be concise. A 4-line docs fix does not need a 4-paragraph review with numbered findings. For small or simple PRs, write one short summary paragraph with inline comments only where needed. Save deep analysis for PRs that warrant it: large diffs, architectural changes, or tricky logic.

Give your agent this brain