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 agentmods add skills/cloudposse/atmos/pull-requestnpx skills add cloudposse/atmos --skill pull-requestgit clone --depth 1 https://github.com/cloudposse/atmosWhat 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 | $0.00060 | $0.03246 |
| Opus 5 | $0.00030 | $0.01623 |
| Sonnet 5 | $0.00012 | $0.00649 |
| Haiku 4.5 | $0.00006 | $0.00325 |
Grade A, and why
pull-request 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 2d 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 — 222 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Pull Request Preparation (Atmos)
Use this skill every time you open or update a PR. It encodes three policies that the Atmos repo enforces via CI and that the team has been burned by repeatedly:
- Every PR needs exactly one semver label. Unlabeled PRs fail the
PR Semver LabelsCI check. minorandmajorPRs require a blog post AND a roadmap update. TheCheck for changelog and roadmap updatesworkflow gates merging on both.featured[]in the roadmap is curated. Never auto-promote a shipped milestone intofeatured[]— only the user decides.
If you violate any of these, CI fails and the PR can't merge. Follow this skill across both phases: complete the pre-push checklist before git push, then immediately work through the post-push / PR checklist (open the PR, apply the label, monitor CI).
The label decision tree
The Atmos repo has four mutually exclusive release labels (plus other category labels that don't affect release docs):
| Label | When | CI requires blog + roadmap? |
|---|---|---|
no-release |
Internal refactor, new internal helper, dependency bump with zero user-visible behavior, docs fixes | No |
patch |
Bug fix, performance fix, error-message improvement, small UX polish — user-visible but not a feature | No |
minor |
New user-visible feature, new flag, new command, new config option, default flip that users see | YES |
major |
Breaking change: removed/renamed flag, schema migration, CLI behavior reversal | YES |
How to choose
Ask, in order:
- Would a user upgrading Atmos see ANY visible change? Behavior, output, errors, performance, new flags, new commands, removed flags, changed defaults? If no, use
no-release. This is the most common case for foundation/plumbing PRs. - Is this a breaking change? Removed flags, renamed flags, changed semantics, schema bumps that require user action? Use
major. Document the migration in the blog post. - Is this net-new functionality? New command, new flag, new config option that users will adopt? Use
minor. Write a blog post. - Anything else user-visible (bug fix, UX polish, error-message rewrite, output formatting): use
patch. No blog post required.
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.
- 2d ago First seen · 222 lines · 60 tokens per session scan A 8f2e3ced5133
pull-request is a skill published in the GitHub repository cloudposse/atmos (1,365 stars, last pushed today), licensed Apache-2.0. It adds 60 tokens to every session and 3,246 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
x-cmd-advise
Skill "x-cmd-advise" from x-cmd/x-cmd, covering x-cmd advise writing guide, core principles, field quick reference, subcommands at root level and writing priority.
claw-admin
Claw system administration: service management, IM connections, logs, cron, and workspace diagnostics. Use when the user asks to manage claw services, connect/disconnect IM platforms, view logs, or perform system-wide operations.
x-nets
Enhanced netstat module with cached data and structured output. View network connections, routing tables, and interface statistics in interactive or TSV/CSV formats. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-arp
Display ARP cache table with MAC vendor lookup and suspicious entry detection. Supports CSV, TSV, and TUI output. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-mankier
Search and browse man pages from ManKier.com. Command line interface for ManKier man page repository. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-osv
CLI for Google OSV database. Query vulnerabilities for packages, scan local projects for vulnerable dependencies. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill). Required Tool: Install osv-scanner for project scanning (see https://github.com/google/osv-scanner).