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/lbk-open/super-spec/ss-archivenpx skills add lbk-open/super-spec --skill ss-archivegit clone --depth 1 https://github.com/lbk-open/super-specWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/lbk-open/super-spec/ss-archive)<a href="https://agentmods.dev/skills/lbk-open/super-spec/ss-archive"><img src="https://agentmods.dev/badge/skills/lbk-open/super-spec/ss-archive.svg" alt="Measured on agentmods" height="20"></a>What 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.00995 |
| Opus 5 | $0.00034 | $0.00498 |
| Sonnet 5 | $0.00014 | $0.00199 |
| Haiku 4.5 | $0.00007 | $0.00100 |
Grade A, and why
ss-archive 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 4d 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 — 111 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Archive OpenSpec Change
Merge OpenSpec delta specs from openspec/changes/<change-id>/specs/ into
openspec/specs/, then move the change directory to
openspec/changes/archive/YYYY-MM-DD-<change-id>/.
This skill is idempotent. The ss-create-pr skill calls it automatically before opening a
pull request.
Inputs
Optional: a specific <change-id>, and/or --dry-run to validate and report without
writing anything.
Process
Step 1: Discover the Active Change
If a <change-id> was given, use it. Otherwise:
- List directories under
openspec/changes/, excludingarchive/. - If none exist, report a no-op.
- If exactly one exists, use it.
- If multiple exist, ask the user which one to archive.
If openspec/changes/<change-id>/specs/ has no delta files, report a zero-spec no-op.
Step 2: Sync With Git
Check the working tree status.
- If there are uncommitted changes: continue only if they are the intended OpenSpec delta/code changes for this branch. Stop if unrelated files are dirty — never stash, discard, or rewrite the user's work.
- Don't rebase-pull while the worktree is dirty.
- If the worktree is clean, sync first (fetch and rebase against upstream).
- If the worktree is dirty but only contains the intended change, perform the archive merge and commit first, then rebase-pull only if needed before pushing.
Step 3: Validate Delta Format
For every openspec/changes/<change-id>/specs/<cap>/spec.md:
- section headings are only ADDED / MODIFIED / REMOVED / RENAMED Requirements
- every section heading is followed by at least one
### Requirement:entry — remove empty sections entirely - every Requirement has at least one
#### Scenario: MODIFIEDentries copy a matching source-of-truth Requirement in fullREMOVEDentries include a Reason and a Migration noteRENAMEDentries useFROM: <old> → TO: <new>
If validation fails, stop and list the exact files and fixes needed.
Step 4: Merge Deltas Into Source-of-Truth Specs
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.
- 4d ago First seen · 111 lines · 68 tokens per session scan A 1398d97b971a
ss-archive is a skill published in the GitHub repository lbk-open/super-spec (1 stars, last pushed 13d ago), licensed Apache-2.0. It adds 68 tokens to every session and 995 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
release
CONTRIBUTOR TOOL - Cut a plugin release: bump plugin.json version, finalize CHANGELOG, update README if needed, gate on make ci, commit, tag vX.Y.Z, and create the GitHub release. Use when shipping a new plugin version. NOT distributed.
craft-plugin-release
Releasing Craft CMS plugins — tagging, Packagist propagation, GitHub releases, branch promotion, shared-library ordering, history rewrites. ALWAYS load when cutting, preparing, verifying, or debugging a plugin release: bumping a version, dating a changelog, creating or moving a git tag, or checking what Packagist…
done
End-of-session shipping gate — "prove it works, then ship it." Runs an evidence checklist (full test suite, lint/typecheck, build, and actually running the change — output quoted, never asserted), then a fresh-context two-stage review by a sub-agent that sees only the diff and the spec: spec-compliance first…
git-collaboration-workflows
Run git collaboration that scales — trunk-based vs git-flow decided by deploy cadence, branch protection and required checks, PR sizing and review etiquette, monorepo vs polyrepo trade-offs, release branches and hotfixes, and history hygiene with disciplined merges.
git-for-research-code
When the user wants to version-control optimization research code - small commits per experiment change, tags for paper result snapshots, .gitignore for solver logs, linking result tables to commit hashes, and branch strategy for risky refactors. Also use when the user mentions "git workflow," "version control…
vibe-changelog
Generates and maintains two changelog files from git tags, TASKS.md, DECISIONS.md, and feature folders. CHANGELOG.md at repo root is developer-facing in Keep a Changelog format with task IDs and decisions. CHANGELOGCLIENT.md is plain English, grouped by "what you can now do", written like a product update — no task…