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/phobologic/claude_code_helpers/ticket-triagenpx skills add phobologic/claude_code_helpers --skill ticket-triagegit clone --depth 1 https://github.com/phobologic/claude_code_helpersWrote 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/phobologic/claude_code_helpers/ticket-triage)<a href="https://agentmods.dev/skills/phobologic/claude_code_helpers/ticket-triage"><img src="https://agentmods.dev/badge/skills/phobologic/claude_code_helpers/ticket-triage.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.00068 | $0.01669 |
| Opus 5 | $0.00034 | $0.00834 |
| Sonnet 5 | $0.00014 | $0.00334 |
| Haiku 4.5 | $0.00007 | $0.00167 |
Grade A, and why
ticket-triage 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 3d 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 — 159 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ticket Triage
Use tk triage to filter and sort tickets. Never write inline Python or pipe through
jq for this — tk triage handles multi-key sorting, confidence extraction, and
formatted output in a single safe command.
Phase 1 — Understand the request
Parse $ARGUMENTS for filter and sort intent. Common patterns:
| User says | Flags to use |
|---|---|
| "open P2 tickets" | --priority 2 |
| "bugs first, oldest first" | --sort type,created --type-order bug,task,feature,chore,epic |
| "triage the backlog" | --status open --sort priority,created |
| "tickets in epic X" | --epic <id> |
| "sort by confidence" | --sort confidence |
| "bugs and tasks only" | --type bug,task |
| "top 10" | --limit 10 |
Default sort is type,created (bugs first by type order, then oldest first within each type).
Phase 2 — Run the triage query
Run tk triage with the appropriate flags. Start with table output for orientation:
tk triage [--status STATUS] [--priority N] [--type TYPE] [--epic ID] [--tag TAG]
[--sort FIELDS] [--limit N]
If you need ticket body content for deeper analysis (e.g., to evaluate relevance or
read acceptance criteria), re-run with --json --full:
tk triage --json --full [same filters]
This returns structured JSON including the full ticket body — use it when you need to reason about ticket content, not just metadata.
Phase 3 — Present
Render results in a consistent layout. Scale the layout to the size of the result set — a 3-ticket triage doesn't need a cross-tab.
Standard layout
Epic: [<id>] <title> (or "All open tickets" if no --epic filter)
Count by priority × type:
bug task feat chore epic │ total
P0 2 0 0 0 0 │ 2
P1 1 3 1 0 0 │ 5
...
Signals:
- N tickets total, X blocked by deps, Y blocking others
- Oldest: <date> (<age>d) — [<id>] <title>
- Z tickets missing Acceptance Criteria: [<id>], [<id>]
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.
- 3d ago First seen · 159 lines · 68 tokens per session scan A 8c394c5dced3
ticket-triage is a skill published in the GitHub repository phobologic/claude_code_helpers (5 stars, last pushed 1mo ago), licensed MIT. It adds 68 tokens to every session and 1,669 once invoked, about $0.0003 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
wayfinder
Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
sap-transport-overview
System-wide inventory of open transport requests — every visible modifiable request, who owns it, how big it is, and supported risk signals such as empty/local requests, explicit locks, and confirmed manifest overlaps. Headers-only and cheap; NO source diffs. Use when asked "what transports are open in the system"…
timeline-creator
Create HTML timelines and project roadmaps with Gantt charts, milestones, phase groupings, and progress indicators. Use when users request timelines, roadmaps, Gantt charts, project schedules, or milestone visualizations.
pm-all
Skill "pm-all" from wei63w/pm-manager, covering user input, outline and shared workflow (all /pm- commands).
bootstrap-prd
Set up PRD-driven development infrastructure for a new project, including directory structure, templates, and roadmap.
finn-spec
Interview the user about a raw idea until confident, then file a build-ready issue in Linear. Use when asked to run Finn-loop's spec interview, draft a queue-ready issue, or plan a feature. Interactive — requires the user present; never run unattended.