PromptWorks/ado-triage/SKILL.md

name

description

ado-triage

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

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:

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.