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/dppdppd/rpm/backlognpx skills add dppdppd/rpm --skill backloggit clone --depth 1 https://github.com/dppdppd/rpmWhat 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.00156 | $0.02882 |
| Opus 5 | $0.00078 | $0.01441 |
| Sonnet 5 | $0.00031 | $0.00576 |
| Haiku 4.5 | $0.00016 | $0.00288 |
Grade A, and why
backlog 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 2d 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 — 256 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/backlog
Manage the rpm backlog — persisted at docs/rpm/future/tasks.org.
All operations read and write this file using org-mode format.
Project Amendments
At the start of every invocation, check whether
docs/rpm/skills/backlog.md exists in the consuming project. If it
does, read it and apply its contents as additional project-specific
instructions for this skill. Amendments may add band orderings,
extra parent groups, or custom triage rules. They cannot remove or
override plugin defaults — on conflict, this SKILL.md wins.
The backlog is sorted in execution order (top-to-bottom = the order in which tasks need to get done). "Take from the top" is the expected read pattern.
Within each * Parent group, keep this band order top-to-bottom:
- Actionable —
** IN-PROGRESSor** TODOwith all:BLOCKED_BY:deps DONE - Blocked —
** BLOCKED, or** TODOwith unresolved:BLOCKED_BY: - Postponed —
** TODOwith a:POSTPONED:stamp
Closed entries (** DONE / ** CANCELLED) are archived to
docs/rpm/future/done.org by /session-end and do not live in
tasks.org long-term. /backlog done toggles TODO → DONE in place;
the archive sweep runs at the next session-end.
Blocked and postponed items drift to the bottom of their band
automatically whenever this file is written (during add,
postpone, review, or session-end Phase 3b). Moves are mechanical
— no user question. Preserve relative order within each band.
New add entries land at the bottom of the actionable band
(not the absolute bottom); user promotes upward explicitly if
something needs to happen sooner.
Pivot capture (automatic, no user question). When the user
redirects mid-session to new multi-step work that meets the
TaskCreate bar, the LLM must insert a ** TODO at the top of
the actionable band AND update docs/rpm/~rpm-session-start to set
the task: field to the new work. The ask IS the confirmation —
don't prompt. Skip for tactical single-step follow-ups. Rationale:
the backlog should always represent current state, so a dropped
session (without /session-end) still hands off accurately. Full
rule lives in plugin/hooks/_directives.sh.
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.
- 2d ago First seen · 256 lines · 156 tokens per session scan A fae44255a37e
backlog is a skill published in the GitHub repository dppdppd/rpm (3 stars, last pushed 4d ago), licensed MIT. It adds 156 tokens to every session and 2,882 once invoked, about $0.0008 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
vobiz-audio-streams
Stream live call audio bidirectionally over WebSocket for AI voice agents, real-time transcription, and custom audio pipelines.
vobiz-partner-api
Vobiz Partner / reseller API - create customer sub-accounts, transfer balance, run KYC sessions (PAN+Aadhaar OTP, no documents), and query per-customer CDRs/transactions/numbers.
vobiz-plivo-migration
Migrate a Plivo voice integration to Vobiz - swap the client/auth and base URL, rename one XML verb, update the webhook signature header, and provision new Vobiz numbers (Plivo numbers cannot be ported). Plivo and Vobiz are near 1:1, so prefer minimal diffs.
vobiz-sub-accounts
Manage Vobiz sub-accounts for multi-team or multi-environment isolation - separate billing, credentials, and number pools under one parent account, including per-sub-account India KYC (PAN, GST, CIN, DigiLocker) and hosted KYC sessions.
vobiz-cdr
Query Vobiz Call Detail Records - list, search, retrieve by callid, fetch recent, and export CSV. 43 fields per CDR including quality metrics (MOS, jitter, packet loss) and hangup attribution.
vobiz-sip-trunking
Manage Vobiz SIP trunks, IP ACLs, SIP credentials, and origination URIs for BYOC and outbound routing.