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 | $0.00041 | $0.01528 |
| Sonnet 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 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 — 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.
- 10d ago First seen · 307 lines · 81 tokens per session scan A 004d6caa21f0
carpeos-pr is a skill published in the GitHub repository innocarpe/CarpeOS (0 stars, last pushed 26d ago), licensed Apache-2.0. It adds 81 tokens to every session and 3,055 once invoked, about $0.0004 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-31.
Other skills, from other repositories
issue-match
Measure a target repository's queue and find a live open issue the contribution would close, before opening a pull request there. Reports how many PRs are open, how many of the last N closed ones were actually merged, and which issue to attach to, because a cold PR into a dead queue is a wasted artifact. Triggers…
sync-brain-starter
Sync reusable skills, configs, and templates from the private brain repo to the public brain-starter template repo. Use when you've updated a skill or config and want to push it to the open-source template.
retro
Close a work session properly: reconcile it against the wider collaboration, inventory what was actually built from git log and recently-touched files, summarize the arc, classify each artifact as keep, one-off or promote-to-permanent, route the durable ones to memory, canon or a new skill, save the retro as a vault…
release-slice
Open-source one slice of a private system: take a component, sanitize it, run a leak-scan as a hard gate, publish to GitHub, then changelog, roadmap and tag on cadence, then the content wave. Publishing without passing the leak-scan is forbidden. Triggers: "/release-slice ", "ship the next slice".
clone-projects
Clone or sync the project repositories you work on into a local workspace laid out by the same domains as the vault, so notes and code sit side by side. Use when setting up a machine, onboarding a new project, or refreshing all clones.
wiki-build
A tool for building or rebuilding a local wiki from all source files in a vault, which is a folder used to store source material. It creates structured pages, layered indexes, logs, and cross-links.