feat: add triage-issues agent skill for Shield workflow

.agents/skills/triage-issues/evals/evals.json

@@ -0,0 +1,23 @@
+{
+  "skill_name": "triage-issues",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "triage new issues",
+      "expected_output": "Fetches the Needs: Triage :mag: queue, classifies each issue, presents a recommendation table, and waits for approval before applying any gh mutations.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "can you go through the fluent ui triage queue and tell me what needs labels?",
+      "expected_output": "Same flow as above — fetches the queue and produces per-issue recommendations. Should correctly route web-components issues to the web-components owner and surface reports that document a critical regression as `Shield: P1` candidates.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "run shield triage on the open issues",
+      "expected_output": "Fetches queue, classifies, produces recommendations. Should not apply any labels without approval. Should correctly identify feature requests and recommend 'Needs: Backlog review'.",
+      "files": []
+    }
+  ]
+}

.agents/skills/triage-issues/references/partner-orgs.md

@@ -0,0 +1,44 @@
+# High-priority reporter signals
+
+Every issue in the triage queue is treated as first-class, regardless of who filed it. External community reports and internal reports go through the same decision tree (classify, check repro, route to owner), and the same SLAs apply to all open v9/v8 bugs.
+
+This file exists because the Shield workflow has one narrow exception: when a report documents a clearly critical regression — with root-cause analysis, measured impact data, or a large blast radius — it can be flagged as `Shield: P1` to pull it to the front of the queue. That flag is about the **nature of the report**, not the reporter.
+
+## When to consider `Shield: P1`
+
+- The issue documents a measured regression (numbers, metrics, profiling data).
+- The issue points to a specific root cause in the code, often with a suggested diff.
+- The issue affects a broad surface (many components, many consumers) rather than a single edge case.
+- The workaround is genuinely unavailable (not just "we'd prefer not to").
+
+The presence of any one of these is a hint, not a trigger. All of them together is a strong signal. None of them — even for a report from an internal team — means normal-priority flow.
+
+## When to consider `Partner Ask`
+
+The `Partner Ask` label exists for a narrow operational reason: some downstream Microsoft teams rely on Fluent UI and their feedback loop is tracked separately for roadmap/reporting purposes. The label captures that a report originated in one of those workstreams so the PM team can roll up partner-facing impact. It is not a quality or priority judgment on the issue itself — community issues frequently hit the queue ahead of partner-tagged issues because their triage outcome is clearer.
+
+If you can't tell from the issue body whether a report qualifies, **don't guess and don't apply the label**. Leave it off and flag `needs_human_followup: "verify whether this is a partner workstream"`. A missing `Partner Ask` label can be added in 5 seconds later; a wrong one is noisier and communicates the wrong thing.
+
+## What this skill does not do
+
+- **Does not downrank community issues.** External contributors get the same triage, labels, assignee routing, and comment quality as anyone else.
+- **Does not treat author identity as a priority signal on its own.** GitHub login is used only to look up context (previous issues, stated affiliation), never as an override for the decision tree above.
+- **Does not publish a partner list.** The operational specifics of which teams use the `Partner Ask` label live outside this repo (in the triager's private notes / internal Shield docs). If you need them for a triage session, the maintainer will surface them; they are not required for a correct triage decision on any individual issue.
+
+## Verification commands
+
+Look up an author's public profile (name, company, bio) when the issue body doesn't make context clear:
+
+```bash
+gh api users/<login> -q '{login, name, company, bio}'
+```
+
+Check prior triage decisions on the same author's issues to see how the team has historically handled similar reports:
+
+```bash
+gh issue list --repo microsoft/fluentui \
+  --search 'is:issue author:<login>' \
+  --limit 5 --json number,title,labels,state
+```
+
+Neither of these determines priority — they just give you context the decision tree can use.

.agents/skills/triage-issues/references/shield-guidelines.md

@@ -0,0 +1,75 @@
+# Shield Triage Guidelines (distilled)
+
+Source: the internal Shield Dev Guidelines doc (Gouttierre Gomes, 15 Jan 2024). This file captures the triage decision tree in text — refer back to the original doc for the surrounding context (R.O.B., PR review, communication channels).
+
+## The core question
+
+Shield human triage processes issues labeled `Needs: Triage :mag:` (after the Shield BOT has already auto-routed the obvious ones). For each issue, you're deciding:
+
+1. **Is this even an issue?** (spam, not-an-issue, question-should-be-discussion)
+2. **Is there a reliable repro?** (if not, block on author)
+3. **What product and version?** (v9 / v8 / v7 / web-components / charting / northstar)
+4. **Does the report document a critical regression?** (measured impact, root cause, broad blast radius → P1 candidate)
+5. **Who owns it?** (area owner or package owner)
+
+## Decision tree
+
+```
+issue labeled "Needs: Triage :mag:"
+├── Is it a question / support request?
+│   └── yes → convert to Discussion, close issue
+├── Is it an accessibility issue?
+│   └── yes → add "Area: Accessibility", assign smhigley (in addition to owner), add to v-a11y board
+├── Does it have a reliable repro?
+│   └── no → add "Needs: Repro" + "Needs: Author Feedback", comment asking for repro
+├── What version?
+│   ├── v9 (N) → always resolve; highest priority among open bugs
+│   ├── v8 (N-1) → resolve normally
+│   └── v7 → generally "Resolution: Won't Fix"; maintainer may make exceptions for exceptional-impact reports
+├── Does the report have tracked-workstream context (per triager's private notes)?
+│   └── yes → add "Partner Ask" if the body confirms the workstream reference. If also a clear critical bug, add "Shield: P1" + notify Shield Teams channel
+├── Is it a feature request?
+│   └── yes → add "Needs: Backlog review", add to unified Backlog
+├── Is it a clear critical bug (even without partner)?
+│   └── yes → add "Shield: P1", notify Shield Teams channel
+├── Is it reasonable for a community contributor?
+│   └── yes → add "Help Wanted"
+├── Can a newcomer tackle it?
+│   └── yes → add "Good First Issue"
+└── Otherwise → assign area owner, remove "Needs: Triage :mag:"
+```
+
+## Area routing (fixed assignments per the guidelines)
+
+| Area                        | Assignee GitHub login |
+| --------------------------- | --------------------- |
+| Northstar (v0)              | `jurokapsiar`         |
+| Web Components (v3)         | `chrisdholt`          |
+| Charting                    | `AtishayMsft`         |
+| Date/Time pickers           | `ermercer`            |
+| Accessibility (any product) | `smhigley`            |
+
+For v8 and v9 React components, use `.github/CODEOWNERS` to find the package owner. CODEOWNERS often lists a team (`@microsoft/cxe-prg`, `@microsoft/cxe-red`); teams can't be assigned to issues, so leave the assignee blank and surface the team for the user to route.
+
+## Version-support matrix
+
+| Version                                 | Status            | Priority treatment                                                                                                    |
+| --------------------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------- |
+| v9 (`Fluent UI react-components (v9)`)  | Active (N)        | Highest — always resolve                                                                                              |
+| v8 (`Fluent UI react (v8)`)             | Maintenance (N-1) | Resolve normally                                                                                                      |
+| Web Components v3 (`Fluent UI WC (v3)`) | Active            | Resolve normally                                                                                                      |
+| Charting                                | Active            | Resolve normally                                                                                                      |
+| v7 (`Fluent UI react (v7)`)             | EOL               | Generally close as "Won't Fix"; a maintainer may make exceptions for reports with exceptional business-impact signals |
+| Northstar (`Fluent UI react-northstar`) | EOL               | Route to `jurokapsiar`, generally won't-fix                                                                           |
+
+## "We'll fix this soon" is off-limits
+
+The guidelines explicitly call this out. When commenting on an issue:
+
+- Acknowledge, point to existing docs / workarounds, offer to review a PR.
+- Do **not** commit the team to a fix unless a dev has already picked it up.
+- Avoid dates. "We'll get to this in Q2" creates an obligation.
+
+## When to stop and hand off
+
+The guidelines are clear: if you can't get an issue to a reasonable resolution state, do a **positive hand-off** — name the next owner explicitly and assign them. Don't just leave it floating with a partial triage. In skill terms: flag `needs_human_followup` with a specific ask ("check whether the reported repro still happens on latest", "check if #33888 should be reopened").

.agents/skills/triage-issues/references/triage-labels.md

@@ -0,0 +1,89 @@
+# Triage label allow-list
+
+These are the labels actually present on the `microsoft/fluentui` repo as of this skill's writing. Don't recommend anything that isn't here — `gh` will fail, and invented labels slip past the user during approval.
+
+To refresh this list against the live repo:
+
+```bash
+gh api repos/microsoft/fluentui/labels --paginate -q '.[] | .name' | sort
+```
+
+## Product labels (pick exactly one)
+
+- `Fluent UI react-components (v9)`
+- `Fluent UI react (v8)`
+- `Fluent UI react (v7)`
+- `Fluent UI WC (v3)` (use together with `web-components`)
+- `web-components`
+- `Fluent UI react-northstar` / `Fluent UI react-northstar (v0)`
+- `Fluent UI vNext`
+- `Package: charting`
+
+## Type labels (pick exactly one)
+
+- `Type: Bug :bug:`
+- `Type: Feature`
+
+## Status labels
+
+- `Needs: Triage :mag:` — remove once triage is done (unless flagged for human follow-up)
+- `Needs: Author Feedback` — pair with repro/info requests
+- `Needs: Repro` — when the reproduction is missing or unusable
+- `Needs: Actionable Feedback :female_detective:` — author replied but still not actionable
+- `Needs: Attention` — needs team attention, not blocking on author
+- `Needs: Backlog review` — for feature requests going to the unified Backlog
+- `Needs: Investigation` — dev needs to investigate before further action
+- `Needs: Discussion` — requires team discussion
+- `Needs: Design` — needs design input
+- `Needs: PM` — needs PM input
+- `Needs: API Breaking Change` / `Needs: Behavior Breaking Change` — flag breaking-change impact
+
+## Priority / ownership labels
+
+- `Shield: P1` — critical / partner-driven; notify Shield Teams channel after applying
+- `Shield: P2` — elevated but not P1
+- `Partner Ask` — report originates in a tracked partner workstream (see `partner-orgs.md` for what this does and does not mean)
+- `Help Wanted ✨` — community can take this
+- `Good First Issue 🏆` — scoped well for a newcomer
+- `From Shield` — marks it as triaged via the Shield workflow
+
+## Area labels (add as applicable — not exhaustive)
+
+- `Area: Accessibility` — always pair with `smhigley` assignment
+- `Area: Performance`
+- `Area: Testing`
+- `Area: Theming`
+- `Area: Icons`
+- `Area: SSR`
+- `Area: Documentation`
+- `Area: Positioning`
+
+(Full list has ~40 Area labels — run the refresh command above if an area doesn't seem covered.)
+
+## Component labels
+
+Format: `Component: <Name>` (e.g., `Component: Announced`). Add when the issue targets a specific component.
+
+## Resolution labels (only when closing)
+
+- `Resolution: Duplicate` — must be accompanied by a comment linking the original
+- `Resolution: Not An Issue` — spam or invalid
+- `Resolution: By Design` — working as intended; explain why in the comment
+- `Resolution: Can't Repro` — after investigation, can't reproduce
+- `Resolution: External` — caused by a dependency or external factor
+- `Resolution: Won't Fix` / `Resolution: Won't Do` — out of support or scope
+- `Resolution: Soft Close` — closed for inactivity but can be reopened
+
+## Label-combination heuristics
+
+| Situation                                                                | Labels to add                                                                                                                  |
+| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ |
+| v9 bug, good repro, not a partner                                        | `Type: Bug :bug:`, `Fluent UI react-components (v9)`, possibly `Component: <X>`                                                |
+| v9 feature request (no v9-native pattern exists)                         | `Type: Feature`, `Fluent UI react-components (v9)`, `Needs: Backlog review`                                                    |
+| v9 feature request porting v8 behavior that v9 addresses via composition | `Type: Feature`, `Fluent UI react-components (v9)`, `Resolution: By Design` — and close with a comment pointing to the pattern |
+| Web-components bug                                                       | `Type: Bug :bug:`, `web-components`, `Fluent UI WC (v3)`                                                                       |
+| Bug with no repro                                                        | `Type: Bug :bug:`, `<product>`, `Needs: Repro`, `Needs: Author Feedback`                                                       |
+| A11y issue                                                               | (above) + `Area: Accessibility`                                                                                                |
+| Partner ask, critical                                                    | (above) + `Partner Ask` + `Shield: P1`                                                                                         |
+| Good first issue candidate                                               | (above) + `Good First Issue 🏆` + `Help Wanted ✨`                                                                             |
+| Duplicate                                                                | `Resolution: Duplicate` + comment with link to original                                                                        |