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/bacsystem/parallel-plan-executor/shipnpx skills add bacsystem/parallel-plan-executor --skill shipgit clone --depth 1 https://github.com/bacsystem/parallel-plan-executorWhat 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.02193 |
| Opus 5 | $0.00023 | $0.01097 |
| Sonnet 5 | $0.00009 | $0.00439 |
| Haiku 4.5 | $0.00005 | $0.00219 |
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 yesterday.
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 — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
cys:ship
Overview
A guided workflow that takes changes from the working tree to a pull request, following consistent conventions: branch naming, code review, Conventional Commits, automatic SemVer, and a PR template. Guided, not blind — confirm with the user at the review, doc-update, and PR steps.
When to Use
- Changes are done and ready to be committed and shared.
- User says "ship this", "commit and open a PR", "create the PR".
- A feature or fix is finished and needs a branch + commit + PR.
Not needed after a cys:run (parallel-plan-executor) run launched with
openPr: true — that run's own Handoff agent already did this (same
conventions, hand-rolled in its prompt because the sandboxed Workflow
script can't invoke skills). Use cys:ship when cys:run ran without
openPr: true (it only leaves handoff.md with suggestions, nothing
pushed) or for any change that never went through cys:run at all.
Skip when: the user only wants a quick local commit with no review/PR.
Conventions
| Aspect | Rule |
|---|---|
| Branch | type/description, kebab-case (e.g. feat/login-form) |
| Commit | Conventional Commits, in English |
| Types | feat, fix, docs, style, refactor, perf, test, build, ci, chore |
| SemVer (≥ 1.0) | feat → minor · fix → patch · BREAKING CHANGE (or !) → major |
| Other types | docs/style/refactor/perf/test/build/ci/chore → patch |
SemVer (0.x) |
BREAKING → minor (0.y→0.(y+1), resets patch) · everything else → patch |
| PR base | develop if that branch exists (local or on the remote), else main |
| Tag | Created after the PR merges, and only if that merge's base was main — a merge into develop is not a release, see step 10 |
| PR | Via gh, ask before creating |
Rules & tie-breakers
- One authoritative type. Classify the change ONCE (step 2). That type drives the branch name, the commit, and the SemVer bump. They must agree.
- Mixed changes: pick the highest-impact type for the version
(
BREAKING>feat>fix> everything else). If the diff contains clearly separate logical changes, make separate commits; otherwise one commit. - Pre-1.0 (
0.x.y): SemVer is still unstable, so the normal table does NOT apply. ABREAKING CHANGE/!bumps the minor (0.2.3→0.3.0);feat,fix, and every other type bump the patch (0.2.3→0.2.4). Use the ≥ 1.0 rules only once the project actually reaches1.0.0. - Branch description: kebab-case derived from the commit subject, ≤ 5 words
(e.g. subject "add token refresh on 401" →
feat/token-refresh). - Version source precedence:
package.json→VERSION→ latestgit tag→CHANGELOG.md. Strip a leadingv. If two sources disagree, use the highest. If no source records a version, start from0.1.0and createCHANGELOG.md. - Staging: only stage the reviewed files plus the docs you updated. Never
git add -A/git add .blindly. - Remote: never hardcode
origin. Resolve the push remote fromgit remote -v— prefer the current branch's upstream if one is set, else the sole remote, else ask which to use. Some repos push through an SSH-alias remote (e.g.git@host-alias:org/repo.git) whose name is notorigin. Use the resolved remote name for the push (step 9) and the post-merge tag (step 10). - Changes = tracked modifications (staged or unstaged) and/or new files. Whitespace-only or no changes → stop.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 138 lines · 47 tokens per session scan A 40aec0615b42
ship is a skill published in the GitHub repository bacsystem/parallel-plan-executor (2 stars, last pushed 1mo ago), licensed MIT. It adds 47 tokens to every session and 2,193 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
sql-reporting
Conventions and review steps for writing analytics SQL against the warehouse. Use whenever the task involves querying tables, building a report, or aggregating metrics.
html-ppt-hermes-cyber-terminal
OpenDesign + BYOK: choosing and wiring your own model, hands-on — cost, quality, and the routing decision. Built as a decision-grade AI literacy deck for engineers, IT, applied-AI teams.
verify-security
安全校验关卡。自动扫描代码安全漏洞，检测危险模式，确保安全决策有文档记录。当用户提到安全扫描、漏洞检测、安全审计、代码安全、OWASP、注入检测、敏感信息泄露时使用。在新建模块、安全相关变更、攻防任务、重构完成时自动触发。.
development
开发语言能力索引。Python、Go、Rust、TypeScript、Java、C++、Shell。当用户提到编程、开发、代码、语言时路由到此。.
post-build-flow
Handles workflow verification and setup after build-workflow succeeds, or when the message contains workflow-verification-follow-up or workflow-setup-required. Load after direct builds, when verificationReadiness requires action, or on orchestrator verify/setup follow-up turns.
n8n:human-like-code-review
Reviews a GitHub pull request like a thoughtful human reviewer and writes the feedback to a markdown file. Prioritizes context, architecture fit, solution complexity, bugs, security edge cases, and missing tests. Use when given a PR URL to review, or when the user says /human-like-code-review.