From devkit
This skill should be used when the user asks to "triage RT tickets", "triage the queue", "RT triage", "check RT queue", "find actionable tickets", "what tickets need attention", "which tickets are code-related", "review the support queue", "what tickets are waiting on us", "triage my tickets", "triage tickets owned by X", or mentions triaging, reviewing, or analyzing tickets from a Request Tracker (RT) queue against a codebase.
How this skill is triggered — by the user, by Claude, or both
Slash command
/devkit:rt-triageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyze tickets from a Request Tracker (RT) queue to identify which open/new tickets — where the last reply is from the client — are directly related to the current codebase and could be resolved through code changes or inspection.
Analyze tickets from a Request Tracker (RT) queue to identify which open/new tickets — where the last reply is from the client — are directly related to the current codebase and could be resolved through code changes or inspection.
$ARGUMENTS is parsed as positional and named parts:
owner=<name> (optional) — restrict results to tickets owned by a specific user. When set to me, resolve to the current user via rt_get_current_user. When omitted, no owner filter is applied. Natural language like "my tickets" or "triage my queue" should be interpreted as owner=me.Examples: General, General owner=john, General owner=me.
rt_). The server's instructions provide the RT web UI base URL ({rt_web_url}) used to build ticket links in the report.Parse $ARGUMENTS to extract the queue name and the optional owner=<name> parameter.
Call rt_get_current_user to obtain the current username — needed to identify staff correspondence in Step 2.
owner=me was specified, this call must complete before the search so the resolved username can be included in the query. Do not parallelize in this case.rt_get_current_user in parallel with rt_search_tickets.Search for actionable tickets using rt_search_tickets:
Queue = '{queue}' AND (Status = 'new' OR Status = 'open')
If an owner was specified, append AND Owner = '{owner}' to the query (with me already resolved to the actual username).
Request fields=Subject,Status,Queue,Owner,Requestor,Priority,LastUpdated,Due and subfields={"Queue":"Name","Owner":"Name"}.
If no tickets are returned and the queue is known to have active tickets, the RT instance may use a custom lifecycle with different status names. In that case, broaden the query to Status != 'resolved' AND Status != 'rejected' and retry.
If still no tickets are returned, report that there are no actionable tickets in queue {queue} and stop. If an owner filter was applied, mention it in the message so the user knows the filter may be narrowing results to zero.
For each ticket, retrieve correspondence history with rt_get_ticket_history. Always include fields=Type,Creator,Created to get transaction metadata in a single call — omitting fields forces a wasteful second round-trip.
Issue all history calls in parallel.
A ticket needs action when:
Determine this by:
Collect only the filtered tickets that need action. Do not begin fetching transaction content yet — Step 3 applies an additional filter first.
Before fetching full ticket content, classify tickets by subject line alone. Tickets that are obviously Not Code-Related from the subject (access requests, GitLab/VPN accounts, infrastructure, documentation updates) should be classified immediately without fetching transaction content or searching the codebase. This avoids wasting tokens on irrelevant tickets.
Since subject classification requires no tool calls, execute both tasks in a single turn: classify subjects locally, then immediately issue rt_get_transaction calls (creation transaction + last correspondence) for tickets that pass the filter. Issue all calls in parallel.
Handle large attachments: When an MCP tool result exceeds the context window, the framework writes it to a temporary file and returns the file path instead. RT tickets often trigger this due to inline screenshots encoded as base64 images. To extract only the text content from an overflow file, use Bash:
# .[0].text is a JSON-encoded string containing the full transaction object;
# the second jq parses that string to extract only the HTML attachment content.
jq -r '.[0].text' <overflow_file> | jq -r '.Attachments[] | select(.ContentType == "text/html") | .Content'
If the HTML itself is still too large (embedded base64 images), pipe through sed 's/<img[^>]*>//g' to strip image tags before reading.
Spawn one Explore subagent per ticket to search the codebase in parallel. This keeps search results out of the main context and allows each ticket's analysis to proceed independently with multiple search rounds.
When to use subagents: Always use subagents when 3 or more tickets need codebase analysis. For 1-2 tickets, use direct Grep/Glob calls instead.
Subagent prompt template — provide each agent with:
Analyze RT ticket #{id} ("{subject}") against this codebase to classify it.
Ticket content:
{conversation_summary — stripped of base64/images}
Classification categories:
- Code Fix: bug or error likely fixable by modifying code in this repository
- Code Investigation: requires inspecting code to diagnose or understand behavior
- Not Code-Related: infrastructure, access, documentation, third-party services
- Unclear: not enough information to determine relevance
Search strategy:
- Extract key terms: error messages, feature names, module names, URLs, API endpoints, model/class names, function names.
- Use Grep and Glob to search the working directory.
- Look for references to specific files, views, templates, or configuration mentioned in the ticket.
- Cast a wide net first, then narrow down. Try multiple search strategies if the first yields no results.
- When uncertain between Code Fix and Code Investigation, prefer Code Investigation.
Return EXACTLY this format:
Category: {category}
Summary: {one-line summary referencing specific files/modules found}
Relevant files: {comma-separated list of key files, or "none"}
Launch all subagents in a single message so they run concurrently. Set thoroughness to "medium" (controls how many search rounds each subagent attempts before returning).
Collect subagent results and combine with any tickets pre-classified in Step 3. Present results in this format (ticket IDs must link to the RT web UI):
RT Triage Report — Queue: `{queue_name}`
Owner filter: {owner_name or "all"}
Repository: {current working directory}
Date: {YYYY-MM-DD}
Tickets analyzed: {count} | Actionable (code-related): {count}
## Code Fix
- [#{id}]({rt_web_url}/Ticket/Display.html?id={id}): {subject} — {one-line summary referencing specific files/modules found}
## Code Investigation
- [#{id}]({rt_web_url}/Ticket/Display.html?id={id}): {subject} — {one-line summary of what to investigate and where}
## Not Code-Related
- [#{id}]({rt_web_url}/Ticket/Display.html?id={id}): {subject} — {brief reason}
## Unclear
- [#{id}]({rt_web_url}/Ticket/Display.html?id={id}): {subject} — {what information is missing}
Omit empty categories from the report.
get_ticket_history without fields=Type,Creator,Created. Never call get_transaction for tickets already classified as Not Code-Related.For a complete sample report, see examples/sample-report.md.
npx claudepluginhub dipcode-software/agents-marketplace --plugin devkitMoves issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.
Triages project issues through a state machine with category and state roles. Use when creating issues, reviewing bugs/feature requests, preparing issues for AFK agents, or managing issue workflow.
Triages issues through a state machine with category and state roles. Helps manage bug reports, feature requests, and prepare issues for AFK agents.