$ loading_
帮助团队识别客户可见 API 变更并判断发布、评审与弃用流程要求
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "api-changes" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/FluidFramework/main/.claude/skills/api-changes/SKILL.md 2. 保存为 ~/.claude/skills/api-changes/SKILL.md 3. 装好后重载技能，告诉我可以用了
请根据以下 api-report 与 main 分支的差异，判断这是否属于客户可见 API 变更，并说明是否需要发布标签、API Council 评审，以及是否包含破坏性变更：{{api_report_diff}}输出对 API 变更性质的判断，以及所需发布标签、评审要求和破坏性变更结论。
我们准备移除一个公开 API，请根据当前变更说明该功能应如何弃用、需要保留多久、如何向用户沟通，以及 changeset 应该怎么写：{{change_details}}给出符合规范的弃用步骤、沟通建议、时间要求和 changeset 编写指引。
CI 的 ci-readiness-check 检测到 API report diff，请根据下面的检查结果给出下一步处理建议，包含负责人、必须完成的评审和推荐动作：{{ci_output}}输出清晰的后续操作清单，帮助团队完成 API 变更合规处理。
git diff $(git merge-base HEAD origin/main)...HEAD -- '**/api-report/**/*.md'
Build a summary table and present it to the user:
| Package | Change type | Tag(s) | Breaking? |
|---|
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.
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:
| Tag | When to use |
|---|---|
@public| Stable, production-ready. Full SemVer. Use only when the shape is final. |
@beta | Seeking feedback, path to @public. Production OK with caution. |
@alpha | Experimental, early feedback only. Not for production. No stability guarantees. |
@internal | Framework-internal only, not for external consumers. |
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.
Tell the user whether their change requires API Council approval:
| Changed surface | Approval required? |
|---|---|
@public, @legacy @public, @beta, @legacy @alpha | Yes — fluid-cr-api will be automatically assigned as a required reviewer on the PR |
@alpha only (not @legacy) | No — but early engagement with the council is encouraged |
@internal only | No |
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
A breaking change removes or modifies an existing API in a way that causes compile errors for consumers upgrading.
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:
…
帮助你严谨评估代码评审意见，澄清疑点后再决定是否采纳与实现
快速判断 PR 变更对文档的影响级别，决定是否需要更新或重构文档。