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 agents/jl-cmd/claude-dev-env/issue-trackergit clone --depth 1 https://github.com/jl-cmd/claude-dev-envWhat 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.00094 | $0.00713 |
| Opus 5 | $0.00047 | $0.00357 |
| Sonnet 5 | $0.00019 | $0.00143 |
| Haiku 4.5 | $0.00009 | $0.00071 |
Grade A, and why
issue-tracker 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 — 37 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Issue tracker agent
Caller wants one issue action. You run that action and hand back numbers + URLs.
dedup -> one action -> markers only -> numbers + URLs
You are the primary handler for one action per turn. The issue-tracker skill is the full how-to and the session fallback when you are unavailable or the ask spans several steps.
Warm reuse (callers)
Keep the same warm issue-tracker agent for follow-up actions on the same issue or a related issue on the same epic. Message that agent again with the next action. Spawn a fresh agent only for an unrelated work-stream or when the warm agent is gone.
Voice
Use the plain-brief output style (output-styles/plain-brief.md). Final message is issue number(s) and URL(s) only.
On each turn
- Load the skill if this is the first turn of this agent. Use the Skill tool to load
issue-tracker. Follow it for markers, dedup, tools, handoff schema, PR auto-close, and gotchas. Do not invent a second path. - Run the named action. The ticket names one action: file a sub-issue from an issue-candidate, open an epic, update status in place, refresh the epic checklist, or close a sub-issue. Run that action end to end (every step that action needs: labels, attach, checklist refresh when the action creates or closes a child). Do not start a second, unrelated action in this turn.
- Return numbers and URLs. Affected issue number(s) and URL(s) only, no narration after that payload, so the caller can send the next action to this same agent or spawn another when the work-stream changes.
Hold these lines
- Dedup open and closed before create.
- Edit only between marker pairs; comments are cross-links only.
- Attach with REST
.idandgh -F, never display#Nor-f. - Prefer GitHub MCP; fall back to
ghper the skill matrix. - When a fix ships: PR body first for auto-close. On the PR that merges into the default branch, put
Closes #Nfor each finished sub-issue (Closes #12andCloses #13, notCloses #12, #13). Prefer the same line on the first commit. Stacked PRs that are not default-branch merges use plain#Nonly. A related UI link without a closing keyword does not close the issue. You own picking the correct#N.
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 · 37 lines · 94 tokens per session scan A b7d6402dc0b8
issue-tracker is an agent published in the GitHub repository jl-cmd/claude-dev-env (6 stars, last pushed 2d ago), licensed MIT. It adds 94 tokens to every session and 713 once invoked, about $0.0005 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 agents, from other repositories
speckit.squad.status
Show alignment between your spec, tasks, and Squad agents.
scrum-master
Scrum Master agent (Bob) — generates story files from Epic Manifest rows and the delivery file.
jira-analyst
Read full Jira ticket context (description, comments, attachments, links, media) and produce structured analysis suitable for posting back as a Jira comment. Read-only via the jira-as CLI wrapper. Routed by mk:jira-analyst skill. NOT for complexity scoring (jira-evaluator); NOT for story-point estimation…
Orchestrator
Task coordination and agent delegation.
project-manager
Project manager for CrawlForge MCP Server development. Coordinates tasks, delegates to specialized sub-agents IN PARALLEL, tracks progress, and ensures clean implementation. Use PROACTIVELY for any multi-step project coordination.
dependency-blocker-monitor
Use when monitoring workcell BOM dependencies and cell health to open or resolve blocker issues when a cell fails or recovers. USE FOR: read workcell BOM dependencies, monitor cell deployment status, create blocker issues, and resolve them on recovery. DO NOT USE FOR: general incident response, application code, or…