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 skills add lbk-open/super-spec --skill ss-multi-repo-workflowgit 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-multi-repo-workflow)<a href="https://agentmods.dev/skills/lbk-open/super-spec/ss-multi-repo-workflow"><img src="https://agentmods.dev/badge/skills/lbk-open/super-spec/ss-multi-repo-workflow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/lbk-open/super-spec/ss-multi-repo-workflow"><img src="https://agentmods.dev/badge/skills/lbk-open/super-spec/ss-multi-repo-workflow.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00087 | $0.04393 |
| Opus 5 | $0.00044 | $0.02197 |
| Sonnet 5 | $0.00017 | $0.00879 |
| Haiku 4.5 | $0.00009 | $0.00439 |
Grade A, and why
ss-multi-repo-workflow 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 8d 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 — 278 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Multi-Repo Workflow
Executes a requirement that spans multiple git repositories: plan once, then run one
repository-scoped execution unit per repository (each running ss-coding-workflow from that
repo's real working root), batched by dependency order, and finally consolidate all pull requests
into one cross-repo report.
Why repository runners. Every unit must start with the target repository as its real working root so it loads that repo's own project instructions, specs, skills, and git state. Use a native child runner only when the host can guarantee an independent absolute working directory, fresh repository context, nested implementation/review delegation, observable lifecycle, and exact run identity. Otherwise use a fresh headless process. Extra file access without repository-scoped context is not sufficient.
Orchestrator (this session)
├── in repo-a: run ss-coding-workflow <plan-a>, autonomous, lite/full ┐ batch 1 (parallel)
├── in repo-b: run ss-coding-workflow <plan-b>, autonomous, lite/full ┘
└── in repo-c: run ss-coding-workflow <plan-c>, autonomous, lite/full batch 2 (after batch 1)
Core principle: thin orchestration. This skill never writes code or edits source/configuration
inside target repositories. Its only target-repository write is distributing the generated
sub-plan artifact before execution. Planning-stage work is delegated to other ss-* skills in
this session; execution-stage work is delegated to per-repo runners.
When to Run
Only run this when the user explicitly asks for it, or a single-repo workflow hands off to it
after multi-repo detection (see ../ss-references/multi-repo-detection.md). Do not auto-trigger it
for ordinary single-repo work.
Inputs
- Planning input, one of:
- a path to an existing master plan (see "Input Type Detection"), or
- a requirement/PRD link, issue link, or plain-text requirement — triggers the planning stage first.
- Delivery mode —
full(default) orlite, forwarded to every per-reposs-coding-workflowinvocation. Seess-coding-workflow's "Delivery Mode" section; the choice is made once here and applied uniformly across repos. - Skip-gates — skip the manual multi-repo execution gate.
- Decide-autonomously — resolve clarification questions without pausing; also forwarded to the planning-stage skills.
- Runner adapter —
auto(default),native child, orheadless process.autoselects a native child only when all readiness guarantees in this skill can be proven; otherwise it uses a headless process. Never treat mere access to another directory as repository-scoped context. - Allow unattended edits (optional, default off) — authorize the selected runner's unattended edit mode in trusted environments only.
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.
- 8d ago First seen · 278 lines · 87 tokens per session scan A 600e2553d89f
ss-multi-repo-workflow is a skill published in the GitHub repository lbk-open/super-spec (1 stars, last pushed 17d ago), licensed Apache-2.0. It adds 87 tokens to every session and 4,393 once invoked, about $0.0004 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.
catchup
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
phx-pr-review
Address feedback left on a GitHub pull request: fetch unresolved review threads, make agreed Elixir/Phoenix code fixes, reply, and resolve. Use for a PR URL/number or reviewer comments. NOT for pre-PR review, findings triage, or CI monitoring.
watch-pr
Watch an Elixir/Phoenix PR with an Amp Orb keep-alive lease until required non-deployment CI is green and review threads are resolved. Use after opening or updating a PR.
056-design-avoid-breaking-changes
Use when you need to review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk across commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance. This should trigger for requests such as Review…