菜单
Use when composing, writing, drafting, or reviewing a PR title, PR description, or PR body in Fluid Framework — provides title style, body template, and section guidance.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user explicitly asks for a CI check or to push their branch — e.g. "ci readiness", "check ci", "pre-push check", "ready for CI", "ci check", "ready to push", "push my changes", "push the branch", "let's push". Catches common CI failures before pushing — formatting, stale API reports, missing changesets, policy violations.
Fluid Framework client release group — minor releases, patch releases, and post-release type test updates. Covers release prep, branching, version bumps, changelogs, release notes, and type test baselines. In autonomous mode, auto-detects state from the schedule and repo, attempts to execute, and falls back to a GitHub issue on failure. Triggers on "release", "do the release", "release status", version bump, release notes, changelog, release branch, or release engineering.
IMMEDIATELY USE THIS SKILL when creating or develop anything and before writing code or implementation plans - refines rough ideas into fully-formed designs through structured Socratic questioning, alternative exploration, and incremental validation
Use when implementing user interfaces or user experiences - guides through exploration of design variations, frontend setup, iteration, and proper integration
Use this skill when faced with a difficult debugging task where you need to replicate some bug or behavior in order to see what is going wrong.
Use when you need to create a new custom skill for a profile - guides through gathering requirements, creating directory structure, writing SKILL.md, and optionally adding bundled scripts
| name | fluid-pr-guide |
| description | Use when composing, writing, drafting, or reviewing a PR title, PR description, or PR body in Fluid Framework — provides title style, body template, and section guidance. |
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
fix, feat, chore, build, docsbuild-cli, id-compressor, eslint-config-fluid)fix: Prompt copilot-oce to check for Teams channel repliesfix(build-cli): remove flaky parallel changeset testfeat(devcontainer): add agency installation and update host requirementschore: move misplaced @types/ packages from dependencies to devDependenciesbuild(client): Update type tests after minor release 2.91.0Option B — Plain imperative:
Short imperative or noun-phrase description
Port MessageCodec to ClientVersionDispatchingCodecBuilderRemove tree checkout's branch methodEnsure a summarizer stop request is respected after connectingNever 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.
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.ymlcheck to fail.
## 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.AB#<item-id> if applicable (e.g. AB#12345). No dedicated section needed.