Workflow to label PRs

[michelle-clayton-work]

Add a deterministic GitHub Actions workflow (or extend existing one) that classifies each PR when it is opened, updated, reopened, or marked ready for review.

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

• size:small: no more than 100 changed lines and 5 files.
• size:medium: no more than 300 changed lines and 10 files.
• size:large: no more than 1,000 changed lines and 25 files.
• size:xlarge: anything larger.

Kind
Apply exactly one primary kind:

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

Mixed changes that include production code should use kind:code.

Area
Apply zero or more 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

[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.

@gdams any thoughts?
cc @dagood