Owner Routing Process

Step-by-step procedure for determining the most likely owner/team for each bug cluster using strict 6-level precedence with staleness detection and override memory.

Instructions

Step 1: Check Overrides First

For each cluster, check if a routing_override exists from a prior run:

• If found: use the override (confidence 1.0, source "routing_override"), skip precedence lookup
• Log the override application to audit

Step 2: Query Sources in Precedence Order

For each cluster without an override, query sources strictly in order:

Stop at the first level that returns a valid team or assignee.

Step 3: Apply Confidence Modifiers

Multiply each result's confidence by the precedence modifier from routing_config.

Step 4: Detect Staleness

Flag any routing signal older than the staleness threshold (default 30 days):

• Mark the result as stale with the number of days
• Reduce confidence accordingly
• Stale signals are still usable but should be noted in output

Step 5: Build Recommendation

Using lib.buildRoutingRecommendation():

• Rank valid results by level (lowest level = highest priority)
• Set top_recommendation to the best result
• If no valid results: set uncertainty=true with reason "Routing: uncertain — no routing signals available. Manual assignment required."

References

Load routing precedence rules:

!cat skills/x-bug-triage/references/routing-rules.md

Load escalation trigger definitions:

!cat skills/x-bug-triage/references/escalation-rules.md

Repo Scanning Process

Step-by-step procedure for scanning GitHub repos to gather corroborating evidence for bug clusters, assigning confidence tiers to each finding.

Instructions

Step 1: Select Repos

For each cluster:

1. Look up repos from surfacerepomapping using the cluster's product_surface
2. Cap at top 3 repos per cluster (hard limit — never scan more)
3. If no mapping exists, note it as a warning and skip

Step 2: Search Issues

For each repo, call mcptriagesearchissues with the cluster's symptoms and errorstrings:

• Match error strings against open/recent issues
• Assign evidence tier based on match confidence

Step 3: Inspect Recent Commits

Call mcptriageinspectrecentcommits for each repo:

• 7-day window from current date
• Filter by affected paths if known from the cluster's feature_area
• Look for commits that touch relevant code paths

Step 4: Inspect Code Paths

Call mcptriageinspectcodepaths with the cluster's surface and feature_area:

• Identify likely affected code paths
• Check for recent changes or known fragile areas

Step 5: Check Recent Deploys

Call mcptriagecheckrecentdeploys for each repo:

• Correlate deploy/release timing with cluster's first_seen timestamp
• Recent deploy near first_seen is a stronger signal

Step 6: Assign Evidence Tiers

For each piece of evidence, assign a tier:

Step 7: Handle Degradation

If a repo is inaccessible or an API call fails:

1. Log a degraded scan result with the error reason
2. Continue scanning remaining repos — never abort the whole scan
3. Include degradation warnings in output

References

Load evidence tier definitions for proper tier assignment:

!cat skills/x-bug-triage/references/evidence-policy.md

Triage Display Process

Step-by-step procedure for formatting triage results as terminal-ready markdown and handling interactive review command parsing.

Instructions

Step 1: Render Summary

Produce the initial triage summary as terminal markdown:

X Bug Triage — Run {date} {time} UTC
Account: @{account} · Window: last {window} · {count} posts ({unique} unique, {dedup_groups} duplicate groups)
⚠ Data quality: {warning}                  ← show ONLY when date_confidence is low or medium

--- Sources ---                             ← show ALWAYS between header and clusters
{source_name}      {status}    {count} posts   (rate limit: {remaining}/{limit})
...

--- {n} clusters ({new} new, {existing} existing) ---

{icon} {#} · {bug_signature}
     {report_count} reports · {severity} severity · {status_note}
     Owner: {team}
     Evidence: {t1} Tier 1, {t2} Tier 2, {t3} Tier 3, {t4} Tier 4 · Top: {description}

--- Commands ---
details <#>  ·  file <#>  ·  dismiss <#>  ·  merge <#> <issue>
escalate <#>  ·  monitor <#>  ·  snooze <#> <duration>
split <#>  ·  reroute <#>  ·  full-report

Step 2: Render Detail View (for details command)

When showing a single cluster in detail:

• Family, surface, feature area
• Report count, confidence percentage
• Severity + rationale (always show rationale for high/critical)
• Status and time range (firstseen to lastseen)
• Evidence summary line: "Evidence: {t1} Tier 1, {t2} Tier 2, {t3} Tier 3, {t4} Tier 4" (omit tiers with 0 count)
• Evidence listed by tier (all tiers, highest first)
• 3 representative posts (highest quality, most distinct, most recent) — truncate at 100 chars
• Routing with ranked assignees and confidence percentages

Step 3: Parse Review Commands

When receiving a command string, call mcptriageparsereviewcommand:

• Returns structured ParsedCommand with command, clusterNumber, args, valid, error
• If invalid: display the error message to the user
• If valid: return the parsed command to the orchestrator for execution

Step 4: Render Action Confirmation

After each successfully executed review command, display a confirmation line using formatActionConfirmation() from mcp/triage-server/lib.ts. Examples:

• dismiss 1 noise → "Cluster #1 dismissed (noise). Suppression rule created."
• file 2 → "Draft issue created for cluster #2. Use "confirm file 2" to submit."
• escalate 3 → "Cluster #3 escalated. Severity raised."

Formatting Rules

• Severity icons: redcircle = critical/high, yellowcircle =

X Bug Triage

Closed-loop bug triage from public X/Twitter complaints to clustered, evidence-backed GitHub issues.

Overview

Product teams learn about bugs from X/Twitter hours before internal monitoring catches them. This skill automates the pipeline: ingest complaints, classify and cluster them by bug family, scan repos for corroborating evidence, route to owners, and file issues — all with human confirmation gates. Results display directly in the terminal with optional Slack delivery for team review.

Prerequisites

• X API bearer token configured at ~/.claude/channels/x-triage/.env
• SQLite database initialized (bun run db:migrate)
• config/approved-accounts.json and config/approved-searches.json populated
• GitHub CLI (gh) for issue filing

Verify environment before starting:

!test -f data/triage.db && echo "DB ready" || echo "Run: bun run db:migrate"

!test -f config/approved-accounts.json && echo "Accounts configured" || echo "Missing: config/approved-accounts.json"

Instructions

Step 1: Intake

1. Resolve account username to ID: mcptriageresolve_username
2. Fetch mention timeline: mcptriagefetch_mentions
3. Run approved searches: mcptriagesearch_recent
4. Cross-reference mentions with search results for completeness
5. Hydrate conversation threads for posts with conversationid: mcptriagefetchconversation
6. Fetch quote tweets for high-engagement posts: mcptriagefetchquotetweets

After intake completes:

1. Call assessFreshness() from lib/freshness.ts with the combined post set and the requested window boundaries. If date_confidence is "low" or "medium", pass the warning string to the display step for rendering.
2. Collect all DegradationReport objects from intake tool responses. Call buildSourceStatusReport() from lib/source-status.ts to aggregate into a SourceStatusReport. Pass to the display step for rendering between the header and cluster list.

Step 2: Normalize

For each ingested post:

• Parse into BugCandidate (all 33 fields) using lib/parser.ts
• Classify into 12 categories using lib/classifier.ts
• Redact PII (6 types) using lib/redactor.ts
• Score reporter reliability (4 dimensions) using lib/reporter-scorer.ts
• Tag reporter_category from config/approved-accounts.json

St