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/romerma/mstack/specnpx skills add romerma/mstack --skill specgit clone --depth 1 https://github.com/romerma/mstackWhat 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.00068 | $0.00709 |
| Opus 5 | $0.00034 | $0.00354 |
| Sonnet 5 | $0.00014 | $0.00142 |
| Haiku 4.5 | $0.00007 | $0.00071 |
Grade A, and why
spec 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 — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec
The spec path is opt-in. It turns on when the item has sdd: true, carries a
decision_required field, or the change crosses several subsystems. Otherwise the item's
acceptance array is the contract and you should be implementing.
Four artifacts in .mstack/specs/<slug>/, all four required before the item leaves
specifying. Templates in references/templates.md, statement kit in
references/ears.md.
1. Ground the spec in its source
Read what the item cites, and re-verify every file:line it references. Issues rot: one
written weeks ago names code that has moved, and it can be wrong about the mechanism on the day
you pick it up.
Open with the provenance:
> Source: issue #370. This spec is authoritative for implementation;
> #370 remains the discussion venue.
If the source and the spec disagree, the source is the newer intent. Stop and reconcile. Implementing an outdated spec correctly is still the wrong outcome.
2. Interview the repository, not the user
Most open questions are answered by the code, the history, or an existing decision. Go there
first. Bring the human only the forks the repository genuinely cannot settle: product choices
with different user-visible outcomes. Those go in decision_required, which is what triggers
the human gate.
3. Requirements
Stable ids R1, R2, and EARS statements. One requirement carries one obligation.
A spec is a behaviour contract, not an implementation plan. Quick test: if the implementation could change without changing externally visible behaviour, it does not belong here.
Every acceptance bullet maps to at least one requirement. Every requirement gets at least one WHEN/THEN scenario.
4. Tasks
Every task names the requirements it covers: - [ ] 1.1 ... (covers R1, R3). The last group is
always verification and close. A requirement no task covers is a requirement nobody will build.
5. Grill it, with a different pass
mstack:spec-reviewer, which has no Write and no Edit, and which must not be the pass that
wrote the spec. Three questions in writing:
What ships with it
2 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 · 71 lines · 68 tokens per session scan A eef807d2470d
spec is a skill published in the GitHub repository romerma/mstack (1 stars, last pushed 8d ago), licensed MIT. It adds 68 tokens to every session and 709 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
happiness-skill
当用户问「怎么才能更幸福/为什么得到了还不满足/怎么减少焦虑」时调用。 核心理念: 幸福是缺憾感清空的默认状态, 是可训练的技能; 欲望是与自己的契约(得到前不快乐), 同时只留一个重大欲望; 活在当下。 不适用于: 临床抑郁等需要专业治疗的场景(本书方法不能替代医疗)。 Triggers: 幸福/不快乐/欲望/焦虑/知足/活在当下/happiness/desire/anxiety.
gsd-audit-milestone
Audit milestone completion against original intent before archiving.
spec-kitty-charter-doctrine
Run charter interview, generation, context, and sync workflows for project governance in Spec Kitty 3.x. Access doctrine artifacts programmatically via DoctrineService. Resolve agent profiles. Load action-scoped governance context iteratively, not all at once. Triggers: "interview for charter", "generate charter"…
spec-kitty-spdd-reasons
Drive REASONS Canvas authoring and review for Spec Kitty missions that opted in to Structured-Prompt-Driven Development (SPDD) via charter selection. Triggers: "use SPDD", "use REASONS", "generate a REASONS canvas", "apply structured prompt driven development", "make this mission SPDD". Does NOT handle: enforcing SPDD…
dependency-upgrade
Plan, batch, and verify dependency upgrades safely. Triages outdated packages into risk tiers, upgrades in order (dev/minor/patch first, runtime majors last), verifies each batch, and produces an auditable commit sequence. Use when asked to "upgrade deps", "bump packages", "update nodemodules", "fix vulnerabilities"…
forensics
Post-mortem a failed GSD auto-mode run. Traces symptom to root cause via .gsd/ activity, journal, metrics, and lock artifacts, producing a filing-ready bug report with file:line refs and a fix suggestion. Use when asked to "forensics", "post-mortem", "why did auto-mode fail", "trace the stuck loop", "debug the crash"…