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/outlinedriven/outline-driven-development/atomic-issues-prsnpx skills add OutlineDriven/outline-driven-development --skill atomic-issues-prsgit clone --depth 1 https://github.com/OutlineDriven/outline-driven-developmentWrote 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/outlinedriven/outline-driven-development/atomic-issues-prs)<a href="https://agentmods.dev/skills/outlinedriven/outline-driven-development/atomic-issues-prs"><img src="https://agentmods.dev/badge/skills/outlinedriven/outline-driven-development/atomic-issues-prs.svg" alt="Measured on agentmods" 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.00040 | $0.01595 |
| Opus 5 | $0.00020 | $0.00797 |
| Sonnet 5 | $0.00008 | $0.00319 |
| Haiku 4.5 | $0.00004 | $0.00160 |
Grade A, and why
atomic-issues-prs 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 yesterday.
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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Atomic issues and PRs
Contract
| Field | Bound contract |
|---|---|
| Trigger | User says "atomic PRs" or requests one issue/PR per logical change. |
| Authority | Human-only. Requires explicit human invocation. Preview the target repo and consequence before creating branches, commits, issues, and pull requests on a remote repository. |
| Side effect | Creates branches, commits, issues, and pull requests on a remote GitHub repository. Never force-pushes or pushes to protected branches without explicit user authorization. |
| Done | One issue or PR per logical change on the correct base/head, links appended, URLs reported. |
Inputs
Required: a working tree containing the change-set to publish and a gh-authenticated GitHub account.
Optional: per-unit routing overrides (issue+PR vs PR-only) stated by the user; dependency order among units.
Procedure
- Run
gh auth status. If unauthenticated, stop and ask the user to rungh auth login. - Resolve the canonical (upstream) slug before any permission check. Read remotes with
git remote -v; pick the contribution target asupstreamif present, elseorigin. Detect a fork relationship withgh repo view <slug> --json nameWithOwner,parent,defaultBranchRef; a non-nullparentmeans the canonical slug isparent.nameWithOwner. If there is no clear single upstream (noupstreamremote and ≥2 plausible non-origin candidates, orgh's detectedparentdisagrees with theupstreamremote) ororiginhas genuinely diverged from upstream (no common merge-base, ororiginwas re-created/renamed/renewed), prompt the user for the target repo. Plain fork-behind, whereoriginis merely behindupstreamwith a shared merge-base, is not ambiguity and must never prompt. - Query permission on the canonical slug:
gh repo view <canonical-slug> --json viewerPermission.viewerPermission∈ {ADMIN, MAINTAIN, WRITE} ⇒ direct mode; otherwise ⇒ fork mode. Record the canonical default base branch fromdefaultBranchRef. - Group working-tree changes into atomic units by mechanism/file boundary: one concern per unit. Never bundle unrelated changes. Commit the whole set into N atomic commits first, running the repo-native type-checker and linter before each commit. Each unit becomes one self-contained commit, which allows per-unit branches to be created by cherry-picking. Never re-stage a dirty tree, which would let later units swallow earlier diffs. Present the unit→commit list to the user, then proceed.
- Route each unit by whether it changes observable behavior: behavior-affecting → Issue + linked PR, because a tracking issue gives the change a changelog/discussion anchor; mechanical → PR-only, because a self-explanatory change needs no separate tracking. Honor an explicit per-unit override if the user states one; otherwise route silently.
- Resolve the push URL once, by URL not remote name, to avoid undefined targets and remote-name collisions. Direct mode: push URL =
https://github.com/<canonical-slug>. Fork mode: fork owner =gh api user --jq .login; fork slug =<login>/<repo>. Iforiginalready points to a prior personal fork whose owner ≠ canonical owner and ≠ the authenticated login, print a non-blocking warning noting the account mismatch; do not stop the run. If the fork does not exist, create it withgh repo fork <canonical-slug> --clone=falseand note the fork slug in the output. Push URL =https://github.com/<fork-slug>. - For each unit, in dependency order:
- Create the branch and cherry-pick the unit commit. Independent unit:
git branch <branch> <canonical-default-base>thengit cherry-pick <unit-commit>; PR bases on<default>. Dependent unit in direct mode: parent-ref = the prerequisite unit's already-pushed branch; PR bases on that branch (a stacked PR); cherry-pick only this unit's commit so no prerequisite is lost. Dependent unit in fork mode: cross-fork stacking cannot be expressed (a fork PR's base must be a branch in the canonical repo), so flatten onto<canonical-default-base>and prefix the PR body with a warning line naming the prerequisite unit and noting the dependency was flattened; the compromise is never silent. git push <push-url> <branch>:refs/heads/<branch>(same form both modes; only the URL differs).gh pr create --repo <canonical-slug> --body-file <tmp>. Direct mode:--base <parent-ref> --head <branch>; fork mode:--base <default> --head <fork-owner>:<branch>; capture PR#M.- If the unit routed to Issue + linked PR:
gh issue create --repo <canonical-slug> --title "<summary>" --body-file <tmp>with a body that references PR#M; capture#N. - Amend the PR body by appending
Closes #Nto the PR's existing body. Reuse the body-file from step 3 (append the line and rewrite the file) or fetch the current body first withgh pr view <M> --json body; then write it withgh pr edit <M> --repo <canonical-slug> --body-file <amended-tmp>.gh pr edit --body-filereplaces the whole body, so never write a bareCloses #Nas the entirety of it. - Emit the issue/PR URLs; move to the next unit.
- Create the branch and cherry-pick the unit commit. Independent unit:
- For PR-only routed units (no issue filed in step 4), skip the issue-create and body-amend steps entirely; no dangling
Closes. Done when: every logical unit has the correct issue/PR routing, base and head, links, and reported URLs.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 50 lines · 40 tokens per session scan A 8ae3f75b1172
atomic-issues-prs is a skill published in the GitHub repository OutlineDriven/outline-driven-development (52 stars, last pushed yesterday), licensed Apache-2.0. It adds 40 tokens to every session and 1,595 once invoked, about $0.0002 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-09-03.
Other skills, from other repositories
commit-push-pr
Use when asked to ship/open a PR, or for PR-description-only flows like writing, rewriting, or describing a PR body.
commit
Use when a user asks to commit or save staged or unstaged changes, create a typed branch, or format history for changelog generation. Each logical concern is committed with a conventional-commits message carrying SemVer effect and issue-closing footers. Not for rewriting existing commit messages; use commit-economy.
git-branchless
Use when asked for multi-commit stack edits, rebases, fixups, or stacked-PR publishing with branchless git idioms and a publish gate. Not for plain-git workflows in repos without branchless; the skill stays inert there. Human-only.
commit-push-current
Commit working-tree changes and push to the current branch: no branch creation, no branch switch, no PR. Use when asked to push to the branch you are already on, including the default branch.
commit-push
Use when asked to ship/publish commits without opening a PR.
setup-pre-commit
Use when installing or repairing one repository-local pre-commit hook using the project's current gates, or when a repo needs package-manager-native commit-time checks. Extends existing hook tooling instead of duplicating it; JS uses Lefthook and Biome, Python/Rust/OCaml use prek. Not for remote or irreversible…