Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add costajohnt/oss-autopilot --skill pr-etiquettegit clone --depth 1 https://github.com/costajohnt/oss-autopilotWrote 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/costajohnt/oss-autopilot/pr-etiquette)<a href="https://agentmods.dev/skills/costajohnt/oss-autopilot/pr-etiquette"><img src="https://agentmods.dev/badge/skills/costajohnt/oss-autopilot/pr-etiquette/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/costajohnt/oss-autopilot/pr-etiquette"><img src="https://agentmods.dev/badge/skills/costajohnt/oss-autopilot/pr-etiquette.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
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 →
- medium Excessive Agency · line 75 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
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.00057 | $0.01916 |
| Opus 5 | $0.00028 | $0.00958 |
| Sonnet 5 | $0.00011 | $0.00383 |
| Haiku 4.5 | $0.00006 | $0.00192 |
Grade A, and why
PR Etiquette scanned grade A with 0 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 10d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 181 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Etiquette
How to communicate around a pull request — review responses, descriptions, follow-up cadence, and the readiness gate. Pair with the oss-contribution skill (universal rules) and contribution-ethics (attribution + AI-tell avoidance).
Responding to Code Review Feedback
Mindset
Maintainer feedback is a gift — they're investing time to help you improve. Even critical feedback should be received gracefully.
Response Approach
- Address every point they raise
- Keep it short. One or two sentences is usually enough.
- Push updates promptly after discussion
- Mark conversations as resolved after addressing
- If you feel resistance to a request, investigate deeper — the maintainer likely knows something you don't. If you still think there's an issue after investigating, raise it to the human contributor — never override the maintainer
Assumptions and Verification
When a maintainer requests changes, these rules govern how you respond:
-
Maintainer is right by default. If a maintainer says "do X," your starting assumption is that X is correct and appropriate for their codebase. Do not second-guess their judgment about their own project.
-
Verify, never assume. Before running any tool (linter, formatter, type checker), check the project's CI configuration to confirm that tool is actually enforced. Read
.pre-commit-config.yaml,.github/workflows/,Makefile, or equivalent before deciding what to run. A tool that exists indevDependenciesbut is not in CI is not authoritative. -
Try before estimating scope. When asked to make a change, attempt the simplest implementation first. Do not respond with effort estimates, propose TODOs, or suggest deferring to a follow-up PR. If the change turns out to be genuinely complex after attempting it, report what you found to the human.
-
Pushback = escalate, don't override. If you believe a maintainer's request is incorrect or harmful, raise the concern to the human contributor. Never push back on a maintainer directly, never ignore the request, and never silently do something different from what was asked.
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.
- 10d ago First seen · 181 lines · 57 tokens per session scan A 24a06332d878
PR Etiquette is a skill published in the GitHub repository costajohnt/oss-autopilot (14 stars, last pushed yesterday), licensed MIT. It adds 57 tokens to every session and 1,916 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
cn-check
Install and run the Continue CLI (cn) to execute AI agent checks on local code changes. Use when asked to "run checks", "lint with AI", "review my changes with cn", or set up Continue CI locally.
joycraft-design
Design discussion before decomposition — produce a 200-line design artifact for human review, catching wrong assumptions before they propagate into specs.
joycraft-spec-done
Lightweight per-spec wrap-up — bump status to in-review, terse discovery if surprised, commit. Run after each spec in checkpoint/isolated mode; no validation, no push, no PR.
knowledge
Instructions for contextual knowledge retrieval, tagging, search, and rating. Referenced by fixed planning, implementation, and review workflow bundles.
code-review
Review a code change for correctness, security, maintainability, tests, and scope alignment.
review-comments
Verify review feedback against current code and address valid findings without scope drift.