Provider Resources
Implement Terraform Provider resources and data sources using the Plugin Framework...
Install
npx skills add hashicorp/agent-skills --skill provider-resources -g -a claude-code -y- Repository
- hashicorp/agent-skills911
- Category
- Design
- Updated
- 7d ago
- License
- MPL-2.0
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Implement Terraform Provider resources and data sources using the Plugin Framework: CRUD operations, schema design, plan modifiers and validators, not-found handling, waiters for eventually consistent APIs, import support, resource design principles, and required acceptance test coverage. Use when adding or changing a resource or data source, deciding whether an API concept should be a resource, wiring a resource to the provider's configured client, handling drift or resource-not-found, or reviewing a resource implementation before submission.
Terraform Provider Resources Implementation Guide
Overview
This guide covers developing Terraform Provider resources and data sources. Resources represent infrastructure objects that Terraform manages through Create, Read, Update, and Delete (CRUD) operations.
Use the Plugin Framework
for all net-new resources and data sources. Plugin SDKv2 is for maintaining
resources that already exist on it; do not write new code against it. A
provider can serve both during migration by muxing
(terraform-plugin-mux),
so adopting the Framework never requires a big-bang rewrite. To tell which
mode an existing provider is in, check go.mod: terraform-plugin-mux
present means it serves both SDKv2 and Framework code; only
terraform-plugin-sdk/v2 means SDKv2-only; only
terraform-plugin-framework means Framework-only. Be cautious about
migrating existing SDKv2 resources: the Framework distinguishes null from
zero values, so naive migrations change behavior for existing users (use the
provider-framework-migration skill, if available).
References (load when needed):
references/design-principles.md, what should (and should not) become a resource; data source semantics; relationship and async-task modelingreferences/retries-and-waiters.md, eventual consistency, retry patterns, and status/wait function structure
File Structure
Most providers keep every resource in a single package:
internal/provider/
├── provider.go # Provider schema + Configure
├── widget_resource.go # Resource implementation
├── widget_resource_test.go # Acceptance tests
├── widget_data_source.go # Data source (if applicable)
└── widget_data_source_test.go
