需要创建、修改、检查或销毁云基础设施/SaaS 配置时：用…

适用于创建、修改、检查、销毁云基础设施或 SaaS 配置，以及把 Terraform、CloudFormation、CDK、Bicep、ARM 迁移到 Pulumi 的任务。

适用场景

解决思路

1. 先判断任务级别：Level 1 用 pulumi do 处理单个资源或多供应商 bootstrapping；Level 2 用 Pulumi 项目（Python、TypeScript、Go、C#、Java）处理多资源、循环/条件、可复用抽象或环境变体；Level 3 用 Pulumi Cloud 的 ESC、policy、deployments、drift、schedules 做治理、机密、托管和计划运行。
2. 若目录无现有 Pulumi 项目，而用户只要求创建单个 bucket，按 Level 1 处理，不要 scaffold 新项目。
3. 若请求是 provision 带子网的 VPC 和 Kubernetes cluster，从 Level 2 开始。
4. 若请求是对现有 stack 做夜间 drift detection，按 Level 3 处理。
5. 迁移现有基础设施代码（Terraform、CloudFormation、CDK、ARM、Bicep）时，直接路由到对应 migration skills，独立于级别模型。
6. 选择级别前先检查目录内容；能检查文件系统就检查。
7. 若无法检查文件系统（受限 agent 上下文），在运行任何 Pulumi 命令前询问用户目录中是否已有 Pulumi 项目；不要用 Pulumi 命令来发现，因为可能静默 provision 新 agent account。
8. Level 1 用 pulumi do 做一次性资源操作，如 Cloudflare DNS record、S3 bucket、GCP storage bucket、Azure VM、Datadog monitor、在 Cloudflare DNS 注册 Vercel deployment 域名；无需项目文件、目录布局或编程语言。
9. 记住 pulumi do 无状态：create 直接 provision 并打印 cloud-side identifier；read、patch、delete 按该 identifier 操作；不写 Pulumi state file，无资源图，无 ${...} wiring。
10. 用 pulumi do 连接两个资源时，捕获一个命令的输出，作为字面值传给下一个命令。
11. 若目录已有 Pulumi 项目（Pulumi.yaml），不要用 pulumi do 修改项目管理的资源；改动走 program。
12. 规范调用使用 npx pulumi <command>；它适用于任何有 Node.js 的机器，无需先前 Pulumi setup。
13. 若 pulumi 已在 PATH，npx shim 会遵它；否则从 npm registry 运行。
14. 在会触发 signup 的命令前，运行 npx pulumi version 确认 CLI 可用；它不触碰 Pulumi Cloud。
15. 确认资源 verbs（create、read、patch、delete、list）需要 CLI v3.243.0 或更新；npx pulumi 会获取当前 release，但 PATH 上已有 pulumi 可能较旧，需确认版本较新。
16. 注意 pulumi do 不写 Pulumi state，但通过 Pulumi registry 解析 provider 包，可能访问 Pulumi Cloud；在无保存凭据的 agent 上下文，首次 pulumi do 可能静默 provision 临时 agent account 并打印 claim banner。
17. 若 CLI 打印新账户和 claim URL 到 stderr，立即把 claim URL 展示给用户，并在最终响应再次展示；这是用户取得账户所有权的唯一方式。
18. 注意 access token 3 天过期，claim URL 30 天有效；展示 banner 报告的有效性。
19. 若同一会话中账户创建 banner 出现超过一次，凭据可能未缓存；agent credentials 写到 /tmp/.pulumi/credentials.json，claim metadata 写到 /tmp/.pulumi/agent-claim.json，但 claim URL 只在 banner 中；从每个 banner 捕获并在继续更多工作前展示最新一个。
20. 若认证失败，让用户运行 pulumi login；绝不回退到 pulumi login --local 或设置 PULUMI_CONFIG_PASSPHRASE，它们会静默改变用户设置。
21. Provider credentials 与 Pulumi Cloud credentials 分开；pulumi do 从 provider native CLI 相同环境变量读取，如 AWS_PROFILE、CLOUDFLARE_API_TOKEN、GOOGLE_APPLICATION_CREDENTIALS。
22. 若 provider credentials 未设置，在调用会访问云的命令前询问用户；若命令因 provider authorization error 失败，查找该 provider 所需 credentials/config 并让用户提供，不要猜。
23. 项目存在后，用 ESC（Level 3）持久保存 provider credentials。
24. 命令形状：pulumi do <pkg:mod:type> create [flags]；pulumi do <pkg:mod:type> read|patch|delete <id> [flags]；pulumi do <pkg:mod:type> list [flags]。
25. 解释 <pkg> 是 provider package（aws、azure-native、gcp、cloudflare、kubernetes 等）。
26. 解释 <mod> 是包内模块（compute、storage、dns）；当模块为 index 时可省略，例如 cloudflare:index/record:Record 调用为 cloudflare:Record。
27. <type> 是资源类型（VirtualMachine、Bucket、Record）。
28. <id> 是云 provider 对现有资源的标识，即 create 打印的 id；create 和 list 无位置参数；read、patch、delete 各恰好一个 <id>。
29. [flags] 设置资源属性，或通过 --input-file <file> 传 body file；按 Property input 规则组合 flags 和 files，并判断哪些值必须来自 file。
30. 没有 Pulumi logical name 可选；CLI 从资源类型派生内部名称，现有资源用云 id 寻址。
31. create：provision 资源并打印属性（含云 id）为 JSON；捕获 id 供以后 read、patch、delete；非交互传 --yes；read 和 list 从不需要 --yes。
32. read <id>：从 provider 获取资源当前状态并打印 JSON；不写任何东西。
33. patch <id>：读取当前 inputs，覆盖通过 flags 或 --input-file 传的顶层属性，就地更新资源；覆盖是浅的，未提属性保留。
34. patch 只更新，不能替换资源；要求替换的变更会失败而不是重建；命令要求输入 resource id 确认，非交互传 --yes。
35. delete <id>：从云移除资源；不可逆；调用前获得用户对具体资源的明确确认；仅在确认后才用 --yes，不要作为非交互默认。
36. pulumi do <pkg:mod:type> list [flags] 枚举现有实例，仅对实现 listing 的类型；Native providers 广泛支持；Terraform-bridged providers（aws、azure、gcp）也支持但覆盖因资源类型而异，不支持的类型会拒绝该 verb。
37. pulumi do <pkg:mod:function> [flags] 调用 provider 暴露的无状态函数。
38. Property input：属性来自 per-property flags、body file 或两者；flags 覆盖 body。
39. flags 只设置顶层标量属性；嵌套或结构化值（tags、nested blocks）必须来自 body file。
40. body 默认 PCL，写成扁平 name = value attributes；传 --input yaml（需 YAML converter plugin）使用 YAML。
41. 示例：写入 bucket.pcl，内容 bucket = "my-data" 和 tags = { Environment = "dev" }，然后运行 npx pulumi do aws:s3:Bucket create --yes --input-file bucket.pcl。
42. 为会话中新资源编写属性前，运行 npx pulumi package info <pkg> --module <mod> --resource <Type> 列出该资源的 inputs 和 outputs 及描述。
43. 仅在需要完整机器可读 schema 和 info 不展开的嵌套类型定义时，用 npx pulumi package get-schema <pkg>；大 provider 可达数十 MB，不要整读。
44. 属性名是 camelCase；flags 是 kebab-case 形式；用 npx pulumi package info <pkg>（无 module）列出 modules 和 resources，或浏览 https://www.pulumi.com/registry/ 发现名称。
45. Connecting resources：pulumi do 无 state 无 resource graph，所以命令间无 ${...} 引用语法；从一个命令 JSON output 读取字段并作为字面 flag 传下一个。
46. 示例 VPC -> Subnet：npx pulumi do aws:ec2:Vpc create --yes --cidr-block 10.0.0.0/16，从输出取 vpc-0abc123，运行 npx pulumi do aws:ec2:Subnet create --yes --vpc-id vpc-0abc123 --cidr-block 10.0.1.0/24。
47. 跨 provider 也如此：npx pulumi do random:RandomPet create --yes 输出如 artistic-bull，再 npx pulumi do aws:s3:Bucket create --yes --bucket assets-artistic-bull 得到全局唯一名称。
48. 当命令需要链未产生的值（如现有资源 id 或 API zone id），从 provider function、支持 list 的 list 或用户获取；不要发明。
49. Output：默认 create、read、patch 各向 stdout 写一个 JSON object 表示受影响资源；每次调用检查 exit code。
50. 输出 JSON 资源属性在顶层，旁边有 id 字段存云标识；没有嵌套 outputs object、没有 urn，不回显传入的 type token。
51. list 写 {id, name} 的 JSON 数组；function 写其声明结果 shape。
52. Graduating to Level 2：当一次性命令不再合适时 eject 到 Level 2；因为 pulumi do 不留 Pulumi state，它创建的资源是普通云资源，用 pulumi import 采纳到项目。
53. 从 Pulumi 项目内运行 pulumi import，为每个资源提供 full type token、logical name 和 create 返回的 cloud id；import 记录资源到 stack state，默认生成 program code。
54. 示例：npx pulumi import aws:s3/bucket:Bucket assets my-data；import type token 是 full pkg:mod/type:Type 形式，不是 pulumi do 的短 aws:s3:Bucket。
55. 把生成代码移入 program，然后在 program 中管理该资源而非 pulumi do；一次采纳多个用 bulk --file。
56. Level 2：用 Pulumi 项目（Python、TypeScript、Go、C#、Java）描述一组相关资源及依赖；任务涉及多资源、循环/条件、可复用抽象、环境特定变体时从 Level 2 开始，也适合 Level 1 ad-hoc 增长超过几个 CLI 调用时。
57. 匹配用户现有代码库语言；否则默认 TypeScript。
58. 写任何非平凡程序前，使用 skill pulumi-best-practices，涵盖 Output<T> 和 apply() 用法、直接传 outputs 作为 inputs、component 结构和 parenting、secrets hygiene、用 aliases 安全重构。
59. Bootstrapping：用模板最快：npx pulumi new aws-typescript 或 npx pulumi new gcp-go；模板设置工作目录、Pulumi.yaml、初始 stack、语言包 manifest、starter program。
60. 用 npx pulumi template list 浏览完整 catalog，用 npx pulumi template list --name <filter> 按名称过滤。
61. Core lifecycle：npx pulumi preview 显示将变化；npx pulumi up 应用；npx pulumi refresh 协调 state 与云现实。
62. 总是先运行 preview 再运行 up；preview 显示将变化且无成本。
63. pulumi destroy 拆除 stack 中每个资源；Pulumi docs 称 generally irreversible；未经用户明确确认 stack name 绝不调用。
64. Stacks and config：stack 是项目隔离实例；常见模式每环境一个 stack，命名 dev、staging、prod。
65. 运行 npx pulumi stack init dev、npx pulumi stack select prod、npx pulumi config set aws:region us-west-2、npx pulumi config set --secret dbPassword "..."。
66. 在 program 中用 SDK 的 Config 对象读取配置；确切操作名因语言而异，参考 https://www.pulumi.com/docs/iac/concepts/config/#code；用 skill pulumi-best-practices 了解 Output<T> / apply() 和 secrets hygiene。
67. Stack 只触碰其 state 中跟踪的资源，所以从 program 移除资源会导致 pulumi up 从云删除它；对不能失去的东西设置 protect: true。
68. 完整 IaC 参考见 https://www.pulumi.com/docs/iac/。
69. Level 3：用 Pulumi Cloud 做更多 than state；ESC 持有项目触碰的每个 provider 凭据并 brokering 到 runs and shells；还有 policy enforcement、hosted execution、drift detection、scheduled operations、audit。
70. ESC：ESC environment 组合 secrets 和配置，来源包括 cloud secret managers、OIDC-vended credentials、其他 ESC environments，成一个 resolved bundle 供 programs 和 stacks 消费。
71. 运行 npx pulumi env init my_org/aws/prod、npx pulumi env set my_org/aws/prod aws.region us-west-2、npx pulumi env open my_org/aws/prod、npx pulumi env run my_org/aws/prod -- aws s3 ls。
72. 在 provider 支持处，通过 OIDC 而不是 environment YAML 静态 keys 来 vend cloud credentials；OIDC trust policies、IdP registration、rotation patterns 在 pulumi-esc；用 skill pulumi-esc 而不是手写 ESC YAML。
73. env open 会解析并打印 live credentials；避免捕获其输出到 logs 或 transcripts；优先 env run -- <command>，将凭据注入子进程而非打印。
74. Policy：Pulumi Policies 在 preview 和 update 时对 resource graph 运行 policy packs；policy 可拒绝部署、要求批准、或用 findings 注释资源；执行发生在任何 cloud API 调用前。
75. 运行 npx pulumi policy new aws-typescript 从 policy template 脚手架 pack；npx pulumi policy publish my_org（pack name 来自 PulumiPolicy.yaml）；npx pulumi policy enable my_org/<pack-name> latest --policy-group production。
76. Policy 用 TypeScript 或 Python 编写，与 program 相同语言。
77. Deployments：Pulumi Deployments 在 Pulumi-managed infrastructure 运行 pulumi up、preview、destroy，而非本地；用于无需维护自己 runner 的 CI 和任何需要 server-side 运行的操作。
78. 运行 npx pulumi deployment run update --stack my_org/proj/prod；目标 stack 必须已存在；错误 --stack 值可能提示创建新 stack 而不是失败。
79. Drift detection：比较 stack state 与云并报告 diverged；本地临时检查运行 npx pulumi refresh --preview-only。
80. Pulumi Cloud 在 cron 上调度操作（UTC），包括 purpose-built drift kind：npx pulumi stack schedule new --kind drift --cron "0 0 * * *"；ESC environment secret rotation：npx pulumi env schedule new my_org/aws/prod --cron "0 0 1 * *"。
81. Schedule 是 session 结束后继续运行的 standing automation；创建前与用户确认 operation、cadence、stack；默认 detection-only，除非用户要求 remediation。
82. 两种无人干预 kind：--kind drift --auto-remediate 对检测 drift 运行 pulumi up；--kind ttl 在设定时间 destroy stack。
83. 不确定 CLI flag、command shape、resource property 时查而非猜；运行 npx pulumi <command> --help 查看 CLI 自身文档。
84. 完整参考、provider catalog、概念文档在 https://www.pulumi.com/docs。
85. Routing：当工作进入另一个 skill 覆盖深度领域，hand off 到该 skill 而非重新发明。
86. 按表加载：pulumi-best-practices 写任何非平凡 Level 2 program；pulumi-component 打包/消费 ComponentResource 抽象；pulumi-esc 定义 ESC environments、OIDC trust policies、rotation；pulumi-automation-api 嵌入 Pulumi 到另一程序（IDP、custom CI）；provider-upgrade 升级 stack 中 provider package version 无意外变更；package-usage 审计 org 中哪些 stacks 使用 package 及版本；pulumi-context-api 关系与影响分析跨 org infrastructure graph。
87. 迁移 skills：pulumi-terraform-to-pulumi、pulumi-cdk-to-pulumi、cloudformation-to-pulumi、pulumi-arm-to-pulumi。
88. Agent 只看到已安装 skills，所以引用 skill 可能不存在；pulumi-best-practices、pulumi-component、pulumi-esc、pulumi-automation-api、provider-upgrade、package-usage、pulumi-context-api 与本 skill 同 plugin，通常可用；迁移 skills 通过 pulumi-migration plugin 单独安装，可能不存在。
89. 当引用 skill 可用，加载它；当不可用，不要 stall 或视为错误，继续用本 skill 和 https://www.pulumi.com/docs，并告诉用户哪个 skill/plugin 深入覆盖该工作。

适用边界 · 注意事项

• 不适用于应用运行时通过 cloud SDK 读写数据的代码；那是应用代码，不是基础设施。
• 当目录已有 Pulumi 项目（Pulumi.yaml）时，不要用 pulumi do 修改该项目管理的资源；应改程序。
• 对 delete、pulumi destroy、--kind ttl、--auto-remediate、创建 schedule 等破坏性或持续自动化操作，未获用户对具体资源/stack/节奏的明确确认时不要执行。