new-terraform-provider

new-terraform-provider 技能概览

new-terraform-provider 的作用

new-terraform-provider 技能可以帮你用 Plugin Framework 搭起一个新的 Terraform provider 骨架。它面向后端和基础设施开发者，目标是给出一个能直接开工的起点，而不是停留在理论解释。

适合谁使用

当你需要创建新的 provider 工作区、初始化 Go module、接好 main.go，并验证第一轮 build/test 流程时，就适合用 new-terraform-provider 技能。如果你已经知道要做什么 provider，只是希望把初始化步骤按正确顺序走完，它尤其有用。

它为什么有用

这个技能是以决策为导向的：它会告诉 agent 什么时候该停下来确认是否真的要创建新的工作区，也会推动一套务实的初始化顺序，而不是泛泛讨论。这样能减少 new-terraform-provider 安装过程中常见的阻碍，比如把文件生成到错误目录，或者跳过 build 和 test 检查。

如何使用 new-terraform-provider 技能

安装并激活它

先在你的 agent 环境里走 new-terraform-provider install 流程，然后把技能指向你要创建或引导初始化的 Terraform provider 项目。如果你已经在现有的 provider repo 里，技能应该先确认你是否真的想新建一个工作区。

给技能一个明确目标

想获得更好的 new-terraform-provider usage，请提供 provider 名称、预期的 registry 地址、module path，以及你是从零开始还是在扩展现有 repo。弱请求像是“帮我搭一个 Terraform provider”；更强的请求则是“创建一个名为 terraform-provider-acme 的新 provider 工作区，使用 registry.terraform.io/acme/widgets，并且先把 build 目标保持得尽量精简”。

按 repo 文件顺序阅读

先看 SKILL.md，再读 assets/main.go，了解预期的 provider 入口模式。这个示例 main 文件是这里最重要的支撑材料，因为它展示了 debug flag、provider server wiring，以及哪些 TODO 还需要替换成真实值。

把技能当作骨架，而不是完整 provider

这个技能的职责是帮你建立干净的引导路径：新建 Go module、添加 framework 依赖、写好 provider 入口、执行 go mod tidy、go build -o /dev/null 和 go test ./...。它不能替代 provider 设计工作，比如 schema 规划、CRUD 实现、认证策略，或者 acceptance test 的搭建。

new-terraform-provider 技能常见问题

new-terraform-provider 只适合全新的 repo 吗？

不是。它最适合新的工作区，但如果你想在更大的 mono-repo 里搭一个干净的 Terraform 专用模块边界，它也能帮上忙。如果你已经在一个 provider 工作区里，技能应该先问清楚再决定是否创建另一个。

它和普通 prompt 的主要区别是什么？

普通 prompt 常常会漏掉关键初始化步骤，或者生成一个不符合 Plugin Framework 模式的 main.go。new-terraform-provider 技能能给你更稳定的安装流程，以及从空目录到可编译 provider binary 的更清晰步骤。

这适合新手吗？

适合，前提是你的目标是带着引导启动一个 provider 项目。它不能替代对 Terraform provider 架构的学习，但它能降低第一次初始化的摩擦，减少漏掉基础 module 和 build 步骤的概率。

什么情况下不该用它？

如果你已经有成熟的 provider 代码库，只是要新增一个 resource、修一个 schema，或者重构现有 binary，那就不要用 new-terraform-provider。在这些情况下，这个技能会额外引入你并不需要的工作区搭建步骤。

如何改进 new-terraform-provider 技能

一开始就补全缺失值

最好的 new-terraform-provider skill 输出，来自那些明确给出 provider address、module path、package layout，以及是否需要 debug 支持的输入。如果这些都留空，agent 往往只能自己猜，比如用 example.org/terraform-provider-demo 之类的占位地址，这通常会带来后续清理工作。

立刻替换占位符

仓库示例在 assets/main.go 里仍然保留了以 TODO 驱动的占位内容，尤其是 provider address 和 release-time version wiring 相关部分。第一次跑完之后，就应该在你认定骨架完成之前把这些值换掉，否则 build 可能已经通过，但 binary 仍然指向一个演示身份。

按技能的方式验证骨架

只有当新的工作区里 go mod tidy、go build -o /dev/null 和 go test ./... 都通过时，这套流程才算真正完成。如果任何一步失败，先修正 module path、provider import path 或 package layout，再去加 resource 或 acceptance test。

从骨架继续迭代到真实的 provider 设计

等工作区稳定下来后，就继续要下一层内容：provider schema、认证、resource 布局以及文档生成。到那时，new-terraform-provider for Backend Development 的价值会更明显，因为它先把地基打稳，再把实现细节留给下一轮聚焦处理。