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/nikzlabs/shipit/probenpx skills add nikzlabs/shipit --skill probegit clone --depth 1 https://github.com/nikzlabs/shipitWrote 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/nikzlabs/shipit/probe)<a href="https://agentmods.dev/skills/nikzlabs/shipit/probe"><img src="https://agentmods.dev/badge/skills/nikzlabs/shipit/probe.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 | $0.00028 | $0.00747 |
| Opus 5 | $0.00014 | $0.00374 |
| Sonnet 5 | $0.00006 | $0.00149 |
| Haiku 4.5 | $0.00003 | $0.00075 |
Grade A, and why
probe 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 3d 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
The probe report
This skill ships with ShipIt's test plugin (docs/262). If you can read this
text through your skill listing, skills materialization (req 22) works: the
file was copied from the plugin checkout into your backend's discovery root
under a plugins--<alias>--probe namespace.
Run probe in the project workspace. It prints one JSON report and mutates
nothing. Flags: --bump increments the shared counter before reporting;
--host-check also tests HTTPS egress to the declared host (example.com).
| Field | Verifies |
|---|---|
cwd |
CLI runs with cwd = the project workspace (req 21) |
mode / env.SHIPIT_PLUGIN_COMMIT |
the self/consumer discriminator: a consumer generation carries its exact commit; repo: self runs the live tree, no commit (reqs 15, 27) |
credential.set |
PROBE_TOKEN injected for this command only (req 23) |
settings.greeting |
the validated settings file (req 26), and which side wrote it: the consuming project's overrides.settings is hello from the consuming project, the manifest's default is hello from the probe. Reading the default under this repo's own shipit.yaml, which sets the override, means the consumer half was ignored (nikzlabs/shipit#2298 finding 2) |
project.readable |
the workspace handle (req 21) |
state.counter |
shared state with the probe service — probe --bump, then reload its page: same number (reqs 17, 18) |
checkout.writable |
this surface's own mount — not the self/consumer signal (read mode), but it does check the rule directly: the plugin's tree is writable exactly when it is the project, so a consumer generation reports false and repo: self reports true (reqs 7, 15, 27). On the service surface it measures this fragment's own .:/app, which ShipIt forces read-only for a tracked generation and leaves as declared under repo: self |
install.matchesActiveCommit |
install ran for the active generation; null under self-use, which has no generations (req 7) |
dependency.project / .plugin |
a real dependency loads from each mount of the tree, reported per root because /plugin and /project are separate mounts even when they are one tree. Under repo: self the CLI must show both resolved: true, used: true — the working tree's own agent.install prepares the tree the CLIs and services run out of (req 27); the service shows plugin: resolved false, since its fragment mounts only its own directory at /app. This is the one field that would have caught nikzlabs/shipit#2298 (test-plugin/README.md has the full table) |
The probe service renders the same report from the service surface at its
preview URL, with a counter button and an Agent Interface SDK section: it
awaits window.shipit.ready, checks embedded, and its "Send counter to
agent" button exercises the browser-to-agent path (req 3).
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.
- 3d ago First seen · 33 lines · 28 tokens per session scan A 6199139f26a2
probe is a skill published in the GitHub repository nikzlabs/shipit (6 stars, last pushed 4d ago), licensed Apache-2.0. It adds 28 tokens to every session and 747 once invoked, about $0.0001 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
lanes-sessions
Use when managing Lanes issues or driving Claude Code sessions through the lanes MCP tools — creating issues, starting/stopping/inspecting sessions, batch-launching work across worktrees, reading terminal output, attaching labels and components by UUID, or moving issues across the backlog/todo/in-progress/done…
lanes-forms
Use when the user wants a form backend or contact form set up (a live POST endpoint that captures submissions and emails them), OR wants an agent to fill in / submit to a form on their behalf. Lanes Forms creates and manages hosted form endpoints from Claude Code. Triggers on "set up a contact form", "provision a…
github-lanes-bridge
Use when bridging GitHub and Lanes — importing GitHub issues into Lanes for local Claude Code execution, batch-spawning sessions per ticket, decomposing one GitHub issue into multiple Lanes sub-issues with dependencies, or posting session results (PR links, comments, follow-up issues) back to GitHub. Triggers on…
linear-lanes-bridge
Use when bridging Linear and Lanes — importing Linear issues into Lanes for local Claude Code execution, batch-spawning sessions per Linear ticket, decomposing one Linear issue into multiple Lanes sub-issues with dependencies, or posting session results (PR links, comments, status updates) back to Linear. Triggers on…
embedding-strategies
Select and optimize embedding models for semantic search and RAG applications. Use when choosing embedding models, implementing chunking strategies, or optimizing embedding quality for specific domains.
docx-comment-reply
Reply to comments (批注) in Word .docx/.doc files: extract comment context, draft replies, write threaded replies back, and validate OOXML.