Rabbit round
Local-first security scanner and policy gate for Agent Skills
npx -y skills add stella/skillguard --skill rabbit-roundAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
SKILL.md
2.4 KB, as published. Nobody here has run it
Rabbit Round
Process automated PR review comments systematically. Use this for CodeRabbit, Gemini, GitHub Copilot, Devin, Greptile, and similar bots.
Instructions
-
Get context:
PR_NUMBER=$(gh pr view --json number -q '.number') gh api user --jq '.login' git rev-parse HEAD -
Fetch review comments from the PR:
gh api repos/{owner}/{repo}/pulls/"$PR_NUMBER"/comments --paginateFilter for known bot accounts. Do not treat human review comments as bot comments.
-
Triage each bot comment:
- Accept if it improves correctness, safety, maintainability, or follows repo conventions.
- Push back if it is incorrect, overreaching, or conflicts with documented conventions.
-
Implement accepted suggestions:
- make the code changes
- group related fixes logically
- run the relevant project checks
-
Reply inline to each bot comment:
COMMENT_ID="123456789" gh api -X POST repos/{owner}/{repo}/pulls/"$PR_NUMBER"/comments/"$COMMENT_ID"/replies \ -f body="[response]"Good response patterns:
- accepted and implemented
- agreed, implemented with a small adjustment
- already addressed in commit
{hash} - pushing back, with a concrete reason and source or repo convention
-
Never resolve human review threads. For bot threads, resolve only after:
- the change is implemented, or
- the pushback is clearly documented
-
Check nit-level comments too. Small ones still matter if they improve clarity or remove avoidable friction.
-
Commit and push if you made changes:
- use a neutral commit message such as
fix: address review comments - push to the active PR branch
- use a neutral commit message such as
Decision Guidelines
Accept when the suggestion:
- fixes a bug or real edge case
- improves type safety
- adds missing tests
- aligns with existing repo patterns
- tightens security or validation appropriately
Push back when the suggestion:
- assumes facts not true in this codebase
- conflicts with canonical specs or official sources
- adds complexity for little benefit
- would undo a deliberate, documented decision
- is purely stylistic and inconsistent with the repo