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 Shailesh200/prism --skill prism-shipgit clone --depth 1 https://github.com/Shailesh200/prismWrote 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/shailesh200/prism/prism-ship)<a href="https://agentmods.dev/skills/shailesh200/prism/prism-ship"><img src="https://agentmods.dev/badge/skills/shailesh200/prism/prism-ship.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.00076 | $0.00540 |
| Opus 5 | $0.00038 | $0.00270 |
| Sonnet 5 | $0.00015 | $0.00108 |
| Haiku 4.5 | $0.00008 | $0.00054 |
Grade A, and why
prism-ship 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.
What it actually says
Ship it
A PR description written from the diff reads like a changelog. One written from the impact tells a reviewer where to look, which is the only thing a description is for.
The procedure
1. Check the work is complete. review_changes with no paths. If it flags
something, raise it with the user before opening a PR — better to ask now than
to have a reviewer find it.
2. Describe the impact. blast_radius on the primary changed paths. What
this produces is the part of the description that a reviewer cannot get by
reading the diff: which areas are affected, and how far the change reaches.
3. Name the verification. test_impact on the changed paths. State which
suites cover the change and — if you ran them in this session — that they
passed. Do not claim a run you did not see.
4. Write the description. Structure it as:
- What changed, in one or two sentences of plain prose
- Why — the ticket, the bug, the request
- Impact — from blast radius: the affected areas, and anything a reviewer should look at closely
- Verification — what was run, what was not
Skip empty sections rather than filling them with "N/A".
5. Raise it with your own tools. Push the branch and open the PR with the editor's GitHub tools. Request reviewers if the user asked for specific people or the repository has a convention you can see.
6. Move the ticket. If the work came from Linear or Jira and the user asked you to update it, transition it with the editor's own connector and link the PR.
Boundaries
Prism holds no credentials for GitHub, Linear or Jira. Everything in steps 5 and 6 runs through connectors configured in this editor. If none is connected, produce the description as text, tell the user the PR was not raised, and stop.
Confirm before pushing to a shared branch, before requesting review from named people, and before any ticket transition. Writing a description is not permission to raise the PR.
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 · 52 lines · 76 tokens per session scan A 00b5165c436a
prism-ship is a skill published in the GitHub repository Shailesh200/prism (1 stars, last pushed 3d ago), licensed MIT. It adds 76 tokens to every session and 540 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-09-05.
Other skills, from other repositories
batch
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
gsd-complete-milestone
Archive completed milestone and prepare for next version.
github-cli
Default GitHub skill for the action agent. Use githubcli for any GitHub request — create/list/view/close issues and PRs, assign, labels, repos, releases, checks, github.com/owner/repo URLs, or gh api. Prefer over shellrun/!gh. Run these with githubcli in the current agent turn.
github
Drive GitHub via the official gh CLI — repos, issues, pull requests, releases, gists, Actions runs, and raw REST through gh api. Use when the user asks to inspect or manage GitHub.
maintainer-release-ops
Maintainer release and milestone operating workflow. Use when a maintainer wants to plan a release, assess milestone health, coordinate release blockers, or generate a release-focused review brief.
testdino-releases
Use when the user wants to browse, inspect, create, or update releases/milestones in a TestDino project. Covers listreleases, getrelease, createrelease, and updaterelease. Accepts counter-style IDs like MS-12.