From beislid
Reviews external pull requests by fetching metadata and diffs via gh/glab, running review contracts, selecting findings, drafting comments, and posting after approval.
npx claudepluginhub sandsower/beislidThis skill uses the workspace's default tool permissions.
Review someone else's pull request and optionally post approved review comments. This is an inbound review workflow built around the side-effect-free `review` contract.
Reviews GitHub pull requests end-to-end using gh CLI: analyzes diffs, commits, CI/CD checks; provides blocking/suggestion/nit/praise feedback and submits review. Use for assigned PRs, self-reviews, or post-merge audits.
Reviews GitHub pull requests using gh CLI, analyzing diffs for code quality, security, testing, best practices, and providing structured feedback.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Review someone else's pull request and optionally post approved review comments. This is an inbound review workflow built around the side-effect-free review contract.
Boundary:
review inspects a diff and returns findings.pr-patrol fetches PR context, decides with the user which findings are worth posting, drafts comments, and performs posting side effects only after approval.Use this for:
Do not use this for:
review, fresh-eyes, or ship-itheard-chefwalk-the-diffBefore touching external systems, establish capabilities and print them to the user.
Resolve:
gh, glab, MCP tool, API client, or paste-only)Example capability table:
pr-patrol preflight
pr: <url>
host: github / gitlab / other / paste
fetch_diff: gh / glab / mcp / paste ✓
inline_comments: yes/no ✓
post_comments: yes/no ✓
If required tooling is missing, offer:
(a) load/fix tooling and retry
(b) continue in draft-only mode
(c) abort
Do not post anything unless posting is explicitly available and the user approves the final drafts.
Complete these phases in order:
Accept a PR URL or host-specific identifier. Prefer host tooling when available.
For GitHub with gh available:
gh pr view <url-or-number> --json title,body,author,baseRefName,headRefName,url,files
mkdir -p "${TMPDIR:-/tmp}/beislid-pr-patrol"
gh pr diff <url-or-number> > "${TMPDIR:-/tmp}/beislid-pr-patrol/pr.diff"
For other hosts, use the configured MCP/tooling or ask the user to paste:
If the PR is too large for one review pass, split by logical area and say how findings will be grouped. Do not silently ignore files.
Use, in order:
If requirements are unavailable, say so in the review metadata.
Invoke the review contract with:
For large PRs, run one overall pass plus scoped passes by subsystem when possible.
For security-sensitive PRs — auth, permissions, token handling, crypto, secrets, privacy, or data export — offer multi-reviewer mode if the host can call additional independent reviewers. All reviewers must return the same review contract and must not post comments.
Optional: run fresh-eyes after the normal review for whole-diff drift, especially on large PRs.
Show findings grouped by severity. Recommend posting:
Ask the user which findings to post:
Which findings should I post?
(a) all Critical + Important
(b) only selected IDs: <IDs>
(c) draft comments only; do not post
(d) none; summarize locally
Do not post style-only nits unless the user explicitly selects them.
Convert selected findings into concise PR comments. Each comment should include:
Tone:
When inline comments are supported, map each finding to a file/path/line. If line mapping is unavailable, use a general PR review comment with file references.
Use temporary files for comment bodies. Do not inline large comment text in shell commands. This avoids shell quoting bugs and credential-guard false positives.
Example pattern:
comment_file="$(mktemp "${TMPDIR:-/tmp}/beislid-pr-comment.XXXXXX.md")"
$EDITOR "$comment_file" # or write the approved body through the host agent's file tool
# Pass the file as a body field if the host tool supports file-backed fields.
# Otherwise build a JSON payload file and pass that file to the API client.
rm -f "$comment_file"
If the host/API requires a JSON payload, write JSON to a temp file and pass the payload file path to the tool instead of embedding the body in the command string. Do not pass a raw Markdown body file to an API option that expects JSON.
Present all drafts before posting:
### Comment Drafts
#### P1 -> <path:line or general>
<body>
...
Ask for explicit approval:
Post these comments? yes/no/edit
For GitHub, prefer host-supported review APIs. If the exact inline position cannot be resolved safely, fall back to a general PR review comment rather than guessing an inline location.
End with:
### PR Patrol Summary
- PR: <url>
- Requirements: <source or not available>
- Reviewers used: local / external names if any
- Findings found: Critical N, Important N, Minor N
- Comments posted: N
- Draft-only comments: N
- Not posted: <IDs and reason>
- Suggested review verdict: approve / comment / request changes
review is side-effect-free. pr-patrol owns posting.gh examples only as examples.