Agent Skills: Agentic Labeler

Agentic Labeler

Labeling rules for the dotnet/maui repository. These rules are the canonical source of truth for how issues and PRs should be labeled. They are consumed by the agentic-labeler gh-aw workflow and can also be used standalone for batch evaluation or interactive labeling.

🚨 Scope: area-* and platform/* ONLY

The labeler applies only two label families, and nothing else:

1. Exactly one area-* — derived from the subject matter (control name, area like layout / navigation / xaml / infrastructure / etc.). Choose the single most specific match for the dominant subsystem; see the tie-breaking rules below.
2. One or more platform/* — derived from changed-file platform conventions on PRs, or from explicit platform mentions on issues. Apply all that fit.

The labeler must NOT apply any other label, ever. Specifically, do not apply:

• t/* (kind: t/bug, t/enhancement ☀️, t/docs 📝, t/breaking 💥, t/native-embedding, t/desktop, t/a11y, etc.) — the issue/PR author or other automation owns these.
• i/* (indicators: i/regression, etc.) — set during triage based on investigation, not initial content.
• s/* (status: s/needs-info, s/needs-repro, s/needs-verification, s/needs-attention, s/triaged, s/verified, s/no-repro, s/not-a-bug, s/duplicate 2️⃣, s/pr-needs-author-input, etc.) — managed by dotnet-policy-service[bot] and human triagers.
• p/* (priority: p/0, p/1, p/2, p/3) — set by maintainers.
• partner/* (e.g., partner/syncfusion) — set by partner-tracking automation.
• perf/* (e.g., perf/memory-leak 💦) — set during perf investigation.
• backport/*, regressed-in-*, version/* — set during triage / release management.
• untriaged, :watch: Not Triaged — applied by repo automation on issue open.
• Anything else that is not literally an area-* or platform/* label.

If the only labels that clearly apply are not area-* or platform/*, noop instead — see the noop section below.

If neither an area-* nor a platform/* label clearly applies, noop.

Label discovery

• Fetch the current list of labels using the list_label MCP tool (provided by the labels toolset). Note the singular name — it is list_label, not list_labels.
• Important pagination caveat: the list_label tool only returns the first ~100 labels (no pagination). This repo has ~440 labels, so many area-* and platform/* labels will be missing from the listing. If you have a strong candidate area-* or platform/* label name in mind that isn't in the listing, verify it exists with the get_label tool before adding it.
• Do not create new labels — only labels that already exist in the repository will be accepted.

Labeling rules

area-* label (issues and PRs) — exactly one

Apply exactly one area-* label. Pick the single most specific match for the dominant subsystem:

• Specific control mentioned → matching area-controls-<name> (e.g., CollectionView → area-controls-collectionview, Entry → area-controls-entry, Map / Maps → area-controls-map, Window → area-controls-window, WebView → area-controls-webview, HybridWebView → area-controls-hybridwebview). Always use the area-controls-<name> prefix — never invent shorter aliases (e.g., the Maps area is area-controls-map, not area-maps).
• Layout, measure/arrange, sizing issues → area-layout.
• Navigation, Shell routing, page navigation → area-navigation (or area-controls-shell when Shell-specific).
• XAML parsing, markup extensions, XamlC, source generators → area-xaml.
• Hot reload, build, MSBuild, workload, project templates, tooling → area-tooling, area-templates, or area-setup as appropriate.
• BlazorWebView / Blazor hybrid → area-blazor.
• Essentials APIs (non-UI: connectivity, sensors, preferences, etc.) → area-essentials.
• Drawing / Microsoft.Maui.Graphics → area-drawing.
• Gestures (tap, pan, swipe, pinch) → area-gestures.
• Lifecycle, hosting, app startup, DI → area-core-lifecycle / area-core-hosting.
• Dispatcher / main thread / threading → area-core-dispatching.
• Localization / RTL / culture → area-localization.
• Docs only → area-docs.
• CI, build pipelines, Maestro / dependency flow, branch mirroring, GitHub workflows, agentic-workflow / skill files (when these are the primary subject of the PR; see Mixed PRs below) → area-infrastructure. This covers:
  • [dnceng-bot] codeflow/branch-mirroring issues (the standard "Branch … can't be mirrored to Azdo" issues) → area-infrastructure (do not noop these — they have a clear area).
  • PRs touching only .github/workflows/, .github/skills/, .github/scripts/, eng/pipelines/, eng/common/, or other CI/agent-infra files → area-infrastructure (prefer this over area-tooling, which is for the dev-build/MSBuild/workload surface that ships to users).
  • Mixed PRs (infra-primary + small product edits): if the PR is dominated by CI/agent-infra changes but also has incidental edits to product code, still apply area-infrastructure (and omit any product area-*). If the product-code change is the focus and the infra change is incidental (e.g., a small workflow tweak that supports a feature), prefer the product area-* label and omit area-infrastructure.

Tie-breaking when multiple areas could apply — pick the single most specific:

• Specific control beats generic area. area-controls-tabbedpage over area-navigation; area-controls-collectionview over area-layout; area-controls-shell over area-navigation.
• Sub-area beats parent area. area-safearea over area-layout; area-core-dispatching over area-core-lifecycle.
• Subject-matter focus beats incidental touch. If a PR fixes a CollectionView bug by adjusting layout code, the area is the control (area-controls-collectionview), not the layout system.
• When genuinely tied, prefer the area that names the user-visible feature over the implementation-detail area.

If after applying these heuristics there is still no single best fit, noop rather than apply two area labels.

platform/* labels

This is the most important behavior for PRs.

For pull requests, infer platform/* labels primarily from the changed files, using the rules below. Each rule maps a file pattern to one or more platform labels. Apply a platform/* label if any changed file matches that pattern. The path patterns intentionally target the established MAUI source-layout conventions — match the patterns in the table below (e.g., /Platform/<Name>/, /Platforms/<Name>/, /Handlers/*/<Name>/). Do not match on a bare top-level /Android/, /iOS/, /Windows/, or /MacCatalyst/ segment that is not part of one of the patterns in the table — bare segments occur in templates, docs, and unrelated tooling paths and are not platform-specific source code.

Note on iOS / MacCatalyst: file-extension patterns and directory patterns map differently because of MAUI's compilation conventions — they are split into separate rows below.

| File pattern (changed in the PR) | Label(s) to apply | | --- | --- | | *.android.cs, *.Android.cs, paths containing /Platform/Android/, /Platforms/Android/, /AndroidNative/, or handler subdirectories like /Handlers/*/Android/ | platform/android | | *.ios.cs, *.iOS.cs (file-extension pattern — these compile for both iOS and MacCatalyst) | platform/ios and platform/macos | | Paths containing /Platform/iOS/, /Platforms/iOS/, or handler subdirectories like /Handlers/*/iOS/ (directory pattern — these compile only for the iOS TFM) | platform/ios only | | *.maccatalyst.cs, *.MacCatalyst.cs, paths containing /Platform/MacCatalyst/, /Platforms/MacCatalyst/, or handler subdirectories like /Handlers/*/MacCatalyst/ | platform/macos | | *.windows.cs, *.Windows.cs, paths containing /Platform/Windows/, /Platforms/Windows/, or handler subdirectories like /Handlers/*/Windows/ | platform/windows | | *.tizen.cs, paths containing /Platform/Tizen/, /Platforms/Tizen/ | platform/tizen |

Notes:

• If a PR touches only shared / cross-platform code (e.g., src/Core/src/*.cs without a platform suffix, or src/Controls/src/Core/), do not apply any platform/* label.
• If a PR touches multiple platforms, apply each matching platform/* label.
• .ios.cs files compile for both iOS and MacCatalyst (see split table rows above).
• .maccatalyst.cs files do not compile for iOS — apply only platform/macos for those.

For issues, infer platform/* labels only if the reporter clearly indicates a platform (explicit mention of Android / iOS / macOS / Windows / Tizen in the title, body, or attached logs/stack traces). Do not guess. If the report says "all platforms" or doesn't specify, apply no platform/* label.

When to noop (no labels)

Some items should not be labeled. If any of the following apply, skip labeling entirely:

• Automated inter-branch merge PRs — titles like [automated] Merge branch 'main' => 'net11.0' or similar bot-created merge PRs. These are infrastructure, not feature/bug work.
• Dependency bump PRs that already have dependencies and area-infrastructure labels.
• Items where no area-* or platform/* label clearly fits — when the content is too vague or ambiguous to determine area or platform with confidence, or when the only labels that would apply are outside the allowed area-* / platform/* scope.

⚠️ Do NOT noop [dnceng-bot] codeflow/branch-mirroring issues. Despite being bot-authored, they have a clear area (area-infrastructure) and should be labeled, not noop'd. The noop rule for automated PRs above is specifically about [automated] Merge branch … titles.

What NOT to do

• Do not apply any label that is not literally area-* or platform/*. No t/*, i/*, s/*, p/*, partner/*, perf/*, backport/*, regressed-in-*, version/*, untriaged, :watch: Not Triaged, or anything else. See the "Scope" section at the top for the full prohibition.
• Do not create new labels — apply only labels that already exist in the repository.
• Do not add platform/* labels to PRs that don't touch platform-specific files.
• Do not post a comment summarizing the labels — labels speak for themselves.
• Do not close, lock, or otherwise modify the issue/PR beyond labeling.
• Do not label automated merge PRs — these are infrastructure, not actionable items.
• Be conservative; precision beats recall. Only apply area-* or platform/* labels that clearly fit.