[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PJ4ZJASDV2CGQTG1JWKBFE":3,"skill-same:01M6PJ4ZJASDV2CGQTG1JWKBFE":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6PJ4ZJASDV2CGQTG1JWKBFE","fluid-release",null,"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 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.","microsoft\u002FFluidFramework","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AG0BQKNGBJQ5YNG09HXXW",4948,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"fluid","fluid release","release","patch","release prep","release status","updates","mode","branching","back","issue","releases","bump","status","auto","autonomous","branch","changelog","release notes","notes","2026-11-10 10:12:30",false,"---\nname: fluid-release\ndescription: 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 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.\nlicense: MIT\n---\n\n# Fluid Framework Client Release\n\nRelease workflow for the client release group. Supports two modes: **interactive** (default) and **autonomous**.\n\nPipeline behavior can change: verify the actual run's candidate, metadata, and stages before recommending a publishing action.\nIf the run differs from these instructions, report the discrepancy and investigate before proceeding.\nIf you cannot access the run state, report that limitation rather than guessing or queueing a duplicate run.\n\n## Environment Detection\n\nCheck the `CI` environment variable at the start of every session:\n\n- **`CI=true`**: Running in a GitHub Actions workflow. Use only `origin` (no `upstream`). Use CI-safe commands (see [CI-safe alternatives](#ci-safe-command-alternatives)). Never prompt for input. Log blockers and phase completions to workflow output for human review.\n- **`CI` unset or false**: Running locally. Use `upstream`\u002F`origin` detection as described in Key Context.\n\nSelect the remote once for repository-state checks:\n\n```bash\nrelease_remote=origin\nif [ \"$CI\" != \"true\" ] && git remote get-url upstream >\u002Fdev\u002Fnull 2>&1; then\n    release_remote=upstream\nfi\n```\n\n## Mode Selection\n\nAt the start of every release session, ask the user:\n\n> Would you like to run in **interactive** or **autonomous** mode?\n\nIn CI (`CI=true`), always use autonomous mode — do not prompt.\n\n### Interactive Mode (default)\n\nRun commands autonomously but pause before creating PRs, pushing branches, or triggering builds. Ask for version confirmation at key points. This is the current behavior.\n\n### Autonomous Mode\n\nRun the entire selected phase end-to-end without pausing. Auto-detect the release state from the repo (see below). If the user provides version info upfront, skip the version questions entirely.\n\nRequirements:\n\n- **Version detection:** Infer version numbers from repo state by default (see below).\n  If the user provides versions, use them unless they conflict with repo state.\n- **No confirmation pauses:** Create PRs, push branches, and run `flub release` without asking. Include clear commit messages and PR descriptions.\n- **Phase-scoped execution:** Each phase runs to completion, then reports what the user needs to do next (e.g., \"queue the ADO release build\", \"monitor the automatically triggered publish run\", or \"prepare type test updates after publication\").\n- **Fallback to issues:** If any step fails (permission errors, CI-safe command failures, git push rejected, or any other error that prevents progress), **stop and open a GitHub issue** in `microsoft\u002FFluidFramework` describing what was completed, what failed, and what remains. Use the title format `Release \u003CVERSION>: \u003Cbrief description>` and label it with `release-blocking`. Include the exact commands remaining so a human can finish using the skill in interactive mode.\n\n#### Auto-detecting release state (autonomous mode and CI)\n\nAuto-detect the release state from the repo using the detection steps below. In interactive mode, this detection also runs when the user gives a generic request like \"do the release\" without specifying a version or phase.\n\n**Step 1: Identify the most recent release.**\n\n```bash\n# Get the latest client release tag\ngit tag -l 'client_v*' --sort=-version:refname | head -1\n```\n\n**Step 2: Identify the release version from repo state.**\n\nInspect release-prep branches\u002FPRs, release branches, and tags for a release already in progress.\nUse the version on `main` for a new minor release and increment its minor version by 1 for the next development version.\nIf the version bump has already merged, use the release-prep PR or pre-bump commit to recover the release version.\n\n```bash\n# Inspect the development version and existing release branches\ngit fetch \"$release_remote\" main\ngit show \"${release_remote}\u002Fmain:package.json\"\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F*' 'release\u002Fclient\u002F*'\n```\n\nAsk for clarification only when repo state is ambiguous or conflicts with user-provided versions or phase.\nIn CI, report the ambiguity or conflict and stop instead of prompting.\n\n**Step 3: Check if a release is in progress.**\n\n```bash\n# Check for release-prep branches for the next version\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F\u003CNEXT_VERSION>\u002F*'\n# Check for the release branch\ngit ls-remote --heads \"$release_remote\" 'release\u002Fclient\u002F\u003CNEXT_MAJOR>.\u003CNEXT_MINOR>'\n# Check for a release tag\ngit tag -l 'client_v\u003CNEXT_VERSION>'\n# Check for open PRs\ngh pr list --repo microsoft\u002FFluidFramework --search \"release-prep\u002F\u003CNEXT_VERSION>\" --state all\n```\n\nFor a release branch with no completed release, also inspect ADO pipeline state:\n\n1. Find the **Build - client packages** (definition 12) run for the release branch tip with `releaseBuildOverride: release`.\n2. If that run succeeded, find the automatically triggered **Publish - client packages** (definition 219) run whose `candidate` resource matches that build.\n   Verify the candidate's release branch and commit, and confirm the **Publish to public npmjs.org through ESRP Release API** stage succeeds, rather than being skipped.\n   Publication destinations come from the candidate's recorded metadata.\n3. If ADO pipeline state cannot be queried, do not infer which action is next. Report that a human must identify whether the release build or publish pipeline has completed.\n\n**Step 4: Determine the phase and act.**\n\n| State | Action |\n|-------|--------|\n| No release-prep branches, no release branch | Start **minor release prep** (Steps 1-5) |\n| Release-prep branches\u002FPRs exist, some not merged | Resume **minor release prep** from where it left off |\n| Release branch exists, no successful release build | Resume **release execution** — queue the ADO release build |\n| Successful release build exists, matching publish run is pending or running | Resume **release execution** — monitor the automatically triggered publish run; do not queue a duplicate |\n| Successful release build exists, matching publish run is missing or failed | Investigate the trigger or failed run using the current publishing instructions; do not queue a replacement blindly |\n| Successful public publish run exists, exact GitHub\u002Fnpm release not yet available | Wait for publication to propagate; investigate the publish run if it does not appear |\n| Exact GitHub\u002Fnpm release verified, no patch bump PR | Resume **release execution** — do the patch bump (Step 7) |\n| Exact GitHub\u002Fnpm release verified, patch bump done, no type test PRs | Start **type test updates** (Steps 8-9) without waiting until the next day |\n| All phases complete | Report that the release is fully done and show the next release version from `main` |\n\nPresent the detected state and chosen action to the user (or in the issue body). Example:\n\n> **Detected state:** `main` is at 2.91.0. No release-prep branches found. The most recent release is 2.90.0.\n> **Action:** Minor release prep needed for 2.91.0 (next version on main: 2.92.0).\n\n## Workflow Selection\n\nUse the requested phase, or auto-detect it from repo state as described above.\nAsk only if the phase is ambiguous or conflicts with the request; in CI, report the blocker and stop.\n\n| Phase | When to use | CI-automatable? | Reference |\n|-------|-------------|-----------------|-----------|\n| **Minor release prep** | Starting a new minor release from `main` (Steps 1-5) | Yes (Steps 1-4 create PRs; Step 5 is a human step) | [minor-release-prep.md](references\u002Fminor-release-prep.md) |\n| **Release execution** | Running and publishing the release build + patch bump (Steps 6-7). Also used for **patch releases** on existing branches. | Partially (Step 6 = human queues ADO build; publishing auto-triggers; Step 7 = CI-automatable) | [release-execution.md](references\u002Frelease-execution.md) |\n| **Type test updates** | After release: update baselines on main and release branch (Steps 8-9) | Yes (must be resilient to failure if npm packages not yet available) | [type-test-updates.md](references\u002Ftype-test-updates.md) |\n\nFor **patch releases**, skip directly to release execution on an existing release branch.\n\n### Human checkpoints\n\nThese steps require human action and should be clearly reported in CI workflow logs:\n\n1. **Merge release-prep PRs** in the correct order (version bump last) after CI creates them\n2. **Create the release branch** (Step 5) — requires elevated permissions on the `release\u002F` branch prefix\n3. **Queue the ADO release build** (Step 6) — choose the \"release\" option in ADO\n4. **Approve manual publishing recovery, if needed** (Step 6) — normal publishing auto-triggers; a manually queued recovery run requires the publication approval gate\n5. **Announce the release** in the Fluid Framework \"General\" Teams channel\n\n## Key Context\n\n- The repo uses `pnpm` as the package manager\n- `flub` is the Fluid build CLI (`pnpm flub ...` or `pnpm exec flub ...`)\n- **Version scheme**: The version numbering is not a simple incrementing pattern (it is NOT always multiples of 10). When suggesting a next version, default to incrementing the minor version by 1 (e.g., 2.90.0 -> 2.91.0). Trust the version the user provides unless it is more than 7-8 minor versions away from the current version (which likely indicates an error).\n- Release branch naming: `release\u002Fclient\u002F\u003Cmajor>.\u003Cminor>` (e.g., `release\u002Fclient\u002F2.90`)\n- The release branch is created from the commit **before** the version bump on `main`\n- There is no `lerna.json` in this repo\n- **Git remote preference**: When pushing branches, prefer pushing to `upstream` if one is configured for the repo. Check with `git remote -v` if unsure. Only fall back to `origin` if no `upstream` remote exists. **Exception:** In CI (`CI=true`), always use `origin` — there is no `upstream`.\n- **Working branch naming**: Do NOT use the `release\u002F` prefix for working branches because `release\u002F` is protected on upstream. Use the standard naming convention below — these branches double as progress markers.\n\n### CI-safe Command Alternatives\n\nSome `flub` commands require interactive TTY input. In CI, use these alternatives:\n\n| Interactive command | CI-safe alternative |\n|---|---|\n| `flub bump client --bumpType patch` | `pnpm -r --include-workspace-root exec npm pkg set version=\u003CVERSION>` followed by `pnpm install --no-frozen-lockfile` |\n| `flub bump client --exact \u003CVERSION> --no-commit` | `pnpm -r --include-workspace-root exec npm pkg set version=\u003CVERSION>` |\n| `flub release -g client -t patch` | **Not needed in CI.** The release build is queued manually by a human in ADO. CI only handles prep and post-release phases. |\n\nAfter using `npm pkg set` to bump versions, also run `pnpm -r run build:genver` to update `packageVersion.ts` files, and `pnpm install --no-frozen-lockfile` to update the lockfile.\n\nNon-interactive `flub` commands that are safe in CI (no TTY required): `flub generate releaseNotes`, `flub generate changelog`, `flub typetests`, `flub release prepare`.\n\n### Working Branch Convention\n\nWorking branches follow a numbered naming scheme under `release-prep\u002F\u003CVERSION>\u002F`:\n\n| Step | Branch name |\n|------|-------------|\n| 1 | `release-prep\u002F\u003CVERSION>\u002F1-tag-asserts` |\n| 2 | `release-prep\u002F\u003CVERSION>\u002F2-compat-gen` |\n| 3 | `release-prep\u002F\u003CVERSION>\u002F3-release-notes` |\n| 4 | `release-prep\u002F\u003CVERSION>\u002F4-bump-\u003CNEXT_VERSION>` |\n\nExample for releasing 2.90.0 with next version 2.91.0:\n`release-prep\u002F2.90.0\u002F1-tag-asserts`, `release-prep\u002F2.90.0\u002F4-bump-2.91.0`\n\n### Detecting Prior Progress\n\nBefore starting any phase, check for existing progress by looking at branches and PRs:\n\n```bash\n# Check for existing release-prep branches on the selected remote\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F\u003CVERSION>\u002F*'\n# Check for open release-prep PRs\ngh pr list --repo microsoft\u002FFluidFramework --search \"release-prep\u002F\u003CVERSION>\" --state all\n```\n\nIf branches or PRs already exist, skip completed steps and resume from where the process left off.\n\n## Before Starting\n\nRun `pnpm flub release prepare client` to check readiness. Then check for release blockers:\n\n```bash\ngh issue list --repo microsoft\u002FFluidFramework --label release-blocking --state open\ngh pr list --repo microsoft\u002FFluidFramework --label release-blocking --state open\n```\n\nIf either command returns results, **stop and report the blockers to the user**. In autonomous mode, do not proceed past this check if blockers exist. Also remind the user to check ADO for release-blocking issues (cannot be queried via CLI).\n\n**Blocker handling (autonomous and CI):** If the agent is blocked at any point (release blockers, missing release tag, npm packages not available, permission errors, or any other issue that prevents progress), open a GitHub issue in `microsoft\u002FFluidFramework` describing what was completed, what failed, and what human action is needed. Use the title format `Release \u003CVERSION>: \u003Cbrief description>` and label it with `release-blocking`. Include the exact commands remaining so a human can finish using the skill in interactive mode. Then exit gracefully.\nFor confirmed post-release feed propagation delays, follow [type test update recovery](references\u002Ftype-test-updates.md#ci-resilience) instead of immediately filing a release blocker.\n\n## Behavior by Mode\n\n### Commands (both modes)\n\nRun these autonomously in both modes: `policy-check:asserts`, `layerGeneration:gen`, `flub generate releaseNotes`, `flub generate changelog`, `build:genver`, `flub typetests`, `flub release prepare`\n\nFor version bumps, use `flub bump` locally or CI-safe alternatives in CI (see [CI-safe alternatives](#ci-safe-command-alternatives)).\n\n### PR Conventions\n\nUse the `build:` conventional commit prefix for all release PR titles (e.g., `build: tag untagged asserts for 2.90.0 release`).\n\n### Checkpoints\n\n| Action | Interactive | Autonomous |\n|--------|------------|------------|\n| Creating PRs | Pause and confirm | Create automatically with descriptive titles\u002Fbodies |\n| Pushing branches | Pause and confirm | Push automatically |\n| Running `flub release` | Pause and confirm | Run automatically |\n| Version determination | Infer from repo state; ask only if ambiguous or conflicting | Use version provided upfront or auto-detect |\n| Announcing releases | Remind user | Remind user (never auto-announce) |\n| ADO release build queuing | Instruct user | Instruct user |\n| ADO publish run | Monitor auto-triggered run; manual recovery requires human approval | Monitor auto-triggered run; manual recovery requires human approval |\n\n### Autonomous Mode: Phase Completion Reports\n\nAt the end of each autonomous phase, provide a summary:\n\n1. **What was done** — list all PRs created, branches pushed, commands run\n2. **What to do next** — specific manual steps needed (e.g., queue ADO build, merge PRs in order)\n3. **When to continue** — timing guidance for the next phase (e.g., \"after PRs merge\" or \"after publication is verified; prepare type test updates without waiting for feed propagation\")\n\n### Autonomous Mode: Fallback to Issues\n\nIf any step in autonomous mode fails (permission errors, command failures, git push rejected, etc.), **stop and open a GitHub issue** in `microsoft\u002FFluidFramework` with:\n\n1. **What was completed** — PRs created, branches pushed, commands run successfully\n2. **What failed** — the specific error and which step it occurred at\n3. **What remains** — the exact commands for remaining steps, ready to copy-paste\n4. **How to finish** — remind the human to invoke the `fluid-release` skill in an interactive GitHub Copilot session\n\nUse the title format `Release \u003CVERSION>: \u003Cbrief description of failure>` and label it with `release-blocking`.\nConfirmed post-release feed propagation delays use the retry guidance in [type test updates](references\u002Ftype-test-updates.md#ci-resilience) instead.\n\nRead the appropriate reference file for the phase the user selects, then guide them through it step by step.\n","# Fluid Framework Client Release\n\nRelease workflow for the client release group. Supports two modes: **interactive** (default) and **autonomous**.\n\nPipeline behavior can change: verify the actual run's candidate, metadata, and stages before recommending a publishing action.\nIf the run differs from these instructions, report the discrepancy and investigate before proceeding.\nIf you cannot access the run state, report that limitation rather than guessing or queueing a duplicate run.\n\n## Environment Detection\n\nCheck the `CI` environment variable at the start of every session:\n\n- **`CI=true`**: Running in a GitHub Actions workflow. Use only `origin` (no `upstream`). Use CI-safe commands (see [CI-safe alternatives](#ci-safe-command-alternatives)). Never prompt for input. Log blockers and phase completions to workflow output for human review.\n- **`CI` unset or false**: Running locally. Use `upstream`\u002F`origin` detection as described in Key Context.\n\nSelect the remote once for repository-state checks:\n\n```bash\nrelease_remote=origin\nif [ \"$CI\" != \"true\" ] && git remote get-url upstream >\u002Fdev\u002Fnull 2>&1; then\n    release_remote=upstream\nfi\n```\n\n## Mode Selection\n\nAt the start of every release session, ask the user:\n\n> Would you like to run in **interactive** or **autonomous** mode?\n\nIn CI (`CI=true`), always use autonomous mode — do not prompt.\n\n### Interactive Mode (default)\n\nRun commands autonomously but pause before creating PRs, pushing branches, or triggering builds. Ask for version confirmation at key points. This is the current behavior.\n\n### Autonomous Mode\n\nRun the entire selected phase end-to-end without pausing. Auto-detect the release state from the repo (see below). If the user provides version info upfront, skip the version questions entirely.\n\nRequirements:\n\n- **Version detection:** Infer version numbers from repo state by default (see below).\n  If the user provides versions, use them unless they conflict with repo state.\n- **No confirmation pauses:** Create PRs, push branches, and run `flub release` without asking. Include clear commit messages and PR descriptions.\n- **Phase-scoped execution:** Each phase runs to completion, then reports what the user needs to do next (e.g., \"queue the ADO release build\", \"monitor the automatically triggered publish run\", or \"prepare type test updates after publication\").\n- **Fallback to issues:** If any step fails (permission errors, CI-safe command failures, git push rejected, or any other error that prevents progress), **stop and open a GitHub issue** in `microsoft\u002FFluidFramework` describing what was completed, what failed, and what remains. Use the title format `Release \u003CVERSION>: \u003Cbrief description>` and label it with `release-blocking`. Include the exact commands remaining so a human can finish using the skill in interactive mode.\n\n#### Auto-detecting release state (autonomous mode and CI)\n\nAuto-detect the release state from the repo using the detection steps below. In interactive mode, this detection also runs when the user gives a generic request like \"do the release\" without specifying a version or phase.\n\n**Step 1: Identify the most recent release.**\n\n```bash\n# Get the latest client release tag\ngit tag -l 'client_v*' --sort=-version:refname | head -1\n```\n\n**Step 2: Identify the release version from repo state.**\n\nInspect release-prep branches\u002FPRs, release branches, and tags for a release already in progress.\nUse the version on `main` for a new minor release and increment its minor version by 1 for the next development version.\nIf the version bump has already merged, use the release-prep PR or pre-bump commit to recover the release version.\n\n```bash\n# Inspect the development version and existing release branches\ngit fetch \"$release_remote\" main\ngit show \"${release_remote}\u002Fmain:package.json\"\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F*' 'release\u002Fclient\u002F*'\n```\n\nAsk for clarification only when repo state is ambiguous or conflicts with user-provided versions or phase.\nIn CI, report the ambiguity or conflict and stop instead of prompting.\n\n**Step 3: Check if a release is in progress.**\n\n```bash\n# Check for release-prep branches for the next version\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F\u003CNEXT_VERSION>\u002F*'\n# Check for the release branch\ngit ls-remote --heads \"$release_remote\" 'release\u002Fclient\u002F\u003CNEXT_MAJOR>.\u003CNEXT_MINOR>'\n# Check for a release tag\ngit tag -l 'client_v\u003CNEXT_VERSION>'\n# Check for open PRs\ngh pr list --repo microsoft\u002FFluidFramework --search \"release-prep\u002F\u003CNEXT_VERSION>\" --state all\n```\n\nFor a release branch with no completed release, also inspect ADO pipeline state:\n\n1. Find the **Build - client packages** (definition 12) run for the release branch tip with `releaseBuildOverride: release`.\n2. If that run succeeded, find the automatically triggered **Publish - client packages** (definition 219) run whose `candidate` resource matches that build.\n   Verify the candidate's release branch and commit, and confirm the **Publish to public npmjs.org through ESRP Release API** stage succeeds, rather than being skipped.\n   Publication destinations come from the candidate's recorded metadata.\n3. If ADO pipeline state cannot be queried, do not infer which action is next. Report that a human must identify whether the release build or publish pipeline has completed.\n\n**Step 4: Determine the phase and act.**\n\n| State | Action |\n|-------|--------|\n| No release-prep branches, no release branch | Start **minor release prep** (Steps 1-5) |\n| Release-prep branches\u002FPRs exist, some not merged | Resume **minor release prep** from where it left off |\n| Release branch exists, no successful release build | Resume **release execution** — queue the ADO release build |\n| Successful release build exists, matching publish run is pending or running | Resume **release execution** — monitor the automatically triggered publish run; do not queue a duplicate |\n| Successful release build exists, matching publish run is missing or failed | Investigate the trigger or failed run using the current publishing instructions; do not queue a replacement blindly |\n| Successful public publish run exists, exact GitHub\u002Fnpm release not yet available | Wait for publication to propagate; investigate the publish run if it does not appear |\n| Exact GitHub\u002Fnpm release verified, no patch bump PR | Resume **release execution** — do the patch bump (Step 7) |\n| Exact GitHub\u002Fnpm release verified, patch bump done, no type test PRs | Start **type test updates** (Steps 8-9) without waiting until the next day |\n| All phases complete | Report that the release is fully done and show the next release version from `main` |\n\nPresent the detected state and chosen action to the user (or in the issue body). Example:\n\n> **Detected state:** `main` is at 2.91.0. No release-prep branches found. The most recent release is 2.90.0.\n> **Action:** Minor release prep needed for 2.91.0 (next version on main: 2.92.0).\n\n## Workflow Selection\n\nUse the requested phase, or auto-detect it from repo state as described above.\nAsk only if the phase is ambiguous or conflicts with the request; in CI, report the blocker and stop.\n\n| Phase | When to use | CI-automatable? | Reference |\n|-------|-------------|-----------------|-----------|\n| **Minor release prep** | Starting a new minor release from `main` (Steps 1-5) | Yes (Steps 1-4 create PRs; Step 5 is a human step) | [minor-release-prep.md](references\u002Fminor-release-prep.md) |\n| **Release execution** | Running and publishing the release build + patch bump (Steps 6-7). Also used for **patch releases** on existing branches. | Partially (Step 6 = human queues ADO build; publishing auto-triggers; Step 7 = CI-automatable) | [release-execution.md](references\u002Frelease-execution.md) |\n| **Type test updates** | After release: update baselines on main and release branch (Steps 8-9) | Yes (must be resilient to failure if npm packages not yet available) | [type-test-updates.md](references\u002Ftype-test-updates.md) |\n\nFor **patch releases**, skip directly to release execution on an existing release branch.\n\n### Human checkpoints\n\nThese steps require human action and should be clearly reported in CI workflow logs:\n\n1. **Merge release-prep PRs** in the correct order (version bump last) after CI creates them\n2. **Create the release branch** (Step 5) — requires elevated permissions on the `release\u002F` branch prefix\n3. **Queue the ADO release build** (Step 6) — choose the \"release\" option in ADO\n4. **Approve manual publishing recovery, if needed** (Step 6) — normal publishing auto-triggers; a manually queued recovery run requires the publication approval gate\n5. **Announce the release** in the Fluid Framework \"General\" Teams channel\n\n## Key Context\n\n- The repo uses `pnpm` as the package manager\n- `flub` is the Fluid build CLI (`pnpm flub ...` or `pnpm exec flub ...`)\n- **Version scheme**: The version numbering is not a simple incrementing pattern (it is NOT always multiples of 10). When suggesting a next version, default to incrementing the minor version by 1 (e.g., 2.90.0 -> 2.91.0). Trust the version the user provides unless it is more than 7-8 minor versions away from the current version (which likely indicates an error).\n- Release branch naming: `release\u002Fclient\u002F\u003Cmajor>.\u003Cminor>` (e.g., `release\u002Fclient\u002F2.90`)\n- The release branch is created from the commit **before** the version bump on `main`\n- There is no `lerna.json` in this repo\n- **Git remote preference**: When pushing branches, prefer pushing to `upstream` if one is configured for the repo. Check with `git remote -v` if unsure. Only fall back to `origin` if no `upstream` remote exists. **Exception:** In CI (`CI=true`), always use `origin` — there is no `upstream`.\n- **Working branch naming**: Do NOT use the `release\u002F` prefix for working branches because `release\u002F` is protected on upstream. Use the standard naming convention below — these branches double as progress markers.\n\n### CI-safe Command Alternatives\n\nSome `flub` commands require interactive TTY input. In CI, use these alternatives:\n\n| Interactive command | CI-safe alternative |\n|---|---|\n| `flub bump client --bumpType patch` | `pnpm -r --include-workspace-root exec npm pkg set version=\u003CVERSION>` followed by `pnpm install --no-frozen-lockfile` |\n| `flub bump client --exact \u003CVERSION> --no-commit` | `pnpm -r --include-workspace-root exec npm pkg set version=\u003CVERSION>` |\n| `flub release -g client -t patch` | **Not needed in CI.** The release build is queued manually by a human in ADO. CI only handles prep and post-release phases. |\n\nAfter using `npm pkg set` to bump versions, also run `pnpm -r run build:genver` to update `packageVersion.ts` files, and `pnpm install --no-frozen-lockfile` to update the lockfile.\n\nNon-interactive `flub` commands that are safe in CI (no TTY required): `flub generate releaseNotes`, `flub generate changelog`, `flub typetests`, `flub release prepare`.\n\n### Working Branch Convention\n\nWorking branches follow a numbered naming scheme under `release-prep\u002F\u003CVERSION>\u002F`:\n\n| Step | Branch name |\n|------|-------------|\n| 1 | `release-prep\u002F\u003CVERSION>\u002F1-tag-asserts` |\n| 2 | `release-prep\u002F\u003CVERSION>\u002F2-compat-gen` |\n| 3 | `release-prep\u002F\u003CVERSION>\u002F3-release-notes` |\n| 4 | `release-prep\u002F\u003CVERSION>\u002F4-bump-\u003CNEXT_VERSION>` |\n\nExample for releasing 2.90.0 with next version 2.91.0:\n`release-prep\u002F2.90.0\u002F1-tag-asserts`, `release-prep\u002F2.90.0\u002F4-bump-2.91.0`\n\n### Detecting Prior Progress\n\nBefore starting any phase, check for existing progress by looking at branches and PRs:\n\n```bash\n# Check for existing release-prep branches on the selected remote\ngit ls-remote --heads \"$release_remote\" 'release-prep\u002F\u003CVERSION>\u002F*'\n# Check for open release-prep PRs\ngh pr list --repo microsoft\u002FFluidFramework --search \"release-prep\u002F\u003CVERSION>\" --state all\n```\n\nIf branches or PRs already exist, skip completed steps and resume from where the process left off.\n\n## Before Starting\n\nRun `pnpm flub release prepare client` to check readiness. Then check for release blockers:\n\n```bash\ngh issue list --repo microsoft\u002FFluidFramework --label release-blocking --state open\ngh pr list --repo microsoft\u002FFluidFramework --label release-blocking --state open\n```\n\nIf either command returns results, **stop and report the blockers to the user**. In autonomous mode, do not proceed past this check if blockers exist. Also remind the user to check ADO for release-blocking issues (cannot be queried via CLI).\n\n**Blocker handling (autonomous and CI):** If the agent is blocked at any point (release blockers, missing release tag, npm packages not available, permission errors, or any other issue that prevents progress), open a GitHub issue in `microsoft\u002FFluidFramework` describing what was completed, what failed, and what human action is needed. Use the title format `Release \u003CVERSION>: \u003Cbrief description>` and label it with `release-blocking`. Include the exact commands remaining so a human can finish using the skill in interactive mode. Then exit gracefully.\nFor confirmed post-release feed propagation delays, follow [type test update recovery](references\u002Ftype-test-updates.md#ci-resilience) instead of immediately filing a release blocker.\n\n## Behavior by Mode\n\n### Commands (both modes)\n\nRun these autonomously in both modes: `policy-check:asserts`, `layerGeneration:gen`, `flub generate releaseNotes`, `flub generate changelog`, `build:genver`, `flub typetests`, `flub release prepare`\n\nFor version bumps, use `flub bump` locally or CI-safe alternatives in CI (see [CI-safe alternatives](#ci-safe-command-alternatives)).\n\n### PR Conventions\n\nUse the `build:` conventional commit prefix for all release PR titles (e.g., `build: tag untagged asserts for 2.90.0 release`).\n\n### Checkpoints\n\n| Action | Interactive | Autonomous |\n|--------|------------|------------|\n| Creating PRs | Pause and confirm | Create automatically with descriptive titles\u002Fbodies |\n| Pushing branches | Pause and confirm | Push automatically |\n| Running `flub release` | Pause and confirm | Run automatically |\n| Version determination | Infer from repo state; ask only if ambiguous or conflicting | Use version provided upfront or auto-detect |\n| Announcing releases | Remind user | Remind user (never auto-announce) |\n| ADO release build queuing | Instruct user | Instruct user |\n| ADO publish run | Monitor auto-triggered run; manual recovery requires human approval | Monitor auto-triggered run; manual recovery requires human approval |\n\n### Autonomous Mode: Phase Completion Reports\n\nAt the end of each autonomous phase, provide a summary:\n\n1. **What was done** — list all PRs created, branches pushed, commands run\n2. **What to do next** — specific manual steps needed (e.g., queue ADO build, merge PRs in order)\n3. **When to continue** — timing guidance for the next phase (e.g., \"after PRs merge\" or \"after publication is verified; prepare type test updates without waiting for feed propagation\")\n\n### Autonomous Mode: Fallback to Issues\n\nIf any step in autonomous mode fails (permission errors, command failures, git push rejected, etc.), **stop and open a GitHub issue** in `microsoft\u002FFluidFramework` with:\n\n1. **What was completed** — PRs created, branches pushed, commands run successfully\n2. **What failed** — the specific error and which step it occurred at\n3. **What remains** — the exact commands for remaining steps, ready to copy-paste\n4. **How to finish** — remind the human to invoke the `fluid-release` skill in an interactive GitHub Copilot session\n\nUse the title format `Release \u003CVERSION>: \u003Cbrief description of failure>` and label it with `release-blocking`.\nConfirmed post-release feed propagation delays use the retry guidance in [type test updates](references\u002Ftype-test-updates.md#ci-resilience) instead.\n\nRead the appropriate reference file for the phase the user selects, then guide them through it step by step.\n",{"name":5,"license":15,"description":7},"main","8c51cdeac2dc2c238a8e97fd61e0a1206a7eb336",".github\u002Fskills\u002Ffluid-release",590,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework","https:\u002F\u002Ffluidframework.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 02:46:12",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add microsoft\u002FFluidFramework --skill fluid-release",{"tool":60,"command":61},"bunx","bunx skills add microsoft\u002FFluidFramework --skill fluid-release",{"tool":63,"command":64},"pnpm","pnpm dlx skills add microsoft\u002FFluidFramework --skill fluid-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002FSKILL.md",true,[68,74,78],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fminor-release-prep.md","REFERENCE","参考文档",9218,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002Freferences\u002Fminor-release-prep.md",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frelease-execution.md",7496,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002Freferences\u002Frelease-execution.md",{"path":79,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ftype-test-updates.md",3720,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-release\u002Freferences\u002Ftype-test-updates.md",[83,106,144,166,184,207],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":39},"01M6PJ5SAHYFZFWDG5Y4RW56EP","trigger-pipelines-for-copilot-pr","Trigger ADO pipelines for a Copilot-created PR by posting \u002Fazp run comments. Use when the user asks to trigger CI pipelines for a specific PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftrigger-pipelines-for-copilot-pr\u002FSKILL.md",[],[90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105],"pr","trigger pipelines for copilot pr","for","trigger","copilot","pipelines","ado","posting","run","ci","use","number","URL","comments","user","when",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":125,"publishedAt":39},"01M6PJ5M4ZG7E78C4GM4041HEP","review","Review changes relative to a prior state, such as a diff, pull request, branch, commit, or working-tree changes. Use for change-focused code review and regression analysis. Do not use to assess an existing file, API, design, implementation, or other artifact without a comparison; if the request is ambiguous, ask whether the user wants a change review and what prior state to compare against.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview\u002FSKILL.md",[112,117,120],{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":118,"categoryName":119,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":121,"categoryName":122,"taxonomyType":123,"taxonomyTypeDesc":124},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[108,35,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,92,142,143],"regression","code review","design","ask","analysis","code","commit","api","change","artifact","request","pull","tree","as","do","diff","assess","ambiguous",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":153,"publishedAt":39},"01M6PJ5E3PCBDS319FFMHPFACN","review-pr-local","The authority on pulling a pull request — Azure DevOps or GitHub — into an isolated local worktree so a human can review it in their editor, and on posting human-controlled review comments back to the PR (ADO via the ado PR-thread MCP tools or the Azure DevOps REST API, GitHub via the gh CLI). Auto-detects the platform and all identifiers from the PR URL; not tied to any specific repository. The AI assists an interactive human review and only ever posts comments the human explicitly requests. If you find yourself checking out a PR branch over the user's own working tree, or posting AI-authored review prose the human did not ask for, invoke this skill instead.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Freview-pr-local\u002FSKILL.md",[150],{"categoryNo":151,"categoryName":152,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000023","Skill与智能体开发",[154,108,90,155,156,28,35,157,158,159,160,33,161,162,102,163,129,133,164,165],"local","review pr local","review pr","posts","only","MCP","authority","invoke","azure devops","you","cli","worktree",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":39},"01M6PJ5AVZAS0AEBPCYJZ9ZMMD","policy-check","This skill should be used when the user asks to \"run policy check\", \"check policy\", \"policy-check\", or needs to validate package compliance. Provides guidance on running policy checks for specific packages or the entire repository.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpolicy-check\u002FSKILL.md",[],[173,174,175,176,177,92,98,178,179,180,181,104,182,105,183],"policy check","policy","check","packages","compliance","repository","guidance","validate","package","running","entire",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":193,"publishedAt":39},"01M6PJ54H068MZF2WD2JDKCVDC","pipeline-test-triage","Triage test failures in an Azure DevOps pipeline run for Fluid Framework. Use when the user shares an ADO build\u002Fpipeline URL or build ID and wants failures analyzed, when they ask \"why did this pipeline fail\", \"summarize the test failures\", \"is this test flaky or a real bug\", \"compare these runs\", or wants bugs filed for genuine failures. Covers the Real Service End to End Tests pipeline as the worked example but applies to any FF test pipeline.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpipeline-test-triage\u002FSKILL.md",[190],{"categoryNo":191,"categoryName":192,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000008","测试与质量",[194,195,196,197,198,199,200,201,162,102,129,98,202,203,204,205,96,139,206,92,105],"pipeline","test triage","pipeline test triage","pipeline test","test","triage","end","test pipeline","why","bug","but","framework","bugs",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":213,"publishedAt":39},"01M6PJ4VZB32S8YG8RBKRZ4GP2","fluid-pr","Use when creating a pull request in the Fluid Framework repo. Composes a PR title and body following Fluid Framework conventions, proposes them to the user, then pushes the branch and creates the PR on GitHub. Triggers on \"create a PR\", \"make a PR\", \"open a PR\", \"submit a PR\", or \"push and create a PR\".","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FFluidFramework\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ffluid-pr\u002FSKILL.md",[],[90,19,214,137,35,215,216,217,218,219,220,100,221,222,223,224,225,136,226,227,105],"fluid pr","push","submit","repo","triggers","pr title","open","fluid framework","create","title","github","pull request","conventions","body"]