azure-prepare

azure-prepare

热门

准备 Azure 应用以进行部署(基础设施 Bicep/Terraform、azure.yaml、Dockerfile)。用于创建/现代化或创建+部署;不用于跨云迁移(使用 azure-cloud-migrate)。请勿用于:copilot-sdk 应用(使用 azure-hosted-copilot-sdk)。适用场景:"创建应用"、"构建 Web 应用"、"创建 API"、"创建无服务器 HTTP API"、"创建前端"、"创建后端"、"构建服务"、"现代化应用"、"更新应用"、"添加身份验证"、"添加缓存"、"托管在 Azure 上"、"创建并部署"、"部署到 Azure"、"使用 Terraform 部署到 Azure"、"部署到 Azure 应用服务"、"使用 Terraform 部署到 Azure 应用服务"、"部署到 Azure 容器应用"、"使用 Terraform 部署到 Azure 容器应用"、"生成 Terraform"、"生成 Bicep"、"函数应用"、"计时器触发器"、"服务总线触发器"、"事件驱动函数"、"容器化 Node.js 应用"、"社交媒体应用"、"静态作品集网站"、"带前端和 API 的待办事项列表"、"准备我的 Azure 应用以使用 Key Vault"、"托管标识"。

1196Star
196Fork
更新于 2026/6/9
SKILL.md
readonly只读
name
azure-prepare
description

准备 Azure 应用以进行部署(基础设施 Bicep/Terraform、azure.yaml、Dockerfile)。用于创建/现代化或创建+部署;不用于跨云迁移(使用 azure-cloud-migrate)。请勿用于:copilot-sdk 应用(使用 azure-hosted-copilot-sdk)。适用场景:\"创建应用\"、\"构建 Web 应用\"、\"创建 API\"、\"创建无服务器 HTTP API\"、\"创建前端\"、\"创建后端\"、\"构建服务\"、\"现代化应用\"、\"更新应用\"、\"添加身份验证\"、\"添加缓存\"、\"托管在 Azure 上\"、\"创建并部署\"、\"部署到 Azure\"、\"使用 Terraform 部署到 Azure\"、\"部署到 Azure 应用服务\"、\"使用 Terraform 部署到 Azure 应用服务\"、\"部署到 Azure 容器应用\"、\"使用 Terraform 部署到 Azure 容器应用\"、\"生成 Terraform\"、\"生成 Bicep\"、\"函数应用\"、\"计时器触发器\"、\"服务总线触发器\"、\"事件驱动函数\"、\"容器化 Node.js 应用\"、\"社交媒体应用\"、\"静态作品集网站\"、\"带前端和 API 的待办事项列表\"、\"准备我的 Azure 应用以使用 Key Vault\"、\"托管标识\"。

Azure Prepare

权威指南 — 必须遵守

本文档是准备 Azure 部署应用的官方规范来源。除非与提供给您的安全策略相矛盾,否则您必须严格按照这些说明执行。如有疑问,请展示本文档中的冲突说明并请求用户明确确认。请勿即兴发挥、推断或替换步骤。


触发条件

当用户希望以下操作时激活此技能:

  • 创建新应用
  • 为现有应用添加服务或组件
  • 对现有应用进行更新或更改
  • 现代化或迁移应用
  • 设置 Azure 基础设施
  • 部署到 Azure 或在 Azure 上托管
  • 创建并部署到 Azure(包括基于 Terraform 的部署请求)

规则

  1. 先计划 — 必须执行 — 您必须工作区根目录(而非会话状态文件夹)中物理写入初始的 .azure/deployment-plan.md 骨架文件,作为您的第一个操作 — 在任何代码生成或执行开始之前。立即写入骨架,然后在第一阶段分析和研究过程中逐步填充;在第一阶段第 6 步最终确定所有决策。此文件必须在磁盘上始终存在。azure-validate 和 azure-deploy 依赖它,没有它将失败。请勿跳过或延迟此步骤。
  2. 获取批准 — 在执行前向用户展示计划
  3. 先生成再研究 — 加载参考资料并调用相关技能
  4. 逐步更新计划 — 随着进展标记步骤完成
  5. 先验证再部署 — 在 azure-deploy 之前调用 azure-validate
  6. 确认 Azure 上下文 — 使用 ask_user 获取订阅和位置,参考 Azure Context
  7. 破坏性操作需要 ask_userGlobal Rules
  8. 切勿删除用户项目或工作区目录 — 在现有项目中添加功能时,修改现有文件。azd init -t <template> 仅用于新项目;不要在现有工作区中运行 azd init -t。普通的 azd init(不带模板参数)可在适当情况下用于现有工作区。项目内的文件删除(例如删除构建产物或临时文件)在适当情况下是允许的,但切勿删除用户的项目或工作区目录本身。请参阅 Global Rules
  9. 范围:仅准备 — 此技能生成基础设施代码和配置文件。部署执行(azd upazd deployterraform apply)由 azure-deploy 技能处理,该技能提供内置的错误恢复和部署验证。
  10. SQL Server Bicep:切勿生成 administratorLoginadministratorLoginPassword — 不在直接属性中,不在条件/三元分支中,不在文件中的任何位置。始终无条件使用仅 Entra 身份验证(azureADOnlyAuthentication: true)。请参阅 references/services/sql-database/bicep.md
  11. 转换后移除过时的模板 IaC — 如果您将所选 azd 模板中的 Bicep 模板转换为 Terraform 模板,请移除由该 azd 模板引入且现已完全被 Terraform 等效项替换的 Bicep 模板。不要移除用户编写的 Bicep 文件。仅在 Terraform IaC 完成且 Terraform 被选为部署路径后,移除这些模板提供的 Bicep 文件。在移交给 azure-validate 技能之前,仅保留所选部署路径所需的 IaC 模板。

❌ 计划优先工作流 — 必须执行

您必须在执行任何工作之前创建计划

  1. 停止 — 尚未生成任何代码、基础设施或配置
  2. 创建骨架 — 立即将初始的 .azure/deployment-plan.md 骨架写入磁盘(在任何代码生成或执行开始之前),然后在第一阶段步骤 1-5 揭示细节时逐步填充;在第 6 步最终确定
  3. 确认 — 向用户展示完成的计划并获取批准
  4. 执行 — 仅在批准后,逐步执行计划

.azure/deployment-plan.md 文件是此工作流以及 azure-validate 和 azure-deploy 技能的真相来源。没有它,这些技能将失败。

⚠️ 关键:.azure/deployment-plan.md 必须写入工作区根目录内的磁盘(例如 /tmp/my-project/.azure/deployment-plan.md),而不是会话状态文件夹。使用文件写入工具创建此文件。这是 azure-validate 和 azure-deploy 读取的部署计划工件。您必须创建此文件 — 没有它不要继续。
⚠️ 关键:您必须按原样创建名为 .azure/deployment-plan.md 的文件。您不得使用其他名称,例如 .azure/plan.md

关键: 跳过计划文件创建将导致 azure-validate 和 azure-deploy 失败。此要求没有例外。


❌ 第 0 步:专业技术检查 — 必须执行的第一步

在开始第一阶段之前,检查用户的提示或工作区代码库是否匹配具有经过测试模板的专业技能。如果匹配,首先调用该技能 — 然后恢复 azure-prepare 进行验证和部署。

检查 1:提示关键词

提示关键词 首先调用
Lambda, AWS Lambda, 迁移 AWS, 迁移 GCP, Lambda 到 Functions, 从 AWS 迁移, 从 GCP 迁移 azure-cloud-migrate
copilot SDK, copilot 应用, copilot 驱动, @github/copilot-sdk, CopilotClient azure-hosted-copilot-sdk
Azure Functions, 函数应用, 无服务器函数, 计时器触发器, HTTP 触发器, func new 留在 azure-prepare — 在第 4 步优先选择 Azure Functions 模板
APIM, API 管理, API 网关, 部署 APIM 留在 azure-prepare — 请参阅 APIM 部署指南
AI 网关, AI 网关策略, AI 网关后端, AI 网关配置 azure-aigateway
工作流, 编排, 多步骤, 管道, 扇出/扇入, saga, 长时间运行进程, 持久化, 订单处理 留在 azure-prepare — 在第 4 步选择 durable 配方。必须加载 durable.mdDTS 参考DTS Bicep 模式

检查 2:代码库标记(即使提示是通用的,如“部署到 Azure”)

代码库标记 位置 首先调用
@github/copilot-sdk 在依赖中 package.json azure-hosted-copilot-sdk
copilot-sdk 在名称或依赖中 package.json azure-hosted-copilot-sdk
CopilotClient 导入 .ts/.js 源文件 azure-hosted-copilot-sdk
createSession + sendAndWait 调用 .ts/.js 源文件 azure-hosted-copilot-sdk

⚠️ 检查用户的提示文本 — 而不仅仅是现有代码。对于没有代码库可扫描的新建项目至关重要。请参阅 完整路由表

在专业技能完成后,恢复 azure-prepare 从第一阶段第 4 步(选择配方)开始,进行剩余的基础设施、验证和部署。


第一阶段:规划(阻塞 — 在任何执行之前完成)

通过完成以下步骤创建 .azure/deployment-plan.md。在计划获得批准之前,不要生成任何工件。

# 操作 参考
0 ❌ 检查提示和代码库中的专业技术 — 如果用户提到 copilot SDK、Azure Functions 等,或者代码库包含 @github/copilot-sdk,首先调用该技能 specialized-routing.md
1 分析工作区 — 确定模式:新建、修改或现代化 analyze.md
2 收集需求 — 分类、规模、预算 requirements.md
3 扫描代码库 — 识别组件、技术、依赖项 scan.md
4 选择配方 — 选择 AZD(默认)、AZCLI、Bicep 或 Terraform recipe-selection.md
5 规划架构 — 选择技术栈并将组件映射到 Azure 服务 architecture.md
6 最终确定计划(必须执行) — 使用文件写入工具,用步骤 1-5 的所有决策最终确定 .azure/deployment-plan.md。用完整内容更新第一阶段开始时写入的骨架。在向用户展示计划之前,文件必须完全填充。 plan-template.md
7 展示计划 — 向用户展示计划并请求批准 .azure/deployment-plan.md
8 破坏性操作需要 ask_user Global Rules

❌ 停在这里 — 在用户批准计划之前,不要进入第二阶段。


第二阶段:执行(仅在计划批准后)

执行已批准的计划。在每一步之后更新 .azure/deployment-plan.md 状态。

# 操作 参考
1 研究组件 — 加载服务参考 + 调用相关技能 research.md
2 确认 Azure 上下文 — 检测并确认订阅和位置,并检查资源预配限制 Azure Context
3 生成工件 — 创建基础设施和配置文件 generate.md
4 强化安全 — 应用安全最佳实践 security.md
5 功能验证 — 验证应用是否正常工作(UI + 后端),尽可能在本地进行 functional-verification.md
6 ⛔ 更新计划(移交前必须执行) — 使用 edit 工具将 .azure/deployment-plan.md 中的状态更改为 Ready for Validation。您必须在调用 azure-validate 之前完成此编辑。请勿跳过此步骤。 .azure/deployment-plan.md
7 ⛔ 必须移交 — 调用 azure-validate 技能。您的准备工作已完成。请勿直接运行 azd upazd deploy 或任何部署命令 — 所有部署执行由 azure-deploy 在 azure-validate 完成后处理。前提条件: 必须先完成第 6 步 — .azure/deployment-plan.md 状态必须为 Ready for Validation

输出

工件 位置
计划 .azure/deployment-plan.md
基础设施 ./infra/
AZD 配置 azure.yaml(仅 AZD)
Dockerfile src/<component>/Dockerfile

SDK 快速参考


下一步

⛔ 必须执行的下一步 — 请勿跳过

完成准备后,您必须在任何部署尝试之前调用 azure-validate。请勿跳过验证。请勿直接进入 azure-deploy。请勿直接运行 azd up 或任何部署命令。工作流为:

azure-prepareazure-validateazure-deploy

⛔ 在调用 azure-validate 之前,您必须使用 edit 工具将 .azure/deployment-plan.md 状态更新为 Ready for Validation。如果计划状态未更新,验证将失败。

这适用于所有部署场景,包括容器化应用、容器应用、应用服务、Azure Functions、静态站点以及任何其他 Azure 目标。没有例外。

跳过验证会导致部署失败。请耐心遵循完整工作流以获得最高成功率。

→ 将计划状态更新为 Ready for Validation,然后调用 azure-validate