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/vicmaster/coide/ship-featurenpx skills add vicmaster/coide --skill ship-featuregit clone --depth 1 https://github.com/vicmaster/coideWhat 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.00031 | $0.00668 |
| Opus 5 | $0.00015 | $0.00334 |
| Sonnet 5 | $0.00006 | $0.00134 |
| Haiku 4.5 | $0.00003 | $0.00067 |
Grade A, and why
ship-feature 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 — 38 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ship Feature
Wrap up a completed feature: ensure tests exist and pass, commit all changes, move it from VISION.md's roadmap into SHIPPED.md, add to release notes, and push.
Instructions
- Run
git statusandgit diffto see all staged and unstaged changes - Verify tests exist for the feature:
- Look at the changed/added files and identify any new store actions, utility functions, or event parsing logic
- Check if corresponding test files already exist under
src/__tests__/ - If tests are missing for new logic, write Vitest tests before proceeding:
- Store actions →
src/__tests__/store/ - Utility functions →
src/__tests__/utils/ - Follow the existing test patterns (see
sessions.test.ts,diff.test.ts,mcpParsing.test.tsfor examples)
- Store actions →
- Pure UI components without logic don't require tests, but any extracted logic they use does
- Run the full test suite with
npx vitest run- If any test fails, fix the issue and re-run until all tests pass
- Do NOT proceed to commit if tests are failing
- Read
VISION.mdand find the unchecked item (- [ ]) under## Roadmapthat best matches: "$ARGUMENTS"- If no match is found, list the unchecked items and ask which one (or skip — polish/bug fixes don't always map to a roadmap item)
- Move the matched item to
SHIPPED.md:- Remove the
- [ ]line from VISION.md's## Roadmapsection - Append the item (without the
[ ]checkbox, just- Feature name — description) to the appropriate section inSHIPPED.md(e.g.## Core Roadmap (shipped)or## Copycat — Features parity with Claude Code CLI (shipped)); if no section fits, add to a## Misc (shipped)section, creating it if absent - If step 4 was skipped (no roadmap match), do NOT touch VISION.md or SHIPPED.md in this step
- Remove the
- Update release notes in
src/renderer/src/data/releaseNotes.ts:- Always append a one-line description to the first entry's
notesarray (regardless of what version it shows — the release script renames it on release) - Keep note descriptions concise (under 80 chars), user-facing language (not implementation details)
- Always append a one-line description to the first entry's
- Stage all relevant changed files (including the VISION.md/SHIPPED.md updates, release notes update, and any new test files)
- Write a commit message that describes the feature work done (based on the actual code changes), NOT just "mark as done"
- Commit and push to origin
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 · 38 lines · 31 tokens per session scan A 67d47be6dffc
ship-feature is a skill published in the GitHub repository vicmaster/coide (10 stars, last pushed 2mo ago), licensed MIT. It adds 31 tokens to every session and 668 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
release
Release a new version of the project.
h4tcher-release-prep
Prepare a hatch3r release — version bump, changelog completeness + sync, repo + website docs currency, quality gates, adapter output verification, and release-notes reconciliation with CI.
tlamatini-self-update-inclusion
Sweep the whole codebase and keep the SELF-UPDATE pipeline complete — so every new asset/feature added to Tlamatini is actually carried into a release by build.py AND survives (or is correctly replaced by) the self-update swap. Invoke whenever you add/rename a new agent, top-level file or directory, dependency…
release-readiness
Use this skill whenever the conversation mentions releasing, shipping, publishing, promoting to PyPI, "ship it", "release X.Y.Z", "ready to release", "let's publish", or any phrase suggesting moving codevira to production. Walks the 5-gate release gauntlet (G1-G5) and refuses to proceed without evidence at every gate.…
github
Use the gh CLI for GitHub issues, PR status, CI/logs, comments, reviews, releases, and API queries.
sampo-changeset
Create or update Sampo changesets for Mitsuro version bumps and changelogs.