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/socketdev/sauce/cargo-publishnpx skills add SocketDev/sauce --skill cargo-publishgit clone --depth 1 https://github.com/SocketDev/sauceWhat 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.00059 | $0.00700 |
| Opus 5 | $0.00030 | $0.00350 |
| Sonnet 5 | $0.00012 | $0.00140 |
| Haiku 4.5 | $0.00006 | $0.00070 |
Grade A, and why
cargo-publish 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 — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
crates.io publish (staged model)
crates.io publishes are PERMANENT (yank-only, no unpublish), so the kit's
cargo flow is dry-run by default everywhere and the real publish runs only
under the cargo-publish GitHub environment through crates.io Trusted
Publishing (OIDC - no long-lived token anywhere).
Bootstrap
The same bootstrap stands up the cargo-publish environment
(branch-restricted) and installs cargo-publish.yml:
node scripts/socket-release/bootstrap.mts github-env staged-config --apply
crates.io's trusted-publisher config (crate ↔ repo ↔ workflow ↔ environment) is set on crates.io's settings page by the crate owner - a human step; render it as a gate with the crate's settings URL, do not improvise a browser drive.
Release cycle
-
Bump:
Cargo.tomlversion + CHANGELOG, commitchore: bump version to <version>, push. -
Dry-run locally:
node scripts/socket-release/cargo-publish.mts --staged --dry-run -
Publish from CI: the operator dispatches the
cargo publishworkflow from the Actions UI withpublish: true(gh workflow runis guard-blocked for agents - the human clicks). The workflow runs--directunder thecargo-publishenvironment with the OIDC-minted token; a dry-run dispatch runs--staged --dry-runungated. -
Index propagation: the publish is not "done" until the version appears in the crates.io index - the engine's registry gate polls
https://index.crates.io/<path>and the tag/release cut waits for it (ORDER RULE: the GitHub release follows index resolvability, never precedes it). Do not retry a publish that is merely propagating. -
The tag + immutable release cut follows automatically; a gap heals with
node scripts/socket-release/github-release.mts --tag vX.Y.Z --release.
Local emergencies
node scripts/socket-release/cargo-publish.mts --direct publishes from the
operator's machine with their own cargo login token - 2FA/auth is theirs
to provide (gate, never scripted). --approve promotes a staged cargo
entry where the staged lane is available; --package <name> disambiguates
a workspace (multi-crate ordering is deferred - the tool refuses ambiguity
rather than guessing).
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 · 72 lines · 59 tokens per session scan A d7d4628f1b5a
cargo-publish is a skill published in the GitHub repository SocketDev/sauce (2 stars, last pushed 5d ago), licensed MIT. It adds 59 tokens to every session and 700 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-31.
Other skills, from other repositories
release
Evaluate readiness and publish to crates.io.
release-mcp
Release a new version of the tapo-mcp crate (MCP server), versioned independently from the tapo libraries.
release-crate
Publish a crate release to crates.io with changelog, git tag, and GitHub release. Use when releasing a new version of any workspace crate.
release-process
End-to-end release runbook for playwright-rust — version bump, supply-chain refresh, per-crate CHANGELOGs, tag-prefix routing for the three workspace crates, the safer push-then-tag workflow that waits for CI before publishing, and the post-release follow-ups.
rust-release
Plan and execute Rust release engineering. Use when: publishing a crate, setting up release automation, cross-compiling binaries. Do not use: for version bumping alone, local build setup.
jackin-release
Use only when the user explicitly requests this skill. Cuts a jackin❯ release — runs the readiness gates, writes the changelog, recommends a version, then executes cargo release on explicit operator confirmation.