Workflow to label PRs

[michelle-clayton-work]

Add a fork-safe GitHub Actions workflow that classifies each PR when it is opened, updated, reopened, or marked ready for review. Neither stage should check out or execute pull request code.

Size
Apply exactly one deterministic size label based on changed lines and file count:

• size:small: no more than 30 changed lines and 2 files.
• size:medium: no more than 100 changed lines and 5 files.
• size:large: no more than 300 changed lines and 10 files.
• size:xlarge: anything larger.

Kind
Apply every substantive kind that describes the PR:

• kind:code
• kind:docs
• kind:tests
• kind:examples
• kind:dependencies
• kind:ci

Mixed PRs may have multiple kind labels, such as kind:code and kind:tests. If the semantic classifier cannot read the PR or classify it confidently, preserve existing kind labels and apply failed-auto-classify; remove that marker after a later successful classification.

Area
Apply zero or more deterministic area labels based on changed paths:

• area:agent
• area:workflow
• area:message
• area:tool
• area:provider
• area:provider/a2a
• area:provider/agui
• area:provider/anthropic
• area:provider/copilot
• area:provider/foundry
• area:provider/gemini
• area:provider/openai
• area:provider/otel
• area:internal
• area:tooling
• area:examples
• area:github

Risk classification is tracked separately in #824.

[gdams]

Like this, I wonder if the parity bot could be extended to add these labels

[gdams]

I do wonder whether rather than tracking size we should define a risk matrix:

risk:low

A small, isolated change with a limited blast radius and straightforward rollback.
Typical examples:

• Documentation, comments, examples, or formatting
• Tests that do not change production behaviour
• Minor bug fixes in a self-contained component
• Internal refactoring with no public API or behavioural change
• Dependency patch updates with no meaningful runtime impact

The change should have good test coverage and should not affect authentication, security, persistence, concurrency, public APIs, or workflow execution.

risk:medium

A change that affects production behaviour but is reasonably contained and well tested.
Typical examples:

• New features behind an existing abstraction or feature flag
• Changes to workflow or agent execution behaviour
• Public API additions that remain backwards compatible
• Dependency minor-version upgrades
• Changes involving retries, timeouts, streaming, tool invocation, or error handling
• Refactoring across multiple packages
• Performance or concurrency changes with a bounded impact

Use this as the default when a change has meaningful runtime impact but does not meet the high-risk criteria.

risk:high

A change with a large blast radius, difficult rollback, security implications, or a meaningful chance of data loss or widespread regressions.
Typical examples:

• Authentication, authorization, secrets, or credential handling
• Breaking public API changes
• Changes to core agent orchestration or workflow state management
• Persistence formats, migrations, serialization, or checkpoint compatibility
• Code execution, sandboxing, tool permissions, or trust-boundary changes
• Significant concurrency or synchronization changes
• Major dependency upgrades
• Changes affecting many packages or all users
• Removal of safeguards, validation, or backwards compatibility
• Changes with inadequate tests for the potential impact

[michelle-clayton-work]

Other considerations should be whether to make this a reusable workflow in go-infra so other repos can also use this. The main con would be the mention of go-infra might lead to an increase in PRs there.

George Adams (@gdams) any thoughts?
cc Davis Goodin (@dagood)

[griffinbird]

+1 George Adams (@gdams) to risk being more useful than size as the primary review-depth signal. The remaining design question is whether risk belongs directly in #793 or in the reusable go-infra classifier.

My preference would be to land #793 with its current size/kind/area scope, then add risk as a follow-up in this repository. Risk is more semantic and repository specific than size:

• workflow/, checkpointing, serialization, concurrency, and tool-permission changes may be high risk here.
• Those same paths and concepts may not exist—or may carry different risk—in another Go repository.
• public-api-change from the parity workflow is a useful signal here but is not necessarily available elsewhere.

The first implementation could combine:

• Deterministic inputs: kind, changed paths, dependency version class, file/line counts, and public-api-change.
• Repository-specific rules: checkpoint/persistence, orchestration, security/trust boundaries, concurrency, and compatibility-sensitive serialization.
• Agent assessment: only when deterministic rules do not produce a confident result.

Once tested against real PRs, the generic classification engine could move into go-infra with repository provided configuration example:

YAML

high-risk-paths:
  - workflow/checkpoint/**
  - agent/harness/toolapproval/**
  - tool/shelltool/**

high-risk-labels:
  - public-api-change

low-risk-kinds:
  - kind:docs
  - kind:examples

This lets #793 stay focused and gives us room to test the risk model first and means go-infra can adopt something proven rather than baking in assumptions that may only apply to MAF.

[michelle-clayton-work]

Ben Griffin (@griffinbird) thanks for the input! Created a followup issue to add the risk classifier #824