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/dryvist/claude-code-plugins/track-followupsnpx skills add dryvist/claude-code-plugins --skill track-followupsgit clone --depth 1 https://github.com/dryvist/claude-code-pluginsWrote 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/dryvist/claude-code-plugins/track-followups)<a href="https://agentmods.dev/skills/dryvist/claude-code-plugins/track-followups"><img src="https://agentmods.dev/badge/skills/dryvist/claude-code-plugins/track-followups.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.00085 | $0.01179 |
| Opus 5 | $0.00043 | $0.00589 |
| Sonnet 5 | $0.00017 | $0.00236 |
| Haiku 4.5 | $0.00009 | $0.00118 |
Grade A, and why
track-followups 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 — 115 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Track Follow-Ups
Given follow-up items that have already been triaged, put each one where it will be seen again. A listed follow-up is not a tracked follow-up. This skill creates the item and reports back what it created.
It owns the routing and the creation mechanics. Callers own the triage.
Routing
| Kind of item | Destination | Why |
|---|---|---|
| Work to be done — defects, features, chores, tech debt, side quests | Your issue tracker (Vikunja) | It is a task; it belongs on the board with everything else |
| Incidents — outages, anomalies, RCA-worthy events, security findings, weaknesses | The incident system of record (Zammad) | Incidents need a lifecycle, an audit trail, and a place that is not public |
| Small enough to finish next session (roughly 1–3 tasks) | The next-session prompt | Tracking it would be overhead; it is about to be done |
GitHub issues are never created
Public GitHub carries pull requests only. Never open a GitHub issue, and never put an incident narrative, security finding, credential detail, internal hostname, topology, or outage timeline in any GitHub issue, PR body, comment, or commit message. "It is only a side quest" is not an exemption — that reasoning is exactly how operational detail reaches a public repository.
An item that is both an incident and a code fix gets split: an incident ticket and a tracker task, each carrying the other's URL in its description. Cross-linking is a plain URL each way; there is no integration to configure.
Procedure
1. Confirm the tooling is there
Check for mcp__vikunja__* and mcp__zammad__* before anything else. Nothing
available for a given destination means this skill falls back to listing those
items and says so in one line — it does not silently drop them, and it does not
guess an identifier, project, or ticket number.
2. Deduplicate before creating
Search the destination for an existing open item covering the same thing.
tracker: mcp__vikunja__vikunja_tasks { subcommand: "list", allProjects: true,
search: "<distinctive phrase>", filter: "done = false" }
incidents: mcp__zammad__zammad_search_tickets
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 · 115 lines · 85 tokens per session scan A dc35b0950fbb
track-followups is a skill published in the GitHub repository dryvist/claude-code-plugins (3 stars, last pushed yesterday), licensed Apache-2.0. It adds 85 tokens to every session and 1,179 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
triage-sweep
Backfill labels across oh-my-hermes issues and pull requests. Run manually to sweep everything currently unlabeled, or pass a number to triage one item. Use when issues and PRs have accumulated without labels, after adding a new label to .github/labels.yml, or before a release when the backlog needs to be readable by…
implement
End-to-end workflow for taking MCP work items from backlog to merged PR. Handles git branching, schema-driven planning, implementation, independent review, and PR creation. Composes spec-quality, review-quality, and schema-workflow skills into a single pipeline. Use when a user says "implement this", "work on this…
work-summary
Generates a project dashboard from MCP work items. Default is a lean, attention-first view: what's in flight, what's blocked, what to do next, what's queued. Use when the user says: project status, what's active, show me the dashboard, work summary, what should I work on, project health, what's blocked, where did I…
feature-implementation
Guides the full lifecycle of a feature-implementation tagged MCP item (the feature container) — from queue through review. Creates or resumes the feature container, fills gate-enforced notes at each phase (feature-summary, implementation-notes, session-tracking, review-checklist), dispatches implementation subagents…
jira-administration
Complete JIRA project and system administration including projects, automation rules, permissions, users, notifications, screens, issue types, and workflows. Use when managing project structure, automating work, configuring team access, or setting up issue tracking.
jira-operations
JIRA cache and performance operations. TRIGGERS: 'warm the cache', 'warm cache', 'cache status', 'clear cache', 'cache warm', 'cache for project', 'discover project', 'project discovery', 'cache hit rate', 'optimize performance', 'rate limit'. Use for JIRA API performance optimization and project context discovery.…