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/magebyte-zero/spec-superflow/spec-mergernpx skills add MageByte-Zero/spec-superflow --skill spec-mergergit clone --depth 1 https://github.com/MageByte-Zero/spec-superflowWhat 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.00038 | $0.01309 |
| Opus 5 | $0.00019 | $0.00655 |
| Sonnet 5 | $0.00008 | $0.00262 |
| Haiku 4.5 | $0.00004 | $0.00131 |
Grade A, and why
spec-merger 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.
How it starts
The opening of the file, as written. The whole thing — 114 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec Merger
Before the final executing → closing transition, delta specs (ADDED/MODIFIED/REMOVED/RENAMED) must be published into the main spec base. changes/<change>/ remains the active workflow source; root specs/ is only the published baseline. Specs that aren't synced become lies. A change already in closing must not be routed to spec-merger.
Execution-State Guard
Before ssf sync or any other write, run
ssf state get <change-dir> state.
Continue only when the persisted state is exactly executing. If it is
closing → STOP: "Closing is terminal. Do not route this change to spec-merger;
synchronization belongs before the final executing → closing transition." For
any other state, or if the state cannot be read → STOP and route through
workflow-start; do not perform side effects.
Pre-Flight Checks
Conflict Detection
Run ssf sync <change-dir>. If conflicts are detected (same requirement modified by multiple changes), present the conflict list to the user for resolution order.
Sync Process
Step 1: Identify Deltas
Each specs/<capability>/spec.md under the change folder contains delta operations under ## ADDED/MODIFIED/REMOVED/RENAMED Requirements.
## Purpose is an optional top-level delta extension. Use it only when creating a canonical main spec. When it is absent or empty, the sync result uses and reports a deterministic default Purpose so legacy delta specs remain usable. A delta Purpose must not overwrite an existing main spec Purpose.
Step 2: Apply by Operation
ADDED: Append the requirement to the published baseline's ## Requirements. Create a canonical main spec if it does not exist.
MODIFIED: Match on ### Requirement: <name> and replace its description and scenarios. Flag if the requirement does not exist in the canonical baseline.
REMOVED: Remove the matched requirement from the published baseline. Flag if it does not exist.
RENAMED: Match the old name and change its header to the new name. Flag if the new name collides with an existing requirement.
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 · 114 lines · 38 tokens per session scan A 794a1d99a6c9
spec-merger is a skill published in the GitHub repository MageByte-Zero/spec-superflow (776 stars, last pushed 4d ago), licensed MIT. It adds 38 tokens to every session and 1,309 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-30.
Other skills, from other repositories
chinese-documentation
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用，不要根据上下文自动触发。.
chinese-git-workflow
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用，不要根据上下文自动触发。.
chinese-code-review
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。.
dispatching-parallel-agents
当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用.
executing-plans
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用.
receiving-code-review
收到代码审查反馈后、实施建议之前使用，尤其当反馈不明确或技术上有疑问时——需要技术严谨性和验证，而非敷衍附和或盲目执行.