fluid-pr-guide

Name: fluid-pr-guide
Author: microsoft

Draft and review Fluid Framework PR titles and descriptions consistently.

Stars

★ 4,934

Source

GitHub

Updated

2026-07-14

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 4.9k

Running security audit…

Credentials
Network egress
Code execution
Data access
Supply chain

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "fluid-pr-guide" skill from askskill:
1. Download https://raw.githubusercontent.com/microsoft/FluidFramework/main/.claude/skills/fluid-pr-guide/SKILL.md
2. Save it as ~/.claude/skills/fluid-pr-guide/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Generate a PR title and description

Prompt

Based on the following code changes, write a PR title and PR description for a Fluid Framework repository. Follow a common title style and organize the body into clear sections: fix a race condition during shared object initialization, add unit tests, and update related documentation.

Expected

A well-formatted PR title plus a PR description with sections like summary, testing, and documentation impact.

Polish an existing PR write-up

Prompt

Please review and polish the following PR copy so it better matches Fluid Framework PR writing conventions. Improve the title wording and add any missing sections: Title: fix bug in loader. Body: This fixes an issue and adds tests.

Expected

An improved title and complete PR body, along with notes on unclear or missing information in the original.

Fill out a PR using a template

Prompt

I’ve finished a feature PR. Please apply an appropriate Fluid Framework-style PR template. Known details: added performance instrumentation for container loading; affects runtime monitoring; passed local tests; no breaking changes. Generate the full PR body.

Expected

A complete PR body with sections for background, changes made, testing status, and impact.

// docs

There is no enforced title policy in this repo. Two styles appear in roughly equal proportion — use whichever fits the change. Do not mix them (e.g., don't add a fix: prefix to an otherwise plain-imperative title just because it's a bug fix).

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.