twg-responsibility-routing

twg-responsibility-routing

Use the root twg skill. Use this workflow to answer “who should I involve, why them, and in what role?” Do not assume a broad topic is an exact product.

CLI launcher fallback

Run twg <command>. On shell command not found, use $HOME/.local/bin/twg (macOS/Linux) / $env:LOCALAPPDATA\Programs\twg\bin\twg.exe (PowerShell), then tell user to add that directory to PATH. Do not treat auth or command errors as PATH failures.

Classify The Role

Keep these roles distinct:

• Declared owner: formally accountable for an entity or area.
• Operational owner or maintainer: responsible for current delivery or operation.
• Expert: has source-backed depth in one workstream.
• Reviewer or consulted party: evaluates or advises but may not decide.
• Approver or decision authority: can authorize the specific ask or decision.
• Escalation or Head of Engineering contact: leads the responsible engineering

organization or can route an unresolved ask.

• Informed stakeholder: affected by the decision but not responsible for it.

Resolve Scope Before People

For a fuzzy topic or area, compare one bounded twg rovo search "<topic>" --app confluence pass with one bounded twg work search "<topic>" pass. Group same-named results into distinct initiative, platform, domain, feature, and team clusters. Hydrate 2-5 central charters, roadmaps, services, projects, or active workstreams before ranking people. If the sources disagree, show the alternative scopes or ask the user.

For a stable project, goal, component, service, work item, page, or repository, use that reference directly.

Find Responsibility And Authority

• Use twg responsibility get <reference> for declared owners, teams,

maintainers, approvers, reviewers, or escalation roles.

• Use twg responsibility infer <reference> only when declared responsibility

is missing or the user asks for evidence-based candidates. Preserve confidence, reason codes, evidence window, and declared-versus-observed status.

• Infer primarily from scoped search, declared roles, and hydrated work evidence.

Org data is optional; do not block or weaken the workflow merely because it is unavailable.

• When org data is connected and a candidate leader or manager is known, prefer

the narrowest useful tree: org-tree for hierarchy, work-tree for cross-surface breadth, workitem-tree for Jira work, or pr-tree for PR authorship/review. Tree counts help validate reach and organizational scope; they do not by themselves prove expertise, ownership, or approval authority.

• For an approval ask, inspect the artifact that defines the decision: project or

goal ownership, Jira workflow/approver fields, charter, decision record, or accountable team. State separately who can recommend, who must be consulted, and who can approve. Never promote an active contributor into an approver.

• For escalation, give the nearest verified owner first. Add the engineering

leader only when the owner is missing, blocked, cross-team, or the ask needs organizational authority.

Use twg-context-discovery only when relationship or dependency expansion is needed after the scope and people roles are established. It is not the default route for a responsibility question.

Evidence And Output

Strong evidence includes explicit ownership, accountable roles, workflow authority, charter/roadmap leadership, service ownership, sustained decisions, or repeated central contributions. Profile text, org proximity, one document, raw activity, or a self-authored update is weak evidence by itself.

For topic/SME maps, return at most five workstreams and one primary expert per workstream unless the user asks for more. Name an overall owner only with cross-workstream evidence. For approval or escalation asks, return the proposed contact, role, scope, evidence, confidence, why they are appropriate, and a suggested question or reach-out. State when authority is unconfirmed.

Stop when another search would not change scope, role, authority, escalation, confidence, or the recommended contact.