用途：从原始 issue 和实现 pull request 或提交出发，撰写并提交一个独立的 ASP.NET Core API 提案（审查）issue。
主要能力：收集原始 issue 及其全部评论、实现 PR 或提交与 diff；核对每一处公共或受保护类型、成员、签名、默认值或约定的变更；按模板撰写 Background and Motivation、Usage Examples、Proposed API 等必需章节，Alternative Designs 与 Risks 在资料具备时补充；为正文中每条实质性主张附上来源引文；在 dotnet/aspnetcore 中创建带 [API Proposal] 前缀标题、api-suggestion 与 api-proposal 标签、并尽量使用 Feature 类型的问题；最后将该 API 提案 issue 链接回实现 PR。
必要用法流程：先列输入清单，缺失原始 issue 或实现变更时先向用户索取；阅读 issue 与评论、检查 PR、提交和 diff；起草正文并填写模板（references/section-guidelines.md、assets/issue-template.md）；Proposed API 必须使用 ref-assembly diff 格式，含完整命名空间与类型声明；创建 issue 时优先使用原生工具让用户确认，若无法创建则给出可提交的标题、正文、标签与类型并说明未提交；然后在实现 PR 中追加提案链接且不删除原有描述。
适用场景：为 ASP.NET Core 公共 API 变更发起正式 API 审查流程。
限制：不得编造信息，所有陈述必须来自原始 issue 或实现变更；证据不足时的必需章节须索取信息，可选章节需逐节向用户提一个聚焦问题，用户确认无内容才写 N/A；PublicAPI.Unshipped.txt 只跟踪兼容性，不代表 API 通过审批；API 审查可在实现前、中、后发生，PR 就绪与合并不要求 api-approved；API 进入 RTM 前该提案 issue 须带覆盖最终实现 API 形态的 api-approved 标签，若实现改变已批准形态需更新提案并重新审查；应用 api-ready-for-review 时通知 @dotnet/aspnet-api-review，且须有代表参加审查会议。完成标准：存在独立 API 提案 issue，含所需标题、正文、标签、来源链接与回链实现 PR；若因工具或输入受阻，报告具体阻碍并留下完整可提交草稿。