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 jerseycheese/agent-skills --skill issue-maintenancegit clone --depth 1 https://github.com/jerseycheese/agent-skillsWrote 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/jerseycheese/agent-skills/issue-maintenance)<a href="https://agentmods.dev/skills/jerseycheese/agent-skills/issue-maintenance"><img src="https://agentmods.dev/badge/skills/jerseycheese/agent-skills/issue-maintenance/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/jerseycheese/agent-skills/issue-maintenance"><img src="https://agentmods.dev/badge/skills/jerseycheese/agent-skills/issue-maintenance.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.00277 | $0.04944 |
| Opus 5 | $0.00138 | $0.02472 |
| Sonnet 5 | $0.00055 | $0.00989 |
| Haiku 4.5 | $0.00028 | $0.00494 |
Grade A, and why
issue-maintenance 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 — 309 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Issue Maintenance
prioritize-issues reports; analyze-issue specs out one issue for implementation. This skill
maintains — it mutates the backlog: labels, priority, and issue text. Four passes, one report.
0. Prerequisites
ghauthenticated for the target repo. Ifghisn't installed (some hosted/cloud sessions), every step below has a GitHub MCP equivalent (mcp__github__list_issues,issue_read,issue_write,get_label) — same data, different transport. Say which you used in the report.- No repo clone. Everything here is issue metadata (title, body, comments, labels) via
gh issue— skip themktemp -d/gh repo clonestep entirely, unlikecode-health-audit's andplain-language-audit's scheduled pattern. This skill never touches source files. The one exception is the label-convention doc in §4b, which is a single API file read, not a clone.
1. Discover the repo
gh repo view --json nameWithOwner -q .nameWithOwner # if not specified
2. Fetch the backlog and the real label set
gh issue list --state open --limit 200 --json number,title,labels,createdAt,updatedAt,body,milestone,comments
gh label list
Paginate past 200. Cache the label list — every --add-label below must come from it verbatim.
Never invent a label. If a label this workflow wants (needs-repro, needs-info, duplicate,
any priority:*) doesn't exist in this repo, skip that operation for the whole run and say so
once in the report ("not configured in this repo") — don't repeat the note per issue.
2b. Establish how this repo types its issues
Pass 2 groups label coverage by issue type, so the run needs to know what a "type" is here before it can group anything. Two mechanisms exist and repos use one or the other:
- GitHub native issue types (Bug / Feature / Task and custom ones). There is no
gh issue typesubcommand — sincegh2.94.0 issue types ride on the ordinary commands (--typeon create/edit, a type field onlist/view), and before that they were reachable only through the API. Detect them withgh api repos/{owner}/{repo}/issue-typesormcp__github__list_issue_types. A 404 means this repo has none, which is the ordinary answer for a personal-account repo — issue types are configured at organization level. If the repo does have them, that is the typing mechanism: fetch the type per issue in the §2 bulk call. - A type label convention —
epic,bug,enhancement,user-story,documentation, and so on. The convention doc from §4b usually names these outright (Narraitor's.github/labels.mdhas a## Type Labelssection listing exactly six). Use that list as the type mapping rather than inventing one from whatever labels happen to look type-ish.
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 · 309 lines · 277 tokens per session scan A c9be1f2a77e4
issue-maintenance is a skill published in the GitHub repository jerseycheese/agent-skills (1 stars, last pushed 6d ago), licensed MIT. It adds 277 tokens to every session and 4,944 once invoked, about $0.0014 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
lov-gh-tidy
Interactive GitHub repo hygiene skill. Lists all open issues, PRs, stale branches, and orphan labels, shows a summary of each with analysis, then asks the user how to handle each item (close, merge, comment, delete, keep). Executes all chosen actions via gh CLI. Use when the user says "清理 GitHub", "tidy repo", "clean…
multica-goal-tracker
Track goal-driven Multica issues. Use when a user creates or maintains Multica issues by pasting a /goal prompt, wants Codex to summarize that goal into a concise issue purpose, append a normalized goal-start comment, record completion evidence from real Multica execution run messages or a supplied session transcript…
cross-campaign
Discover and reference other camps, projects, and files across camp boundaries. Use when the user mentions another camp or campaign by name, references work done "in another project/camp", or needs to find/copy/compare code across camps.
fest-execution
Execute active festival tasks. Use when finding the next task, marking tasks completed/blocked/reset, committing with festival traceability, advancing workflow steps, and validating sequence progress.
fest-planning
Plan and scaffold festivals. Use when creating festival/phase/sequence/task structure, enforcing naming rules, linking festivals to projects, and promoting lifecycle states.
camp-workitems
Find, filter, choose, create, or adopt camp work items with camp workitem, camp wi, or camp workitems. Use when a user wants current active work across intents, designs, explore notes, festivals, or tracked workflow directories; when agents need safe camp workitem --json output; or when creating/adopting tracked…