feat: add triage-issues + triage-board skills (+ visual-test hardening)#36012
Open
tudorpopams wants to merge 8 commits intomicrosoft:masterfrom
Open
feat: add triage-issues + triage-board skills (+ visual-test hardening)#36012tudorpopams wants to merge 8 commits intomicrosoft:masterfrom
tudorpopams wants to merge 8 commits intomicrosoft:masterfrom
Conversation
Introduces a new agent skill that walks the `Needs: Triage 🔍` queue on microsoft/fluentui, classifies each issue against the Shield triage decision tree, and recommends labels, assignees, and comments before applying any changes via the `gh` CLI. The skill operates in recommend-then-apply mode: the LLM never mutates issues until the human has approved the batch. For feature requests that cite v8 behavior, the skill is instructed to investigate v9's documented composition patterns (Field, react-motion-components-preview, useAnnounce, etc.) and default to `Resolution: By Design` when a v9 pattern already addresses the ask — avoiding backlog pollution. Reference docs intentionally describe `Shield: P1` and `Partner Ask` as signal-based decisions (critical-regression evidence, tracked workstream context) rather than identity-based tiering, so external community reports go through the same triage path as any other issue. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
📊 Bundle size report✅ No changes found |
|
Pull request demo site: URL |
Adds a Step 3.5 to the triage-issues skill that lets the human ask the skill to validate specific issues' reproductions with playwright-cli before approving triage. Reuses the install pattern from the visual-test skill. The validation pass visits the reporter's StackBlitz/CodeSandbox (or spins up local Storybook when no sandbox is provided), captures a screenshot + DOM snapshot + console output, and classifies the result as `repros`, `does_not_repro`, or `cannot_determine`. A `does_not_repro` result is surfaced as a `Resolution: Can't Repro` candidate only — never auto-applied — so the human still decides based on the evidence. Explicitly documents what validation is not for: feature requests, reports with a documented root cause + diff, perf regressions, OS-specific behavior, and assistive-tech interactions — headless doesn't give reliable signal there. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Flips the validation flow so the skill takes the initiative: during Step 2 classification it now decides a `validation_candidate` boolean per issue, and Step 3 presents the proposed validation set with one-line reasons for each. The user confirms (yes / all / subset / skip) rather than having to think to ask. Moves the "when to validate vs not" heuristic into Step 3 where the candidate decision is made, next to the examples the user will be looking at. Step 3.5 is reframed as the execution of a human-confirmed set, not an opt-in on user request. Keeps the approval gate in Step 4 unchanged — validation produces evidence only, never a mutation. Users can still manually request additional validation after seeing the table. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Investigated a real Copilot session on microsoft#35874 that failed visual validation for three reasons: (1) it tried the workspace-wide Storybook (public-docsite-v9) and hit HMR restart loops + missing unstable package errors, (2) it used a project name alias that may not exist in older workspace snapshots, (3) it fell back to guessing ports because the dev target is unexpectedly declared with `cache: true` which replays cached output and exits. This commit: - Forbids the workspace-wide Storybook for validation, explicitly. The per-component stories package is the only reliable path. - Switches the primary command to `react-<component>-stories:storybook` (direct target on the stories project) with `--skip-nx-cache`, so the advice works even in workspace snapshots that predate the library-level `start` alias. - Replaces the port-guessing loop with a proper detection pattern: find the storybook child PID (the nx wrapper often exits 0 after delegating) and read its listening socket via lsof. - Adds a troubleshooting section mapping the three failure modes the Copilot session hit to their real causes. The triage-issues validation step (which delegates to this skill) is updated to reinforce the per-component-only rule inline, so an agent that reads only the triage skill still gets the warning. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two fixes found while validating PR microsoft#36013 against a fresh-ish workspace: 1. **Port detection.** The old heuristic picked the lowest-numbered listening port on the first process whose name contained "storybook dev", which was wrong in two ways: - `pgrep -f "storybook dev"` matched both `yarn storybook dev` (wrapper, no sockets) and the real `node .bin/storybook dev` child. `head -1` could pick the wrapper, leaving the port search empty forever. - Storybook opens two listening sockets (HTTP + HMR event-stream). They are not ordered — the event-stream is sometimes lower, sometimes higher. Grabbing the lower port gave back the event-stream in about half of attempts, producing a long hang when the caller then tried to navigate there. Replaced with: pgrep pattern scoped to `node.*\.bin/storybook dev`, then probe each listening socket and pick the one whose response Content-Type is text/html. Added an additional wait loop for `index.json` to populate so the caller doesn't race story compilation. 2. **Unstable-deps setup gotcha.** Per-component Storybooks fail to compile with `Module not found: @fluentui/react-alert` (and react-infobutton / react-virtualizer) on a fresh clone, because those three packages are workspace-linked from local sources whose `lib-commonjs/` is only produced on build. Documented the one-shot `yarn nx run-many -t build -p react-alert,react-infobutton,react-virtualizer` fix in both the visual-test troubleshooting section and the top-level contributing doc, so humans and agents don't rediscover it independently. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Introduces a new agent skill that triages items on the org-level
GitHub Project at microsoft/projects/395 ("Fluent UI - Unified").
The skill is deliberately distinct from the existing `triage-issues`
skill — that one handles repo-level Shield triage (labels + area
owner on `Needs: Triage 🔍`), while this one operates at the
project-board layer: it sets the `Team` single-select field on
board items and, when CODEOWNERS names a specific user, adds that
user as a GitHub-issue assignee. Neither skill touches the other's
surface.
Works cross-repo against microsoft/fluentui,
microsoft/fluentui-system-icons, and microsoft/fluentui-contrib.
CODEOWNERS is the source of truth for both team and individual
routing; the skill caches the three CODEOWNERS files per session
and maps team handles (@microsoft/cxe-prg, @microsoft/teams-prg,
@microsoft/fui-wc, etc.) to the board's fixed Team options via a
confident-vs-ambiguous mapping table in references/team-mapping.md.
Ambiguous handles (charting-team, northstar, etc.) are flagged for
human review rather than auto-routed.
Codifies two rules learned from the first real run against the
live board:
1. **View 6 mirroring.** The board's canonical "By team" triage
view (view 6) excludes items labeled `Resolution: Soft Close`,
`Type: Epic`, `Help Wanted ✨`, and `Needs: Triage 🔍`, plus
Status=Done, PRs, and closed state. The skill filters the same
set client-side so it only proposes team assignments for items
the human is actually looking at. Without this, soft-closed
stale v8 bugs got into the triage pool on the first run — they
shouldn't.
2. **v9 never routes to cxe-red.** cxe-red owns v8; v9 ownership
is cxe-prg (or teams-prg for specific packages). When
CODEOWNERS resolves to cxe-red but the issue carries the v9
label, the skill reroutes to the next mapped team (or cxe-prg)
and flags for human confirmation.
Also adds a two-part preflight at the top of the workflow: checks
both account permission on the repos (EMU vs non-EMU) and the
`project` OAuth scope on the active token (read:project is not
enough for `updateProjectV2ItemFieldValue`). Each failure mode has
its own surfaced message so the user can fix it without trial and
error.
Field and option IDs for the Team single-select are documented in
references/team-mapping.md as of this commit; a refresh query is
included so the skill can re-discover them if they ever rotate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
tudorpopams
changed the title
Adds a Phase 6 to the review-pr skill that posts the same markdown produced in Phase 5 as a comment on the PR itself, so reviews are visible to maintainers and — when the PR author is copilot-swe-agent — become actionable feedback the agent can pick up. The chat output and the PR comment are required to be identical; the skill explicitly forbids paraphrasing or re-summarizing between the two. A `Posted via the /review-pr skill.` trailer tags comments from this skill so subsequent runs can detect and skip duplicates on the same head SHA. Bakes in two guardrails learned during April 2026 sessions: - Pre-check the `gh` viewer identity + `viewerPermission` on the target repo. EMU (Enterprise Managed User) tokens on this org read fine but silently fail on writes; catching this at review-post time rather than confusing the user with a late error. - Handle REQUEST_CHANGES correctly: a comment alone is advisory, so the skill now notes that a formal `gh pr review --request-changes` is still needed to block merge. Also documents the don't-post cases (explicit review-only request, iterating draft PRs, previously-posted on same head SHA) so the skill doesn't become a source of comment noise. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds two new agent skills for triage workflows and hardens an existing one along the way.
triage-issues(repo-level Shield queue)Walks the
Needs: Triage :mag:queue on this repo, classifies each issue against the Shield triage decision tree, and recommends labels, assignees, and comments — applying viaghonly after the human approves.Resolution: Can't Reprois surfaced as a candidate only — never auto-applied.Field,react-motion-components-preview,useAnnounce, etc.) and default toResolution: By Designwhen v9 already addresses the ask — avoids backlog pollution.Shield: P1andPartner Askdescribed as signal-based (critical-regression evidence, tracked-workstream context) rather than identity-based tiering. External community reports go through the same triage path as any other issue.triage-board(Fluent Unified project board)Triages items on the org-level GitHub Project at
microsoft/projects/395. Deliberately distinct fromtriage-issues— sets the board'sTeamsingle-select field (cxe-prg / cxe-red / teams-prg / cxe-coastal / v-build / xc-uxe / fluentui-motion / …) and adds a GitHub-issue assignee from CODEOWNERS. Does not touch labels or Status.microsoft/fluentui,microsoft/fluentui-system-icons, andmicrosoft/fluentui-contrib.By team): excludesResolution: Soft Close,Type: Epic,Help Wanted ✨,Needs: Triage :mag:, Status=Done, PRs, and closed state.microsoft/*) and the separateprojectOAuth scope required forupdateProjectV2ItemFieldValue.visual-testhardeningTwo fixes discovered while validating PR #36013 against a fresh-ish workspace:
pgrep -f "node.*\.bin/storybook dev"targets only the real storybook child (not the yarn wrapper), then probe each listening socket and pick the one whoseContent-Typeistext/html. Added an additional wait loop forindex.jsonto populate so the caller doesn't race story compilation.Module not found: @fluentui/react-alert(andreact-infobutton/react-virtualizer) on a fresh clone because those three packages are workspace-linked from local sources whoselib-commonjs/is only produced on build. Documented the one-shotyarn nx run-many -t build -p react-alert,react-infobutton,react-virtualizerfix in both the visual-test troubleshooting section anddocs/workflows/contributing.mdso it doesn't have to be rediscovered.What's in the commits
triage-issues/— workflow, decision rules,ghcommands, proactive-validation proposal, recommend-then-apply gate, references for shield guidelines / labels / partner signalstriage-board/— workflow, cross-repo CODEOWNERS-driven routing, view-6 filter, two-part auth preflight, GraphQL snippets for field mutationsvisual-test/SKILL.md— hardened port detection +Module not foundtroubleshootingdocs/workflows/contributing.md— new "First-time Storybook setup" noteAGENTS.md— skill registry updated with both new skillsOperational specifics that don't belong in a public repo (the tracked partner-workstream list and known reporter handles used by
triage-issues) are intentionally kept out of this PR; they live in private maintainer memory instead. Community contributors shouldn't have to read a tiering list to understand the triage process.Test plan
triage-issuesruns end-to-end against the liveNeeds: Triage :mag:queue (9 issues initially, triaged across several sessions; labels verified against live repo labels API)triage-issuesapproval gate: skill does not mutate any issue without explicit user approval, including during validationtriage-issuesv9-investigation step correctly identifiesResolution: By Designfor v8→v9 feature asks where composition addresses the need (verified on 7 AMC-filed feature requests)triage-boardruns end-to-end on the live board (30+ items classified and applied across 3 repos, including the soft-close/view-6-filter correction cycle)triage-boardcorrectly reverts a wrong apply viaclearProjectV2ItemFieldValuevisual-testhardened port detection validated against live per-component Storybook for both react-combobox and react-tooltip🤖 Generated with Claude Code