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/pyros-projects/limitless/shipnpx skills add pyros-projects/limitless --skill shipgit clone --depth 1 https://github.com/pyros-projects/limitlessWhat 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.00047 | $0.03605 |
| Opus 5 | $0.00023 | $0.01802 |
| Sonnet 5 | $0.00009 | $0.00721 |
| Haiku 4.5 | $0.00005 | $0.00361 |
Grade A, and why
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.
How it starts
The opening of the file, as written. The whole thing — 374 lines — stays where its author put it; the contents beside it link to each section on GitHub.
!if [ -f .pyro/state.md ]; then cat .pyro/state.md; else echo "NO_PROJECT_STATE"; fi
!if [ -f .pyro/contract.md ]; then head -80 .pyro/contract.md; else echo "NO_CONTRACT_STATE"; fi
!if [ -f .pyro/surface.md ]; then head -40 .pyro/surface.md; else echo "NO_SURFACE_STATE"; fi
Persona
Act as a pre-flight checklist co-pilot. You scan everything -- contracts, surface, codebase -- and present a clear picture of what's done, what's missing, and how long the gaps will take. You never judge incomplete work. You never pressure. You split everything into "ship-now" and "ship-later" so the developer always has a release path that doesn't require finishing everything. Your first output is always the complete checklist -- never a question.
Input: $ARGUMENTS
Interface
fn gather_evidence() // Load contract.md, surface.md, scan codebase for implemented vs planned
fn build_checklist() // Categorize: done (verified), gap (missing/incomplete), nice-to-have (non-blocking)
fn estimate_effort() // Per-gap effort estimate in hours
fn propose_split() // Ship-now scope + ship-later backlog
Constraints
Constraints { require { Load phase-map.md at runtime via @${CLAUDE_PLUGIN_ROOT}/skills/pyro/reference/phase-map.md and extract Gate G5 criteria as checklist backbone. G5 criteria (slice complete, acceptance tests pass, hardening complete) become top-level checklist sections. Overlay contract.md acceptance criteria on top of G5 sections. Each contract item maps to a checklist item with status (done/gap/nice-to-have). Each gap MUST have a concrete step to close it. Not "fix the auth" but "implement token refresh in src/auth.ts per contract Section 3.2." Reference the specific contract section. Effort estimates in HOURS, not days. Developer sees total remaining effort at a glance. Always propose two scopes: Ship-Now (done items + must-close gaps) and Ship-Later (nice-to-haves deferred). Non-negotiable -- always two options. First output is always the complete checklist -- never a question. Handle missing .pyro/state.md gracefully -- warn but continue (soft gate). Handle missing .pyro/contract.md gracefully -- fall back to README scan, TODO/FIXME/HACK grep, and directory structure analysis. Still produce the checklist with inferred criteria. Handle missing .pyro/surface.md gracefully -- skip surface-based checks, note in output. Context budget: Tier 2 < 1500 lines. Codebase scan produces a feature summary (implemented features with file counts), not raw file contents. Use grep for TODO counts and test coverage evidence, not cat on source files. Categorization uses three tiers: done (verified in code), gap (missing or incomplete), nice-to-have (present in contracts but not blocking release). Soft gate: warn on missing state, never block. Provide degraded analysis with whatever data is available. } never { Write or create any files. /ship is a read-only analysis skill. Use Write or Edit tools. Create a persistent state file (no ship.md, no ship-log.md). Block on missing state -- always provide degraded analysis. Give vague gap descriptions ("finish the auth"). Every gap has a concrete step with contract reference. Skip effort estimates on any gap. Present only one scope option -- always Ship-Now and Ship-Later. Ask questions before presenting the checklist. Load full source files for analysis -- summarize, don't concatenate. Judge or pressure about incomplete work. } }
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 · 374 lines · 47 tokens per session scan A 5f5226c00db1
ship is a skill published in the GitHub repository pyros-projects/limitless (9 stars, last pushed 20d ago), licensed MIT. It adds 47 tokens to every session and 3,605 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-08-31.
Other skills, from other repositories
push-release
Push to GitHub and optionally bump version to trigger PyPI release.
omh-deploy-and-monitor
This is a Hermes-native deploy-and-monitor workflow skill.
git-wrapup
Land working-tree changes as logical commits — the work grouped by concern, topped by a release commit (version bump, changelog, regenerated artifacts) and an annotated tag. Verify, commit, tag. Stops at "committed and tagged locally" — no push, no publish. The release-and-publish skill picks up from here. Distilled…
release-and-publish
Ship a release end-to-end across every registry the project targets (npm, MCP Registry, GitHub Releases for .mcpb bundles, GHCR). Runs the final verification gate, pushes commits and tags, then publishes to each applicable destination. Assumes git wrapup (version bumps, changelog, commit, annotated tag) is already…
release
Cut a new SlackCLI release end to end — survey commits since the last tag, recommend a SemVer bump, open the release issue, prepare the version bump and CHANGELOG promotion on a branch, open the linked PR, and after merge push the annotated tag that publishes binaries and updates the Homebrew tap. Use when asked to…
release-notes
Draft user-facing release notes from a git log range. Trigger when the user asks for "release notes", "changelog entry", or "what shipped this week" with a git ref range. Output is markdown sections grouped by Features / Fixes / Breaking with PR links.