UI はローカライズ済みです。スキルの紹介と説明文書は選択した言語へ AI が自動翻訳し、コード・コマンド・パス・専門用語は原文のままです。原作者の文書が優先されます。
スキルを探す
開発・技術 · SKILL.md

owner-routing

owner-routing

Internal process for the owner-router agent. Defines the step-by-step procedure for determining likely bug owners using strict 6-level routing precedence with staleness detection. Not user-invocable — loaded by the owner-router agent through its skills frontmatter.

Independent GitHub snapshot · Automated classification · Original documentation governs

スキルの説明

GitHub

name: owner-routing description: | Internal process for the owner-router agent. Defines the step-by-step procedure for determining likely bug owners using strict 6-level routing precedence with staleness detection. Not user-invocable — loaded by the owner-router agent through its skills frontmatter. allowed-tools: "Read, Bash(cat:*), Grep, Glob" user-invocable: false version: 0.1.0 author: Jeremy Longshore jeremy@intentsolutions.io license: SEE LICENSE IN LICENSE model: inherit effort: medium compatibility: "Designed for Claude Code; internal agent-loaded skill (not user-invocable)" tags: [triage, routing, ownership, precedence, internal-agent-skill]

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.

Overview

Loaded by the owner-router agent inside the x-bug-triage plugin. Walks each open bug cluster through a deterministic six-level routing precedence (service-owner → oncall → CODEOWNERS → recent assignees → recent committers → fallback mapping), applies confidence modifiers, detects stale signals, and produces a ranked routing recommendation. Honors prior routing overrides recorded in cluster memory before consulting any signal source.

Prerequisites

  • Cluster table populated upstream by the bug-clustering stage
  • Routing config available at config/routing.json (precedence modifiers, staleness threshold)
  • Triage MCP server reachable for mcp__triage__lookup_* tool calls
  • Repos in the cluster's product_surface have a configured surface→repo mapping

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:

LevelSourceToolBase Confidence
1Service ownermcp__triage__lookup_service_owner1.0
2Oncallmcp__triage__lookup_oncall0.9
3CODEOWNERSmcp__triage__parse_codeowners0.8
4Recent assignees (30d)mcp__triage__lookup_recent_assignees0.6
5Recent committers (14d)mcp__triage__lookup_recent_committers0.5
6Fallback mappingConfig lookup0.3

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."

Output

  • cluster_routing rows with ranked candidates (team/assignee, source level, confidence, staleness flag)
  • top_recommendation field set on each cluster (or null with uncertainty=true if no signals)
  • Audit-event rows recording every override application, source query, and stale-signal flag

Error Handling

  • Source query failure (transient API error): log, skip that level, fall through to next
  • All six levels return empty: emit uncertainty=true with the standard reason, do not raise
  • Override exists but references a non-existent team: log warning, fall back to precedence walk
  • Staleness detection unavailable (missing timestamp): treat signal as fresh, flag as "unknown_age"

Examples

Triggered automatically by the owner-router agent after clusters are produced. Typical run output for a 12-cluster batch: "12 clusters routed — 1 via override, 4 via service-owner, 3 via oncall, 2 via CODEOWNERS, 2 via recent committers, 0 via fallback (1 stale signal flagged)".

Resources

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
保存したスキル