Implement Terraform Provider resources and data sources using the Plugin Framework. Use when developing CRUD operations, schema design, state management, and acceptance testing for provider resources.
94
71%
Does it follow best practices?
Impact
96%
1.33xAverage score across 16 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./terraform/provider-development/skills/provider-resources/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly identifies a specific technical domain (Terraform Provider development with the Plugin Framework), lists concrete actions, and includes an explicit 'Use when' clause with relevant trigger terms. The description is concise, uses third-person voice, and would be easily distinguishable from other skills in a large skill library.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: implementing resources and data sources, CRUD operations, schema design, state management, and acceptance testing. These are all concrete, well-defined activities in the Terraform provider development domain. | 3 / 3 |
Completeness | Clearly answers both 'what' (implement Terraform Provider resources and data sources using the Plugin Framework) and 'when' (Use when developing CRUD operations, schema design, state management, and acceptance testing for provider resources). The 'Use when' clause is explicit. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords a developer would use: 'Terraform Provider', 'Plugin Framework', 'CRUD operations', 'schema design', 'state management', 'acceptance testing', 'resources', 'data sources'. These are terms developers naturally use when working on Terraform providers. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — 'Terraform Provider' and 'Plugin Framework' create a very specific niche. This is unlikely to conflict with general infrastructure-as-code skills, generic testing skills, or other development skills due to the precise domain targeting. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides highly actionable, executable Go code covering the full lifecycle of Terraform provider resource development. However, it is severely over-long and monolithic — it reads more like a comprehensive reference manual than a concise skill file. Much of the content (basic CRUD patterns, error handling idioms, test boilerplate) is knowledge Claude already possesses, and the lack of any bundle files means everything is crammed into one enormous document.
Suggestions
Split into multiple files: keep SKILL.md as a concise overview with the file structure and key patterns, then move CRUD examples to CRUD.md, testing patterns to TESTING.md, schema design details to SCHEMA.md, and link to them clearly.
Remove the SDKv2 resource pattern entirely if the skill is about the Plugin Framework, or move it to a separate MIGRATION.md file — having both doubles the content without clear justification.
Cut explanatory text that Claude already knows (e.g., 'Resources represent infrastructure objects that Terraform manages through Create, Read, Update, and Delete (CRUD) operations') and reduce code examples to one canonical pattern with brief notes on variations.
Add explicit workflow steps with validation checkpoints, e.g., '1. Implement Create+Read → compile → 2. Write basic acceptance test → run → 3. Add Update/Delete → compile → 4. Add disappears test → run all tests'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | This is extremely verbose at 400+ lines, with massive amounts of boilerplate code that Claude already knows how to write. The overview explains what CRUD operations are, includes both SDKv2 and Plugin Framework patterns (doubling content), and provides exhaustive code for every operation when patterns could be shown once with variations noted briefly. | 1 / 3 |
Actionability | The code examples are fully executable, complete, and copy-paste ready. Every CRUD operation, test pattern, finder function, and state waiter has concrete, working Go code with proper imports and error handling patterns. | 3 / 3 |
Workflow Clarity | The pre-submission checklist provides a good sequence, and the testing section shows how to compile and run tests. However, there are no explicit validation checkpoints within the development workflow itself — no 'compile after each CRUD operation' or 'validate schema before writing tests' feedback loops for this multi-step development process. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no bundle files to offload content to. The entire reference for CRUD operations, schema design, state management, testing, error handling, and documentation is inlined in a single massive file. Content like the attribute types table, validator examples, and test helpers should be in separate reference files. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (600 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
43ca9b0
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.