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 markmhendrickson/neotoma --skill process_issuesgit clone --depth 1 https://github.com/markmhendrickson/neotomaWrote 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/markmhendrickson/neotoma/process_issues)<a href="https://agentmods.dev/skills/markmhendrickson/neotoma/process_issues"><img src="https://agentmods.dev/badge/skills/markmhendrickson/neotoma/process_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/markmhendrickson/neotoma/process_issues"><img src="https://agentmods.dev/badge/skills/markmhendrickson/neotoma/process_issues.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Agent Snooping · line 6 Skill enumerates or reads other installed skills. Access to other skills' SKILL.md files or the skills directory reveals prompt instructions, capabilities, and secrets that should be invisible to peer skills.Fix: Remove all code or instructions that list or read other skills' files or directories. Skills should operate independently; cross-skill access is a privilege escalation.
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.00006 | $0.01287 |
| Opus 5.5 | $0.00002 | $0.00515 |
| Sonnet 5.5 | $0.00001 | $0.00257 |
| Haiku 4.5 | $0.00001 | $0.00129 |
Grade A, and why
process_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 1mo 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.
Copies of this mod
1 near-identical copy found in the catalogue:
- process-issues — 97% identical, 14 lines differ
How it starts
The opening of the file, as written. The whole thing — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Process Issues
Use this skill to work the Neotoma issue queue end-to-end.
For each open issue, the skill should create or update one or more plan entities, then do one of three things:
- Open a PR for a public-release reproduction.
- Create a local worktree for a local commit or branch reproduction.
- Post an
add_issue_messageasking for missing context when the reproduction environment is unclear. - Close any clearly test-only issues that the queue surfaces.
- Open a related GitHub security advisory when the issue is a security issue.
Workflow
- Discover open issues with
neotoma issues list --state open(or the current CLI equivalent when the flag shape differs). - Honor reporting mode before any execution:
off-> generate and store plans onlyconsent-> ask before executing a per-issue planproactive-> execute safe plans autonomously
- Filter queue artifacts before reproduction work:
- Exclude open PRs or PR URLs accidentally surfaced by the queue command; do not route them through the issue workflow.
- Identify clearly test-only issues using queue context such as labels like
test,test-flow,test-cleanup, orlive-issues-tooling, and titles/descriptions that indicate sample/live/public test issues rather than product bugs. - For each test-only issue, create or update a cleanup
planentity, then honor reporting mode:off-> store the cleanup plan onlyconsent-> ask before closingproactive-> close the issue immediately with a brief cleanup comment
- Report closed test issues in the final aggregate output.
- Spawn parallel subagents with a default concurrency cap of 4, one non-test issue per subagent.
- Per issue:
- Load the issue snapshot, conversation thread, and any reporter environment fields.
- Classify the reproduction environment as
public_release,local_commit,local_branch, orunknown. - Classify whether the issue is a security issue based on labels, title/body, affected surface, or prior issue/advisory context.
- If the environment is missing, conflicting, or still unreproducible, call
add_issue_messagewith a structured request for the missing detail and mark the planawaiting_input. - Otherwise, synthesize and store a
planentity linked to the sourceissueand relevantconversation_messagerows. - If the issue is a security issue, create a related GitHub security advisory before publishing other public artifacts:
- Reuse an existing related advisory when one already exists.
- Otherwise open a new draft advisory with a minimal, redacted summary, affected versions/surfaces, reproduction notes, and mitigation status.
- Record the advisory URL or identifier in the plan and include it in the final aggregate report.
- If the plan touches schema, security, foundation docs, or an ambiguous architectural boundary, stop and ask instead of executing.
- If execution is safe and allowed by reporting mode:
public_release-> branch frommain, implement and test the change, then open a PR. Public issues may includeFixes #<github_number>; private issues must use neutral wording with no private identifiers.local_commitorlocal_branch-> create a detached git worktree, initialize it, implement and test the change there, then report theworktree_path.
- Aggregate subagent outcomes and report created plans, closed test issues, advisories, worktrees, PRs, and outstanding information requests.
- Summarize comprehensively for the user after each
/process-issuesrun:- Include the set of issues reviewed in the run.
- For each issue, state the current status, classification, and the concrete action taken so far.
- For security issues, state whether a related advisory was created, reused, or is still blocked.
- Call out any blocker, missing context, or user decision needed to make more forward progress.
- Separate "completed / no further action needed now" issues from "still active / blocked" issues.
- End with a concise "What I need from you" section when any issue requires user input, branch guidance, reproduction detail, environment confirmation, or prioritization.
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.
- 1mo ago First seen · 88 lines · 6 tokens per session scan A f8c500cd4e6d
process_issues is a skill published in the GitHub repository markmhendrickson/neotoma (34 stars, last pushed yesterday), licensed MIT. It adds 6 tokens to every session and 1,287 once invoked, about $0.0000 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-08-30.
Other skills, from other repositories
systemic-issue-triage
Trigger: new issue, bug report, triage, backlog, issue flood, community report, root cause, dead-end, blocked user. Attack issues by root class, never one-by-one; fixes must shrink the system, not grow it.
triage-issue-reports
Triage Slack issue reports with one thread-only verdict, evidence review, cause-aware routing, tracker dedupe, and fail-closed ticket creation. Use only from the configured Benny triage automation.
bernstein-plan
Create and manage multi-step execution plans in Bernstein. Plans decompose complex goals into stages with dependencies. Use when the user wants to plan a complex feature, break down a large task, or review an execution plan before agents start working.
browse-flows
Browse Power Automate environments and flows interactively. Use when the user wants to browse, list, or explore their flows and environments.
ci-fixer
CI failures - read error, minimal fix, verify.
factory-triage
Triage a Factory work item's issue — trace history, understand architecture, diagnose root cause, then advance the stage.