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.