azure-app-onboard-prereq

用途

Azure App Onboard Prereq 用于在基础设施规划之前，评估源代码是否已准备好部署到 Azure。它是 AppOnboard 流水线四个阶段中的第 1 阶段，定位是“基础设施工作之前的检查”。

该技能会对用户仓库进行只读评估，检查构建健康度、应用完整性、依赖项以及本地可部署性，并按组件生成 PASS / WARN / FAIL 判定结果，供下游阶段消费。

由 azure-app-onboard 在第 3 步调用，也可独立运行以做代码就绪性检查。
当被编排器调用时，写完产物后应将控制权交回 azure-app-onboard，不应直接调用下游阶段。
不适用场景及重定向：
- 验证基础设施（Bicep/TF/azure.yaml）→ azure-validate
- 生成 IaC → azure-prepare
- 端到端从想法到生产 → azure-app-onboard
- 运行 azd up 或部署 → azure-deploy

扫描工作区，检测组件、仓库信息、已检测基础设施与已检测服务，分类 Terraform providers，检查 CLI 可用性。
逐组件评估：构建检查（3.1）、完整性检查（3.2）、可部署性检查（3.3）；当发现多个项目清单（monorepo）时进行组件映射。
写入会话上下文与产物：context.json（components[]、repo{}、detectedInfra[]、detectedServices[]）、prereq-output.json、readiness-report.md。
可选的修复环节：当存在 FAIL 判定、建议修复或带 fixPhase: "prereq" 的 WARN 时，进入修复循环、静态验证、重新评估并更新产物。
路由输出：将 routeToSkill 与 routeReason 写入 context.json，按优先级从上到下匹配路由规则。

支持的入口：

编排器入口：会话已存在，读取 context.json 后继续。
直接入口：检查 .copilot-azure/sessions/active-session.json；不存在则创建会话（生成 UUID，创建目录 .copilot-azure/sessions/{uuid}，写入 context.json 与 active-session.json），随后运行 az account show 并将 {id, name, tenantId} 合并进 context.json.azure。会话必须先落盘，才能开始扫描。

工作流步骤概览：

会话检查。
扫描工作区；若没有项目文件、没有 Dockerfile 且没有 index.html，则走零代码路径；云 SDK 早期门控会检索 aws-sdk|@aws-sdk|boto3|google-cloud|@google-cloud|firebase，发现功能性依赖时询问用户重定向迁移、继续评估或取消。
逐组件评估：构建检查、完整性检查、可部署性检查（条件性组件映射）。
写入产物并执行就绪门控。
展示发现结果，按严重级别分组。
条件性修复。
写入最终状态，包括运行 git rev-parse HEAD 并写入 lastScanCommit（40 位 SHA）。
强制路由步骤。

MCP 工具：

绝对禁止：在 prereq 阶段不得运行 npm install、npm test、npx jest、pip install、pytest、dotnet build、dotnet restore、dotnet test、go mod download、cargo build 或任何包管理器安装、构建、测试命令。不得运行测试套件验证代码，应改为静态检查测试配置文件。该阶段是只读评估加纯静态验证。
唯一例外：两个经批准且需用户逐条同意的场景——代理在迁移/修复中修改过的代码，或代理在零代码路径中从零编写的代码；且仅在用户回答针对该具体命令的同意提示后，经用户确认的构建验证门控执行。此前的概括性同意无效。
完整流水线（步骤 1–8）无例外；所有提问直接进入步骤 1，具体问题作为发现结果的一部分（步骤 5）回答，而非提前回答。
评估不使用子代理，三轴评估为内联执行；例外是零代码路径脚手架（步骤 2）。
代码或破坏性修改需要 ask_user；出结果前最多提 3 个问题。直接入口时不重复编排器的意图问题。