Use Option A for build-tools PRs because this group generates changelogs from commits. For other PRs, use either style unless the package documents a different requirement. Do not mix the two styles.

Option A — Conventional Commits prefix:

type(optional-scope): short imperative description

• Common types: fix, feat, chore, build, docs
• Scope is a package or area name (e.g., build-cli, id-compressor, eslint-config-fluid)
• Examples:
  • fix: Prompt copilot-oce to check for Teams channel replies
  • fix(build-cli): remove flaky parallel changeset test
  • feat(devcontainer): add agency installation and update host requirements
  • chore: move misplaced @types/ packages from dependencies to devDependencies
  • build(client): Update type tests after minor release 2.91.0

Option B — Plain imperative:

Short imperative or noun-phrase description

• No prefix, just a clear description of what changed
• Examples:
  • Port MessageCodec to ClientVersionDispatchingCodecBuilder
  • Remove tree checkout's branch method
  • Ensure a summarizer stop request is respected after connecting

Never use the [bump] prefix — that is reserved for automated bot PRs.

Always include a ## Description section, even if it is brief and somewhat redundant with the title.

PR Body Template

Read .github/pull_request_template.md from the repo root and use it as the starting point for the PR body. Fill in each relevant section, then delete sections and placeholder text that don't apply — do not leave empty sections.

CI requirement: the preamble line "Feel free to remove or alter parts of this template..." must be removed from the PR body. Leaving it in will cause the .github/workflows/pr-validation.yml check to fail.

Notes on body sections

• ## Description: Focus on why and impact, not just what lines changed. For bug fixes, include repro steps or a test that demonstrates the fix.
• ## Breaking Changes: Only include when a change removes or alters public API surface or behavior in a way that requires consumer action (like migration or build-time updates). Link the wiki page.
• ## Reviewer Guidance: Always include the wiki link line. Add content if you have specific asks; delete the placeholder bullets if you don't. If design questions are unresolved, mark the PR as a draft.
• Azure DevOps work items: Reference inline in the body as AB#<item-id> if applicable (e.g. AB#12345). No dedicated section needed.