Review a pull request or branch diff for bugs, security issues, and compliance with repository `AGENTS.md` instructions. It runs the review in a fresh subagent context using the project’s `REVIEW.md` policy, then reports findings in a defined format.
Code review the current PR (or branch diff against main) for bugs, security, and AGENTS.md compliance. MUST use when asked to review code.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Run the same review locally that the GitHub auto-review actions run on PRs (Claude / Codex / Pi). The review policy lives in REVIEW.md.
Why a subagent: the review MUST run in a fresh context — not inline in the current session. If the user has been iterating on the diff, the main session has absorbed their reasoning and rationalizations, so it anchors and misses things CI catches. A subagent starts cold, like CI does.
Determine the PR scope (cheap, do this in the main session):
main.gh pr view <n> or git rev-parse <branch>).Delegate the review to a fresh-context subagent with a self-contained prompt. The prompt MUST include:
The PR number or branch name to review.
The instruction to read REVIEW.md first for the policy, then AGENTS.md files in directories touched by the diff.
The exact output format (see below).
Whether --comment was requested (so the subagent emits inline-comment payloads if needed).
Any "Additional reviewer instructions" the user provided.
Claude Code: use the Agent tool with subagent_type: branch-diff-reviewer (read-only tools, purpose-built for this). If unavailable, fall back to general-purpose.
Codex / Pi: if the CLI exposes a fresh-session subagent mechanism, use it. Otherwise tell the user to run the skill in a fresh CLI session and stop — running inline in the current session defeats the purpose.
Receive the findings from the subagent and relay them to the user verbatim. Do not re-summarize, re-judge, or filter — the whole point of fresh context is to surface what the main session would dismiss.
Post comments if --comment was requested: use the gh commands below with the subagent's output as the body. The main session does the posting because the subagent is read-only.
Review <PR #N | branch X> against main per the policy in REVIEW.md.
Steps:
1. Read REVIEW.md (repo root) for the full policy: severity triage, public-surface
checklist, AGENTS.md compliance, test coverage assessment.
2. Read AGENTS.md (repo root) and any AGENTS.md in directories touched by the diff.
3. Get the diff: `gh pr diff <N>` (if PR) or `git diff main...<branch>`.
4. Get context: `gh pr view <N>` (if PR) or `git log main..<branch> --oneline`.
5. Read changed files only when the diff alone is insufficient to validate a finding.
6. Self-validate each finding: "is this definitely a real issue a senior engineer
would flag?" Discard if uncertain.
7. Output findings in the exact format below. Do not modify any files.
<paste output format from below>
<if --comment requested:>
Additionally emit a JSON array of inline comments suitable for the GitHub reviews
API, one per finding that maps to a specific line:
[{"path": "...", "line": N, "side": "RIGHT", "body": "[P1] ..."}, ...]
## Code review
<verdict line per REVIEW.md>
Found N issues:
1. [P0|P1|P2] <description>
<file_path:line_number>
2. [P0|P1|P2] <description>
<file_path:line_number>
End with a Test coverage section per the shared policy.
If no issues are found:
## Code review
Good to merge.
No issues found. Checked for bugs, security, and AGENTS.md compliance.
--comment)For a top-level PR comment:
gh pr review --comment --body "<summary from subagent>"
For inline comments on specific lines (using the JSON the subagent emitted):
gh api repos/{owner}/{repo}/pulls/{pr}/reviews \
-f body="<summary>" -f event="COMMENT" -f comments="<json from subagent>"
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Plan the code changes needed to add a TriggerCrud-based trigger to Windmill. The checklist covers backend, database, API, CLI, frontend, capture, and validation work so the new trigger can be managed across the product.
Improve Windmill’s AI chat by reviewing its tools, prompts, result shapes, and context usage. The guidance helps place shared instructions where chat and CLI can use them, reduce repeated token costs, and compare behavior before and after changes with A/B evaluations.
Create and run black-box benchmarks for Windmill AI generation modes such as flows, apps, scripts, CLI, and global requests. Each case exercises the production path, checks hard requirements, and uses an LLM judge to assess user-facing behavior before and after changes.
Use this reference to work with Windmill resources from the command line, including scripts, flows, datatables, and workspace settings. It also covers listing jobs, inspecting details and logs, retrieving results, and rerunning or restarting executions when investigating failures.
Use this skill to shape modules with small interfaces and substantial behavior behind them. It helps you decide where a seam belongs, reduce complexity exposed to callers, and make code easier to test and maintain.
Use this skill to review pending changes, select only the relevant files for staging, and create a focused Git commit. It formats the single-line message with a Conventional Commits type such as feat, fix, or docs, and checks the resulting status.