---
name: "ado-triage"
description: "Triage Daniel's Azure DevOps work items assigned to him across both orgs - OE on office.visualstudio.com and ES365 on dev.azure.com/enginfra. Categorizes each open item as needing an update, missing KB info, or stale/needs cleanup; scores severity and importance using Obsidian KB context; then walks through updates one at a time. Triggers: /ado-triage, check my ADO queue, triage my work items, review my work item queue, go through my ADO items, what am I assigned, my ADO backlog."
---

# ADO Work Item Triage

Reviews Daniel Kucinski's two "assigned to me" Azure DevOps queues, categorizes and scores every open item using the Obsidian KB for context, then interactively walks him through updating each one. Do not skip the interactive confirmation step — never post comments, edit fields, or close/resolve items without per-item user approval.

## Sources (two separate ADO orgs — handle differently)

| Queue | URL | Access method |
|---|---|---|
| OE project | https://office.visualstudio.com/OE/_workitems/assignedtome/ | `azure_devops-*` MCP tools (already connected — verified via `azure_devops-core_list_projects`, which only returns `office.visualstudio.com` projects incl. `OE`) |
| ES365 project | https://dev.azure.com/enginfra/ES365/_workitems/assignedtome/ | **NOT reachable via the azure_devops MCP tools** (different org, `enginfra`, not `office`). No `az` CLI or PAT is available in this environment either. Use **Playwright browser automation** instead — Daniel has SSO/AAD access in his logged-in browser. |

Re-verify tool connectivity at the start of each run (`azure_devops-core_list_projects` with no filter) in case the MCP scope has changed — don't assume it's still enginfra-blind if this instruction is stale.

## Step 1 — Pull open work items assigned to Daniel

### OE (office.visualstudio.com)
Use `azure_devops-wit_query_by_wiql` with `project: "OE"`:
```sql
SELECT [System.Id],[System.Title],[System.WorkItemType],[System.State],[System.CreatedDate],
       [System.ChangedDate],[System.Tags],[Microsoft.VSTS.Common.Priority],[Microsoft.VSTS.Common.Severity]
FROM WorkItems
WHERE [System.TeamProject] = 'OE' AND [System.AssignedTo] = @Me
  AND [System.State] NOT IN ('Closed','Removed','Resolved','Done')
ORDER BY [System.ChangedDate] DESC
```
Then `azure_devops-wit_get_work_items_batch_by_ids` for full field values and `azure_devops-wit_list_work_item_comments` (or `azure_devops-wit_list_work_item_revisions`) per item for discussion history.

### ES365 (dev.azure.com/enginfra)
1. `playwright-browser_navigate` to `https://dev.azure.com/enginfra/ES365/_workitems/assignedtome/` (keep the browser visible, not headless — Daniel should see what's happening since edits happen here later).
2. `playwright-browser_snapshot` to read the grid: ID, title, type, state, changed date. If prompted to sign in, pause and ask Daniel to complete auth, then retry.
3. Filter client-side to open states (New/Active/equivalent — exclude Closed/Removed/Resolved/Done).
4. For each item, navigate to `https://dev.azure.com/enginfra/ES365/_workitems/edit/{id}`, snapshot the Details pane plus the Discussion/History tab to capture description, comments, and last-changed info.

Emphasize to the user which states you're treating as "open" if the process template uses non-standard state names (e.g. To Do/Doing/Done).

## Step 2 — Stage results in SQL

Create (if not present) and populate a `wi_triage` table in the session SQL DB:
```sql
CREATE TABLE IF NOT EXISTS wi_triage (
  id TEXT PRIMARY KEY,          -- "OE-11908778" or "ES365-<id>" to disambiguate orgs
  org TEXT, project TEXT, wi_id INTEGER, title TEXT, type TEXT, state TEXT, url TEXT,
  priority TEXT, severity TEXT, created_date TEXT, changed_date TEXT,
  category TEXT,                -- any combo of 'A','B','C' e.g. "A,C"
  kb_evidence TEXT,             -- short note + vault path citing what was found
  importance_score INTEGER,     -- 1 (highest) .. 5 (lowest)
  recommended_action TEXT,
  status TEXT DEFAULT 'pending' -- pending -> reviewed -> updated/skipped
);
```
One row per open work item from both queues.

## Step 3 — Cross-reference the Obsidian KB

KB root: `D:\Repos\Obsidian`. Most relevant for ES365/OMR-Health work: `03 - Squads\C3 - OMR Reliability Tooling\` (`00 - Home.md` running log, `Docs\Health Hub Work Items.md`, `04 - Decisions.md`, `05 - Open Questions.md`, `Meetings\`, `Status Updates\`) and `05 - Resources\Quick Reference.md`. Other work items may relate to other squads/areas — search the whole vault, don't assume everything is C3/OMR.

For each work item, use `grep` across the vault for the work item ID and for distinctive title/keyword terms. Note: `Health Hub Work Items.md` and `00 - Home.md` are large — use `grep -n` / `view_range` rather than reading whole files.

Categorize (a single item can carry more than one letter):
- **(A) Has an update** — the KB shows relevant recent activity (a merged PR, a decision, a status change, a meeting outcome) tied to this item that is newer than the item's own `ChangedDate` / latest comment, i.e. the item is behind reality and needs a comment/field update to catch it up.
- **(B) KB info missing from the item** — the KB holds a decision, root-cause note, related PR/IcM link, or blocking dependency clearly relevant to this item that is absent from its description/comments.
- **(C) Old / needs cleanup** — no ADO activity in more than ~21 days (ask Daniel if he wants a different threshold) **and** no KB signal that it's still active — recommend Resolve, Close, or reassignment. If KB explicitly says the work is done/superseded elsewhere, say so in `kb_evidence`.

If no KB evidence exists either way, categorize on ADO signals alone and say so explicitly (don't fabricate KB linkage).

## Step 4 — Score severity / importance

Combine, in this priority order:
1. ADO's own `Priority`/`Severity` fields when populated.
2. KB signals: linkage to an active Sev1/Sev2 IcM, explicit P0–P4 tagging (the squad's Improve/Maintain/KTLO/None framework), WSR/ESR-flagged items, "blocking" language in KB notes.
3. Default to `3` (mid) when no signal exists — don't invent urgency.

`importance_score`: 1 = highest, 5 = lowest. Record the reasoning in `recommended_action` or `kb_evidence`, whichever fits.

## Step 5 — Present the sorted list, then walk through updates one at a time

1. Show one markdown table sorted by `importance_score` ascending (ties broken by category, surfacing C items clearly as cleanup candidates even if their importance is low): `ID | Project | Title | State | Category | Importance | Why`.
2. Then go item by item in that order:
   - Show full context (title, state, KB evidence, category reasoning).
   - Propose one concrete action:
     - **A** → draft the specific comment/update text to post.
     - **B** → propose the specific text to add and cite the KB source (vault path/note).
     - **C** → propose Resolve/Close (with a reason) or reassignment.
   - Ask Daniel to confirm, edit, or skip (use `m_ask_user` for a clean multiple-choice: Apply / Edit / Skip) before touching anything.
   - On confirmation, apply:
     - **OE** → `azure_devops-wit_add_work_item_comment` and/or `azure_devops-wit_update_work_item` (state/field changes).
     - **ES365** → Playwright: navigate to the edit page, fill the discussion box or field via snapshot+click+type, save, and re-snapshot to confirm the save succeeded.
   - Update `wi_triage.status` to `updated` or `skipped` and move to the next item.

## Guardrails
- Never post KB content that looks privacy-sensitive or internal-only into an ADO comment without flagging it to Daniel first — ADO comments can be visible more broadly than the vault.
- Never resolve/close/reassign or post a comment without explicit per-item confirmation.
- Keep the ES365 browser visible throughout (per the assistant's environment default, this should already be true — don't set headless).
- If a KB note look stale/contradicted by a newer ADO state, trust ADO as the source of truth for the item's actual state and say so.