用途：在遵循 dotnet/efcore 仓库约定的前提下创建与配置 GitHub Actions 工作流，用于 CI 校验、PR 管理、议题打标签与通知等自动化任务。
主要能力与约定：工作流统一放在 .github/workflows/ 下并使用 kebab-case 命名，开头写描述性注释块；通用任务用 ubuntu-latest，需要特定系统版本时用 ubuntu-24.04。始终显式声明最小权限，不依赖默认值；需要对外部贡献者的 PR 写评论或打标签时用 pull_request_target 而非 pull_request。复杂逻辑优先用 actions/github-script@v8 编写 async/await JavaScript，通过 github.rest.*、github.graphql() 访问 API，数据从 context.payload 与 context.repo 读取，错误用 try/catch 收集后统一上报，调试用 console.log()，失败用 core.setFailed()。
必要用法：先明确触发事件、所需权限、执行条件、API 调用与幂等性；再选择事件（pull_request、pull_request_target、check_suite、push、workflow_dispatch、schedule）；然后按模板编写 YAML 并加入守卫条件，如按 app.slug 过滤自身、按作者或草稿状态提前返回、用隐藏标记做幂等检查。对 pull_request_target 策略工作流：edited 时若无 base 变更应返回；权限应检查 context.actor 而非仅 PR 作者；actor 或作者为机器人时跳过；直接编码禁止的分支类别（如 release/*）；权限查询失败应停止而不做破坏性操作。
限制与安全：pull_request_target 在基础仓库上下文以其权限运行，切勿检出或执行 PR 分支代码，应改用事件载荷和 GitHub API 检查处理；校验时确认权限最小且显式、调用处理分页（per_page: 100）、不硬编码密钥、不产生自触发死循环。仓库已有 validate-pr-target-branch.yml、label-and-milestone-issues.yml、copilot-setup-steps.yml、inter-branch-merge-flow.yml 可作参考。
适用场景：需要按该仓库规范脚手架化或补充 GitHub Actions 工作流的开发与维护场景。具体收费、平台支持范围等资料暂未提供。