Borrowing it
Nothing to install: this file belongs to phase-rs/phase. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/phase-rs/phase/main/.claude/skills/pr-contribution-handler/SKILL.mdgit clone --depth 1 https://github.com/phase-rs/phaseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/phase-rs/phase/pr-contribution-handler)<a href="https://agentmods.dev/skills/phase-rs/phase/pr-contribution-handler"><img src="https://agentmods.dev/badge/skills/phase-rs/phase/pr-contribution-handler/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/phase-rs/phase/pr-contribution-handler"><img src="https://agentmods.dev/badge/skills/phase-rs/phase/pr-contribution-handler.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 4 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high YARA Match · line 21 YARA rule matched a hack tool or exploit indicator (offensive tools, reconnaissance, privilege escalation, or exploit frameworks).Fix: Remove offensive tool references and exploit code. Legitimate agent skills should not contain penetration testing tools, exploit frameworks, or reconnaissance utilities.
- high Tool Misuse · line 491 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- high Agent Snooping · line 544 Skill reads from agent configuration directories (.claude/, .codex/, .gemini/). These directories may contain API keys, personal settings, and other credentials that the skill has no legitimate need to access.Fix: Remove all code or instructions that access agent configuration directories (.claude/, .codex/, .gemini/). If configuration values are needed, pass them explicitly as parameters or environment variabl
- medium Agent Snooping · line 63 Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.Fix: Remove all code or instructions that list or read other skills' files or directories. Skills should operate independently; cross-skill access is a privilege escalation.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00080 | $0.15717 |
| Opus 5.5 | $0.00032 | $0.06287 |
| Sonnet 5.5 | $0.00016 | $0.03143 |
| Haiku 4.5 | $0.00008 | $0.01572 |
Grade B, and why
pr-contribution-handler scanned grade B with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
- [ ] **No workflow or instruction edits in the final diff.** Re-grep the post-fix diff for any path under `.github/workflows/`, `.github/actions/`, `.claude/`, `CLAUDE.md`, `AGENTS.md`, `docs/AI-CONTRIBUTOR.md`, or this Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
Do not approve, enqueue, or leave auto-merge enabled for a PR with a proof gap. Request concrete proof first: template-complete verification, discriminating runtime tests or equivalent boundary tests, exact commands/chec How it starts
The opening of the file, as written. The whole thing — 593 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Contribution Handler
Use this skill when the user provides a GitHub PR number, URL, branch, or list of PRs and asks to handle contributor work end-to-end.
The goal is not just "make CI green." The goal is to leave the PR in the most idiomatic, maintainable, rules-correct shape reasonable for its scope.
Maintainer Quality Bar — READ FIRST (non-negotiable, overrides "just merge it")
This skill lands contributor work, but only after it meets the maintainer's bar — and the bar is "is this PR the best it can be, behaviorally AND architecturally?" not "does CI pass?" The maintainer must be able to be confident in the review itself before anything merges. Apply every rule below to every PR.
-
You may — and should — improve the author's PR. "We can make changes to the author PR; we just need to ensure it's the best it can be." When a PR is correct but not idiomatic/clean/complete, fix it on the contributor's branch (push when
maintainerCanModify=true; verify the fork remote points at the right contributor before pushing) rather than merging as-is or leaving a nit. Bring it to the shape a principal engineer would merge. If review finds only a couple small, local, low-risk changes between the PR and mergeability, do those fixups yourself instead of making the contributor chase another review round. -
CI/Tilt green is necessary, NOT sufficient. Green CI proves it compiles and existing tests pass. It does not prove correctness, no-regression, or performance. Never present "CI green" as evidence a PR is ready. For every PR you must additionally:
- Trace the changed logic by hand, end to end, for the target case AND 2–3 sibling cases in the class AND the obvious edge cases (multiplayer, zero/empty, interaction with existing effects). Confirm it actually produces the rules-correct result — not merely that it "conforms to CLAUDE.md."
- Verify the tests DISCRIMINATE. For every assertion, ask: would this fail if the fix were reverted? An assertion that passes both before and after the fix is coverage theater. A bug-fix PR must have at least one runtime test that drives the engine through the real pipeline (
apply()/ scenario runner) and would fail without the change. Name any behavior with no discriminating test as a gap, and add the missing test before enqueue. - Read the parse-diff sticky comment (engine/parser-surface PRs). CI posts a sticky comment (marker
<!-- coverage-parse-diff -->) with the card-level parse changes this PR introduces — it exists for the reviewing LLM and is required evidence, not optional context. Fetch its full body and confront the card diff against the PR's claimed scope: unexplained gained/lost/changed cards are findings (scope contamination or unintended parser blast radius). Thepr_review.pypacket'sparse_difffield carries presence/state/updated_at; compareupdated_atagainst the head's push time to confirm the diff reflects the current head. If the comment is absent but engine source changed, treat it as missing evidence and check whether CI ran for the current head before reviewing.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago Changed · +2 lines 44d1e5bac706
- 1mo ago Changed d9f0ed1022eb
- 2mo ago First seen · 591 lines · 80 tokens per session scan B 52777a536605
pr-contribution-handler is a skill published in the GitHub repository phase-rs/phase (312 stars, last pushed today), licensed Apache-2.0. It adds 80 tokens to every session and 15,717 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it B with 2 findings (reads agent configuration directories, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
critic-contract
Shared read-side contract every read-only CRITIC imports — adversarial stance, empirical verification of runtime-behavior claims, the mandatory self-red-team before APPROVE, how a finding is stated (quote the span, take the UNKNOWN escape hatch) and held (only new evidence moves a severity, never pushback), spec-UB…
code-quality
Shared clean-code / DRY / KISS / YAGNI standards and stack-specific smells for the React 19 + TypeScript + Rust (Tauri 2) monorepo. Library consumed by the code-quality-reviewer and code-quality-author agents.
deployment-rules
Release/deployment standards — semantic-release, commitlint, version sync, the updater. Load for /prepare-release and changes to release.config.mjs / commitlint / workflows / version files. Owned by project-steward.
review-workflow
The implement→review flow under the ≤3-reviewer budget with the conditional test stage. Use for /implement-feature, /fix-bug, /refactor-module and any change that needs structured review.
coding-standards
General repo rules enforced by ESLint/TypeScript/CI — PRs-only, never bypass lint, import ordering, type imports, path privacy, commit format. Load for any code change.
compiler-commit
Use when you want to verify compiler changes and commit with the correct convention. Runs tests, lint, and format, then commits with the [compiler] or [rust-compiler] prefix.