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. Exception: platform/tizen is never applied by this labeler under any circumstance, even when Tizen files are touched or Tizen is named in an issue (see the platform-label rules below).

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.
• Installation, workload availability, target-framework recognition, requirements, and platform support → area-setup.
• Hot reload, debugging, editor experiences, build tasks, and MSBuild/tooling behavior → area-tooling.
• Project templates → area-templates.
• 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.
• Copilot CLI agents, agent skills, agentic workflows, and AI-assisted development → area-ai-agents. This covers .github/agents/**, .github/skills/**, gh-aw workflow sources and generated locks, and supporting review/test/fix orchestration when the AI-agent behavior is the primary subject.
• CI, build pipelines, Maestro / dependency flow, branch mirroring, and generic GitHub Actions infrastructure → 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 generic .github/workflows/*.yml, .github/scripts/, eng/pipelines/, eng/common/, or other CI infrastructure files → area-infrastructure (prefer this over area-tooling, which is for the dev-build/MSBuild/workload surface that ships to users).
  • AI-agent vs infrastructure tie-break: choose area-ai-agents when the change primarily alters an agent's behavior, prompt, skill, evaluation, or AI-assisted developer workflow. Command parsing and trigger/dispatch behavior for AI-assisted review count as agent behavior. Choose area-infrastructure when the change primarily alters generic CI execution, authentication, scheduling, or pipeline plumbing without changing the AI-assisted workflow's behavior, even if an agent consumes that infrastructure.
  • Mixed PRs (infra-primary + small product edits): if the PR is dominated by CI infrastructure 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 |

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.
• Tizen is excluded. *.tizen.cs files and /Platform/Tizen/ or /Platforms/Tizen/ paths exist in the source tree, but platform/tizen is never auto-applied. Treat Tizen files as if they had no platform suffix for labeling purposes: pick an area-* label normally based on the code's subject matter (e.g., TabbedPage.tizen.cs → area-controls-tabbedpage) and apply no platform/* label for the Tizen content. Only noop if the global noop rules below (e.g., no area-* clearly fits) apply on their own merits.

For issues, infer platform/* labels only for platforms the reporter explicitly identifies as affected: Android, iOS, macOS / Mac Catalyst, or Windows. This includes the issue-template's "Affected platforms" field, plus clear evidence in the title, body, or attached logs/stack traces. Do not guess.

• If the reporter explicitly lists named affected platforms, apply one platform/* label per named platform — even when the list covers every supported platform (e.g., "iOS, Android, Windows, macOS" → apply all four).
• Generic phrases like "all platforms", "every platform", "any platform", or "cross-platform" do not by themselves justify any platform/* label. If a generic phrase is accompanied by an explicit affected-platform list, the named list wins — apply each named platform's label (e.g., "all platforms (iOS, Android, Windows, macOS)" → apply all four).
• Do not apply labels for platforms mentioned incidentally ("tested on iOS"), as "not reproduced" / "not affected", or as label requests ("please add platform/android").
• Never apply platform/tizen — even when the reporter names Tizen, includes Tizen in an "Affected platforms" enumeration, or attaches Tizen logs. Tizen mentions are silently dropped from the platform set.

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 apply platform/tizen under any circumstance — Tizen is excluded from this labeler even when Tizen files are touched or Tizen is named in an issue body, title, or affected-platforms field.
• 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.