Triage Case

• A complete root-cause analysis or solution.
• Customer-ready communications (use local-wiki-action-plan for that).
• Documentation for docs/ (use action-plan-to-analysis-doc for that).

Required Input

Minimum:

• A problem summary (even a rough one)
• A product area: pipelines, boards, repos, artifacts, test-plans, dashboards, service-connections, user-access, sign-in, purchasing, or other

Helpful when available:

• Case ID or ticket reference
• Error text or symptoms
• What has already been tried
• Environment details (Services vs. Server, org/project, browser, agent OS)
• Business impact or urgency
• Data the engineer brought to the meeting (logs, screenshots, HAR, timeline)

Procedure

1. Capture the known facts

Restate the problem in plain terms. Extract:

• Product area and feature
• Reported symptoms and error text
• Environment (Services vs. Server, version if Server)
• What has been tried so far
• Any data already collected (logs, traces, screenshots)
• Timeline: when it started, frequency, pattern

Do not embellish or assume beyond what was stated.

2. Check service health

Review the Azure Status portal (https://status.azure.com) and the Azure DevOps Status portal (https://status.dev.azure.com) for active or recent service events that match the reported symptoms and timeline. Note any matching incidents.

3. Search local sources for process guidance

Follow the local source priority reference:

1. sources/internal/Azure_DevOps_Wiki/** — look for scoping pages, intake checklists, and troubleshooting trees for the product area.
2. sources/public/** — look for agent source, API docs, or implementation detail that clarifies behavior.
3. docs/** — check for prior analysis docs on the same product area.
4. scope-cases/** — check for past scoping work on similar symptoms.

If the wiki pack is absent, say so and continue with available sources.

4. Identify knowledge gaps

For each gap, classify it:

5. Assess what is understood vs. not

Build a two-column summary:

• Understood: facts established from the data brought to triage.
• Not understood: open questions, ambiguities, contradictions, or missing context.

Flag any contradictions between the reported facts and what the wiki or docs say should happen.

6. Build the next-action plan

The plan must contain only concrete, actionable items. Each action should be one of:

Order actions by priority. Lead with blocking data requests, then tasks to try, then lower-priority items.

7. Assign a triage confidence level

8. Save the triage report

Save the report to triage-cases/ using this naming convention:

triage-cases/YYYY-MM-DD-<slug>.md

Where the date is today's date and the slug is a short kebab-case description.

Report Template

# Triage: <short title>

**Date**: YYYY-MM-DD
**Product area**: <area>
**Case ID**: <if provided>
**Confidence**: High | Medium | Low

## Problem Summary

<plain-language restatement of the problem>

## Service Health

<any matching incidents or "No matching service events found">

## Known Facts

- <fact 1>
- <fact 2>

## What Has Been Tried

- <step 1>
- <step 2>

## Knowledge Gaps

| # | Gap | Type | Why it matters |
|---|-----|------|----------------|
| 1 | ... | Blocking | ... |
| 2 | ... | Narrowing | ... |

## Understood vs. Not Understood

| Understood | Not understood |
|---|---|
| ... | ... |

## Wiki/Source Alignment

<relevant wiki pages, scope cases, or docs found — with notes on how they apply or where they diverge from the reported facts>

## Next-Action Plan

1. **[Data request]** <what, from whom, why>
2. **[Task to try]** <specific step, expected outcome>
3. **[Return to triage]** <what the follow-up should evaluate>

## Raw Notes

<optional: any additional meeting notes, attendee names, or sidebar observations>

Decision Points

• If the product area is unclear from the summary, ask before proceeding rather than guessing.
• If wiki guidance directly addresses the scenario, cite it and align the action plan to the documented process.
• If wiki guidance conflicts with the reported facts, flag the conflict explicitly in the report.
• If a past scope case matches, reference it and note what was learned.
• If the data brought to triage is too thin for meaningful analysis, the primary next action should be a structured data request — not speculative troubleshooting.
• If the problem clearly falls outside support boundaries per wiki guidance, say so in the report and recommend routing.

Quality Criteria

• The report never claims more understanding than the data supports.
• Every knowledge gap has a type and a reason.
• Every next action is specific and assignable.
• Wiki process alignment is cited, not invented.
• The report is useful to a different engineer picking up the case.
• The triage report is saved to triage-cases/, not to docs/ or scope-cases/.

Completion Check

Before finishing, verify:

• Problem restated in plain language
• Service health checked
• Local sources searched (wiki, docs, scope-cases)
• Knowledge gaps inventoried with types
• Understood vs. not understood table present
• Next-action plan has at least one concrete action
• Confidence level assigned
• Report saved to triage-cases/YYYY-MM-DD-<slug>.md

Example Prompts

• /triage-case pipelines: Build agent disconnects mid-job on self-hosted Windows agent, happens 2-3 times per week, agent logs show timeout errors
• /triage-case boards: Work items losing field values after bulk update via CSV import
• /triage-case repos: PR merge creates unexpected commits in target branch, customer reports extra cherry-picks appearing
• /triage-case service-connections: Azure RM service connection fails with AADSTS700024 after tenant migration