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 bostonaholic/team --skill pr-screenshotsgit clone --depth 1 https://github.com/bostonaholic/teamWrote 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/bostonaholic/team/pr-screenshots)<a href="https://agentmods.dev/skills/bostonaholic/team/pr-screenshots"><img src="https://agentmods.dev/badge/skills/bostonaholic/team/pr-screenshots/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/bostonaholic/team/pr-screenshots"><img src="https://agentmods.dev/badge/skills/bostonaholic/team/pr-screenshots.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.00051 | $0.01329 |
| Opus 5 | $0.00026 | $0.00665 |
| Sonnet 5 | $0.00010 | $0.00266 |
| Haiku 4.5 | $0.00005 | $0.00133 |
Grade A, and why
pr-screenshots 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
pr-screenshots — inline images in any PR body
Attach local image files to a pull request through GitHub's own attachment
pipeline, harvest the URLs it resolves, and write one ## Screenshots section
into that PR's body. Any PR qualifies — open, draft, closed, or merged, in any
repository, with or without a local checkout and with or without a pipeline run
behind it.
The upload mechanics live here and nowhere else. team-pr decides whether to
run, when, and which entries qualify, then calls this skill.
Every procedure with a loop, a branch, or a value a later step needs is a
committed script under scripts/, run with its arguments and read by its exit
code. A markdown fence carries no shebang, so the host shell picks the
dialect, and a fence boundary is an invocation boundary that no shell variable
survives. A script with #!/usr/bin/env bash pins both. Each reference below
names the script its stage runs; what stays inline is a single command whose
reader benefits from seeing it.
Hard rules
- Upload first, write second. Never fuse an attach flag with a body flag in one command. On a partial failure the host rewrites only the references that landed, which leaves a local filesystem path inside a body that may already be merged.
- One body write per PR, computed from the pre-image taken before the first
attach and produced by
scripts/splice.mjs. That single write also clears the tails the attach step appended. - Refuse before mutating, never after. Every check that can run against the
pre-image runs in step A, including
scripts/splice.mjs --check, which is the structural half of the body transform run against the pre-image alone — so a refusal it finds means nothing changed (principle-fail-closed). What can only be computed after the upload is named, and lands onuploaded-not-writtenrather than onrefused. - Every caller-supplied string is data, not source and not markup. A path,
a caption, a note, and a failure reason each reach a command as one quoted
"$VAR"expansion, and each is normalized by the same function before it renders into a body (principle-never-interpolate,principle-untrusted-input-is-data). - Nothing blocks, prompts, or retry-loops. A capability gap, a failed
entry, or a failed read-back degrades the result and says so
(
principle-optimization-never-dependency,principle-skip-loudly). - Never delete what you did not write. A trailing run of stray image lines
left by an earlier crash is reported and re-emitted below the new section,
never removed. Anything else this skill did not write is a refusal that
leaves the body byte-identical, because a duplicate is recoverable and a
deletion is not. The rule is stated positively, so nothing falls outside it:
the only lines a replace may delete are the shapes this skill's own renderer
emits — a
**caption**line in the position the renderer puts one, an![screenshot-NN]image, a> _note:_note with its bare>separator, and aNot uploaded:line. Ownership is provenance, not shape: the note carries a marker a reviewer would not type and a caption is owned only directly above an image this skill wrote, so a reviewer's own blockquote or bold line refuses rather than being read as this skill's output. Prose, an HTML comment, a raw HTML container, an image in any form the splice cannot count, or a body shape the splice does not model each refuse, with the offending line number named. - Nothing leaves the declared root, and nothing that is not an image is
uploaded. The entries file declares one absolute top-level
root, and every entry's path is resolved and must sit inside it. Acceptance is decided by content type, never by extension:file -b --mime-typemust reportimage/*, and an environment that yields no type fails the check, because unverified is not an image. That is what keeps a.env, anid_ed25519, or a.git/configoff a world-readableuser-attachmentsURL.
What ships with it
10 files 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.
- agents/openai.yaml 177 B
- references/01-input-and-result.md 18 KB
- references/02-upload-and-body-edit.md 33 KB
- references/03-verify.md 5.5 KB
- references/04-rejected-approaches.md 2.8 KB
- scripts/pre-image.sh 2.9 KB runs code
- scripts/resolve-pr.sh 5.9 KB runs code
- scripts/splice.mjs 39 KB runs code
- scripts/upload.sh 15 KB runs code
- scripts/write-companion.sh 6.3 KB runs code
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 · 96 lines · 51 tokens per session scan A ac00b198cb05
pr-screenshots is a skill published in the GitHub repository bostonaholic/team (11 stars, last pushed today), licensed MIT. It adds 51 tokens to every session and 1,329 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-09-07.
Other skills, from other repositories
git-integration
Git commit patterns, formats, and conventions for GSD methodology. Provides atomic commits per task, structured commit messages, planning file commits, branch management, and milestone tag operations.
audit-trail
Full traceability from PRD to code commit through the CCPM spec-driven pipeline.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.
maintenance-orchestration
Technical debt management including branch cleanup, doc verification, TODO scanning, and dependency auditing.
worktree-isolation
Manage git worktree lifecycle for safe, isolated parallel development.
github-sync
Bidirectional synchronization of epics and tasks with GitHub issues, labels, and relationships.