Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/innocarpe/CarpeOSnpx agentmods add skills/innocarpe/carpeos/carpeos-prWrote 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/innocarpe/carpeos/carpeos-pr)<a href="https://agentmods.dev/skills/innocarpe/carpeos/carpeos-pr"><img src="https://agentmods.dev/badge/skills/innocarpe/carpeos/carpeos-pr/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/innocarpe/carpeos/carpeos-pr"><img src="https://agentmods.dev/badge/skills/innocarpe/carpeos/carpeos-pr.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.00081 | $0.03055 |
| Opus 5.5 | $0.00032 | $0.01222 |
| Sonnet 5.5 | $0.00016 | $0.00611 |
| Haiku 4.5 | $0.00008 | $0.00305 |
Grade A, and why
carpeos-pr 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 1mo 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 — 307 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CarpeOS Pull Request (shared harness skill)
Same standard for Claude Code, Codex CLI, Grok Build, and Gajae Code/GJC.
Minimal three-bullet PR bodies are not acceptable. Every PR must follow the
repository template and fill every section with real content (or an explicit
Not applicable / None / Not run where required).
Source of truth
| Artifact | Path |
|---|---|
| Template | .github/PULL_REQUEST_TEMPLATE.md |
| Labels | .github/labels.json + docs/maintainers/github-labels.md |
| Agent rules | AGENTS.md (Pull Request section) |
| Contributing | CONTRIBUTING.md |
When to use
Trigger on: open PR, create PR, gh pr create, edit PR body, gh pr edit,
update PR description, ship branch, stack PR, draft PR for review.
Hard rules
- Fill the full template — all sections below. Do not stop at Summary/Why/Test plan.
- No empty sections — if a section does not apply, write
NoneorNot applicablewith a one-line reason. - Validation must be honest — only list commands you actually ran; put results in the table.
- Public boundary — no credentials, private paths, real project names, production logs, or runtime dumps. Use synthetic identifiers in examples.
- Labels are mandatory (hard gate) — every PR must have exactly one kind label
(
feat|fix|docs|spec|chore) and zero or one area label (capture|sync|retrieval|interfaces|infra). Prefer--labelongh pr create. If labels were omitted, apply immediately withgh pr edit <N> --add-label …. A PR without a kind label is incomplete. - Commits MUST be atomic — each commit contains one independently understandable change, uses an English Conventional Commit subject, and does not mix unrelated files or concerns.
- PRs are semantic review units, not commit containers — a PR SHOULD include the complete set of tightly coupled atomic commits needed for one user-visible, architectural, or milestone-level change. Never create one PR per commit merely to make commit history look tidy unless the user explicitly requests commit-level PRs.
- Preserve atomic history — do not squash, reorder, or force-push atomic commits to manufacture a PR boundary. When a semantic change spans commits, use a stacked PR or a branch range whose diff is exactly that semantic unit.
- Before creating a PR, inspect
git log <base>..<head>andgit diff <base>...<head> --stat; confirm the PR has one semantic purpose, its base is intentional, and no unrelated commit/file has leaked in. - Local preflight is mandatory (hard gate) — before
gh pr create/ push for review, run the local PR-lean gate and keep it green:- preferred:
make preflightorpnpm preflight/pnpm preflight:pr - auto-format then gate:
make preflight-fix - agent iteration only:
make preflight-quick(not enough alone for PR open) - preflight runs format/lint/public-boundary in parallel, then build, then
typecheck∥test, plus merge-tree conflict probe vs
origin/main - list the exact preflight command +
PREFLIGHT PASSin the Validation table - Do not open a PR on a red preflight. CI re-runs the same invariants; local green is required to stop wasting Actions minutes on format/boundary nits
- still document Linux-only gaps (bubblewrap Product 4 sandbox, Gitleaks) as
Not run — Linux GHA onlywhen applicable
- preferred:
- Title — English Conventional Commit subject matching the semantic PR change (and matching the kind label).
- Length — aim for a reviewable body: enough that a cold reviewer can understand problem, approach, risk, and how to verify without reading the whole diff. Prefer complete sentences over telegram bullets alone.
- Post-create verify — after create/edit, run the label gate below. Do not report the PR as done until it passes.
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.
- 1mo ago First seen · 307 lines · 81 tokens per session scan A 004d6caa21f0
carpeos-pr is a skill published in the GitHub repository innocarpe/CarpeOS (1 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 81 tokens to every session and 3,055 once invoked, about $0.0003 per session on Opus 5.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-31.
Other skills, from other repositories
enzyme-sqlite-source
Connect an unfamiliar SQLite database to Enzyme without changing the source data. Inspect the database, decide which query columns represent identity, people, time, content, and folders, show real examples for approval, save a workspace program in the Enzyme language, and verify init and refresh. Use for email…
enzyme-workspace-setup
Set up or check Enzyme in a Markdown workspace. Use for first setup, re-setup, diagnosis, or requested cleanup; existing Enzyme files do not prove setup is complete. Write settings from the user's own map of their notes, review them with the user, demonstrate an answer from real notes, and repair only an evidenced…
enzyme
Use Enzyme in an already activated Obsidian, Markdown, or Hermes workspace for working-memory retrieval, source-grounded exploration, search by keyword and meaning, runtime note-writing, and refresh. If the workspace is not initialized, follow the first-time setup section before normal retrieval.
pr-reply
Answer reviewers on your own pull requests in other people's repos: find threads where the ball is on your side, tell humans from bots, do exactly what was asked and reply with evidence. Use at the start of any GitHub session or on a new-review alert. Triggers: /pr-reply, /prr, answer the reviewers, who is waiting on…
contrib-watch
Watch incoming feedback from outside engineers on your open-source repos: comments, reviews, issues, mentions. Use when you need to find who replied to your pull requests or issues, triage human versus bot responses, and answer within a day with evidence.
github-growth
A working guide for promoting projects and starting useful conversations on GitHub. GitHub is a platform for hosting code, reviewing changes, and discussing software with its users and maintainers.