fluid-pr-guide

Use **Option A** for build-tools PRs because this group [generates changelogs from commits](../../../build-tools/README.md#documenting-build-tools-changes). 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.