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 aj604/toolshed --skill orchestrate-issuesgit clone --depth 1 https://github.com/aj604/toolshedWrote 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/aj604/toolshed/orchestrate-issues)<a href="https://agentmods.dev/skills/aj604/toolshed/orchestrate-issues"><img src="https://agentmods.dev/badge/skills/aj604/toolshed/orchestrate-issues/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/aj604/toolshed/orchestrate-issues"><img src="https://agentmods.dev/badge/skills/aj604/toolshed/orchestrate-issues.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.00209 | $0.09516 |
| Opus 5.5 | $0.00084 | $0.03806 |
| Sonnet 5.5 | $0.00042 | $0.01903 |
| Haiku 4.5 | $0.00021 | $0.00952 |
Grade A, and why
orchestrate-issues 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 today.
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 — 702 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Orchestrating an issue graph with subagents
You are the loop, not the labour. Your job is to keep the frontier moving: find what's unblocked, dispatch someone to build it, get it reviewed, land it, and let the merge open the next edge. You do this until the graph is done, a lane needs a human, or the graph proves it can't finish.
The one rule: you never implement
Not one edit to a source file. Not "this one's tiny." Every issue goes to a subagent, including the trivial ones.
This isn't ceremony — it's what makes the loop survive:
- Your context has to outlast the whole graph. An implementer spends 100k tokens reading and rewriting files and then exits; that's the entire point of it being a subagent. If you spend that context yourself you can't exit — you are the loop. Three nodes in you get compacted, and a compacted orchestrator has forgotten which lanes are in flight and which PRs it was about to merge.
- You're sitting in the wrong tree. Implementers get isolated git worktrees so parallel lanes can't collide. The checkout you're in is not one of them. Edits you make there are invisible to every implementer and will fight the merges you're about to do.
The pull to "just fix this one small thing" is strongest right after a reviewer reports a one-line problem. Dispatch a fixer anyway. Which fixer, and why not the agent that wrote the code, is the next rule.
The second rule: one agent, one job
Every agent you dispatch does exactly one bounded thing and exits. Check the premises. Or implement and open the PR. Or review the diff. Or fix the findings. Never two of those, and never the same job twice.
So when review comes back CHANGES_REQUIRED you dispatch a fresh fixer. You
don't wake the implementer with SendMessage, and you don't send the re-review
to the reviewer that wrote the findings.
That is the opposite of the obvious move — the implementer still has the worktree and the reasoning, so reusing it looks free. It isn't:
What ships with it
4 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.
- today First seen · 702 lines · 209 tokens per session scan A 2f8434e4355e
orchestrate-issues is a skill published in the GitHub repository aj604/toolshed (1 stars, last pushed today), licensed MIT. It adds 209 tokens to every session and 9,516 once invoked, about $0.0008 per session on Opus 5.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-10-19.
Other skills, from other repositories
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.
continue
Autonomous work — find and execute ready tasks.
pr
A command for managing pull requests on GitHub or Bitbucket Server. A pull request is a request for other developers to review and merge changes into a project branch.
github-issue-triage
A GitHub issue organiser for open problems and requests in a software project. GitHub is a service where teams store code and track issues.
team-dev
A workflow for splitting a software task into smaller jobs and assigning independent jobs to coding agents working in separate Git worktrees. A worktree is an isolated working folder connected to the same Git repository.
start-task
Bootstrap a task into a synced feature branch — one shot, zero confirmations. Detects the source from the args: GitHub issue ('#100', 'issue 100', 'gh issue 100', or bare '100'), Jira key ('PROJ-42'), or a local spec file path; ad-hoc conversation otherwise. Fetches the task, derives {type}/{number}/{slug}, syncs the…