<required> Before doing any work, create one task/todo item per applicable step using your available task tooling (TaskCreate for Claude, TodoWrite for Copilot). Mark each task in_progress when you start it and completed when you finish. This prevents steps from being silently skipped as context grows. </required>

API Changes Review

Step 1: Identify what changed

git diff $(git merge-base HEAD origin/main)...HEAD -- '**/api-report/**/*.md'

Build a summary table and present it to the user:

Change types: addition, removal, signature change, tag promotion.

If all changes are @internal-only, tell the user there are no customer-facing API changes and stop.

---

Step 2: Check release tags, documentation, and export reachability

For any new exports, verify each has a release tag and flag any missing ones to the user — API Extractor will fail with ae-missing-release-tag. Help the user choose the right tag:

When in doubt: @alpha — easier to promote than demote. @legacy is a paired modifier (@legacy @public or @legacy @alpha) for FF v1 APIs; don't apply it to new APIs.

For every new customer-facing export (@public, @beta, @alpha) that is intended to be usable by package consumers, verify it is reachable from the package's public entrypoint, not just exported from the adjacent module or folder. Trace and update the export chain through every relevant index.ts barrel up to the package root entrypoint (typically src/index.ts, or tiered entrypoints such as src/alpha.ts / src/beta.ts where used). Missing parent-barrel exports are incomplete API changes. API Extractor may not report the intended API at all, and consumers are expected to import from the package's top-level entrypoint rather than reaching into subpaths.

Also check that each new customer-facing export (@public, @beta, @alpha) has TSDoc documentation — at minimum a summary, @param tags, and @returns if applicable. Flag any missing documentation to the user.

---

Step 3: Inform the user about API Council review

Tell the user whether their change requires API Council approval:

Tell the user: council approval is a separate sign-off from the area owner review. To engage the council, they can reach out to the API Council member on their EM team or tag @FF API on Teams. Share this link with the user for more details: https://eng.ms/docs/experiences-devices/opg/office-shared/fluid-framework/fluid-framework-internal/fluid-framework/docs/dev/resources/api-council

---

Step 4: Assess breaking changes

A breaking change removes or modifies an existing API in a way that causes compile errors for consumers upgrading.

@public / @legacy+@public

If this is a breaking change to @public or @legacy @public, tell the user this is likely a mistake — major releases happen very rarely. Breaking @public APIs must be coordinated with a major release; the old API must be deprecated at least 3 months prior in a minor release with a clear replacement.

Share these links with the user for the required process:

• API Deprecation wiki: https://github.com/microsoft/FluidFramework/wiki/API-Deprecation

…