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/nirecom/agents/sweep-issuesnpx skills add nirecom/agents --skill sweep-issuesgit clone --depth 1 https://github.com/nirecom/agentsWhat 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.00032 | $0.01058 |
| Opus 5 | $0.00016 | $0.00529 |
| Sonnet 5 | $0.00006 | $0.00212 |
| Haiku 4.5 | $0.00003 | $0.00106 |
Grade A, and why
sweep-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 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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Sweeps the open-issue backlog.
- tier 1 — meta parents whose sub-issues are all closed. Closed on every run.
- tier 2 — issues whose referenced
tests/*.shpaths no longer exist. Listed on every run; closed only under--deep, one at a time with the user's approval.
The user types at most --deep and --dry-run. Passes 2 and 3 are this skill's own calls (SI-5, SI-7) — the user never supplies a TSV path.
Procedure
Read rules/github-issues.md before SI-1 — on-demand-only, never auto-injected; it owns the close paths, the status:migrated / status:cancelled labels, and meta-parent handling.
SI-1. Run bash "$AGENTS_CONFIG_DIR/bin/sweep-issues.sh" forwarding the user's flags verbatim (pass 1).
SI-2. Print stdout verbatim. Do not summarize or filter.
SI-3. Stop here when the output carries no <<<TIER2-GATE-SI3 block.
SI-4. With the block: use AskUserQuestion to separate false positives (artifact not built yet) from real staleness.
Write the survivors to ${WORKFLOW_PLANS_DIR:-$HOME/.workflow-plans}/<session-id>-sweep-issues-survivors.tsv.
Columns: number / tokens_csv / class. Copy columns 1-2 from the gate template rows.
class ∈ resolved | refactored-away | duplicate | obsolete | partial.
SI-5. Re-run with --verify-candidates <survivors.tsv> --deep (pass 2) and print every EVIDENCE- line verbatim.
SI-6. Present the <<<TIER2-GATE-SI5 candidates plus their evidence in one batched AskUserQuestion.
Write only the approved rows to <session-id>-sweep-issues-decisions.tsv.
Columns: number / action / arg / rationale. arg is the surviving issue for migrated, else -.
SI-7. Emit <<WORKFLOW_ISSUE_CLOSE_VERIFIED: sweep-issues batch triage>>, re-run with --decisions <decisions.tsv> --deep (pass 3), then emit <<WORKFLOW_ISSUE_CLOSE_VERIFIED_END: sweep-issues batch triage done>>.
Report every PARTIAL: line verbatim.
Rules
- Applies by default;
--dry-runsuppresses tier-1 closes too. --deepnever changes the write mode, and never widens the candidate set — SI-2 scans identically with and without it. It decides only whether the tier-2 candidates reach the human gate or are dropped after being listed.--verify-candidates/--decisionsare this skill's protocol with the script, not user flags. Never surface them in a suggestion to the user; never expect the user to pass one.- Pass
--deepon every tier-2 call (SI-5 and SI-7); omitting it exits 2. - The flagless run is non-interactive. Never place
AskUserQuestionon the default path. - Pair
--deepwith a small band (e.g.--band-size 20) — SI-5 runs real tests and large bands do not finish in usable time. - Under
--dry-run, SI-5 reports the test it would run instead of running it; running a repository script is an effect. - A pass-1 run exits non-zero when any sub-step failed. Treat a non-zero exit as "this band was not swept", never as "nothing to do".
--repomust name the working tree's own repository; pass--repo-root DIRwhen sweeping a repository checked out elsewhere, or the run aborts.- Close only through the existing helpers. Never call
gh issue closedirectly. - The judgement axis table's SSOT is the header of
bin/sweep-issues/close-batch.sh; it is not restated here. - SI-5 evidence never rests on the issue body's own claims.
- Write both intermediate TSVs outside the repo, under
${WORKFLOW_PLANS_DIR}— in-repo writes are blocked byenforce-worktree.js. - After a run that closed several tier-1 children of one parent, recommend
/issue-reconcile:parent-body-update.shcan lose an update between concurrent closes. - This skill sets no
context: fork, unlike its sweep siblings, because its human gates need the parent conversation.
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 · 50 lines · 32 tokens per session scan A 3a7249b2d34c
sweep-issues is a skill published in the GitHub repository nirecom/agents (3 stars, last pushed 2d ago), licensed MIT. It adds 32 tokens to every session and 1,058 once invoked, about $0.0002 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
babysit
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitorstart / monitorupdate / autonudgestop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use…
teamharness-task-delegation
Use when a Leader turns ready Quick Task or Project Work state into Worker task instructions, sends assignment messages, checks submitted results, and defines completion/blocker report contracts. Do not use to create projects, create rooms, or execute Worker tasks.
github-workflow
Use GitHub workflow tools to read work status, draft reports, summarize follow-ups, and execute only approved issue mutations.
flow-next-tracker-sync
Project a flow-next spec to a tracker issue (Linear, GitHub, GitLab, Jira) and reconcile two-way. Use when asked to sync to a tracker. NOT plan-sync.
codex-session-product-reviewer-maintainer
Use when reviewing a local Codex session, task, thread, or commit as a product manager or first-principles reviewer for product correctness, scope, behavior, validation, and whether the task solved the right user problem.
gsd-executor
Executes GSD plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by execute-phase orchestrator or execute-plan command.