メニュー
How to process code review feedback — verify before implementing, push back when wrong, clarify before acting on partial understanding. Applied when receiving review from the agent-code-reviewer or human reviewers.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | do-pullrequest-review |
| description | How to process code review feedback — verify before implementing, push back when wrong, clarify before acting on partial understanding. Applied when receiving review from the agent-code-reviewer or human reviewers. |
| user-invocable | false |
| disable-model-invocation | false |
Code review feedback requires technical evaluation, not automatic agreement. Verify before implementing. Push back when the feedback is wrong.
Run this first. If it exits non-zero, halt and report the stderr output to the user verbatim. Do not proceed.
uv run maverick preflight do-pullrequest-review
Skip the preflight when invoked from inside a do-issue-* or
do-epic phase — the orchestrator already ran a stricter one this
session. Run it only when this skill is invoked standalone.
The check verifies the project is initialised and gh/uv are on PATH.
digraph receive_review {
"Receive feedback" [shape=box];
"Read all items completely" [shape=box];
"All items understood?" [shape=diamond];
"Ask for clarification on unclear items" [shape=box];
"Verify each item against codebase" [shape=box];
"Item technically correct?" [shape=diamond];
"Implement fix" [shape=box];
"Push back with reasoning" [shape=box];
"Run verification after each fix" [shape=box];
"More items?" [shape=diamond];
"Run full verification suite" [shape=box];
"Receive feedback" -> "Read all items completely";
"Read all items completely" -> "All items understood?";
"All items understood?" -> "Verify each item against codebase" [label="yes"];
"All items understood?" -> "Ask for clarification on unclear items" [label="no"];
"Ask for clarification on unclear items" -> "Verify each item against codebase";
"Verify each item against codebase" -> "Item technically correct?";
"Item technically correct?" -> "Implement fix" [label="yes"];
"Item technically correct?" -> "Push back with reasoning" [label="no"];
"Implement fix" -> "Run verification after each fix";
"Run verification after each fix" -> "More items?";
"Push back with reasoning" -> "More items?";
"More items?" -> "Verify each item against codebase" [label="yes"];
"More items?" -> "Run full verification suite" [label="no"];
}
Read the complete review before acting on any single item. Items may be related — implementing one in isolation could conflict with another.
If any item is unclear, ask for clarification on ALL unclear items before implementing ANY items.
Understand items 1, 2, 3, 6. Need clarification on items 4 and 5 before proceeding.
Do not implement the items you understand while waiting for clarification — partial understanding leads to partial (wrong) fixes.
Before implementing each suggestion, verify it is technically correct for this codebase:
Push back with technical reasoning when a suggestion is:
How to push back:
Item 3: Reviewer suggests extracting a utility class.
Checked the codebase — this logic is used in one place only.
Extracting creates indirection without reuse benefit.
Keeping inline per YAGNI.
Do not push back defensively. State the technical facts.
Process items in priority order:
After each fix, run verification (per the mav-local-verification skill). Do not batch multiple fixes without verifying between them.
The agent-code-reviewer agent provides structured two-stage feedback (spec compliance + code quality). Process it as follows:
Human reviewers may have context the agent does not. However:
gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies \
-f body="Fixed — extracted validation to boundary layer."
CI failures are not suggestions — they are facts. Fix them. Use the mav-local-verification and mav-bp-cicd skills to diagnose and resolve.
| Anti-pattern | Why it fails | Instead |
|---|---|---|
| Implement everything without checking | Incorrect suggestions break code | Verify each item first |
| Implement some items, ask about others | Partial understanding leads to wrong fixes | Clarify all unclear items first |
| Ignore review feedback | Issues accumulate and compound | Process every item |
| Add extra improvements while fixing | Scope creep, muddies the review cycle | Fix only what was flagged |
| Batch all fixes, verify once at the end | Cannot isolate which fix broke something | Verify after each fix |
When receiving review during a do-issue workflow:
Scan a project for missing best-practice areas and implement the top recommendation for each gap (linting, unit testing) — installs tools, writes configs, verifies, and commits. Pass 'recommend' to stop after writing recommendations without implementing (replaces the old do-recommend skill).
Implement a focused code change. Use this skill as the wrapper for any implementation work so the Maverick workflow report captures what was done and so the agent applies the project's coding standards before editing. Intended to be invoked once per task from inside a do-issue-* or do-epic phase, not standalone.
Audit a codebase for security risks in one of two modes. In full-audit mode it scans the entire codebase and writes a findings report to docs/security-audit.md (run as part of do-init or on demand). In update mode it reviews only a diff plus the code it could impact, returning a structured findings list as a pre-push gate for do-issue-solo and do-issue-guided. Covers secrets exposure, dependency vulnerabilities, authentication and authorisation patterns, input validation, transport security, and common OWASP risks.
Create, restructure, or update technical documentation. Handles greenfield projects, refactoring non-compliant docs, and incremental updates after code changes.
Work on a multi-story GitHub epic end-to-end. Builds a DAG from the child stories, groups them into waves, runs waves in parallel via per-story worktrees, ejects PRs that fail agent-code-review for human handling, and propagates blocks to downstream stories. Requires git worktrees.
Initialise a project for use with Maverick — verifies the GitHub App, installs the CLI if needed, writes the project config with integration tracking, scaffolds docs, generates project skills, runs an initial cybersecurity audit, then commits the changes and opens a PR.