Implement Terraform Provider actions using the Plugin Framework. Use when developing imperative operations that execute at lifecycle events (before/after create, update, destroy).
95
55%
Does it follow best practices?
Impact
99%
6.18xAverage score across 15 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./terraform/provider-development/skills/provider-actions/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is well-structured with a clear 'Use when' clause that explicitly defines the trigger context. It carves out a distinct niche within Terraform provider development. However, it could benefit from listing more specific concrete actions and including additional natural trigger terms that users might use when seeking this skill.
Suggestions
Add more specific concrete actions, e.g., 'Define action functions, register before/after lifecycle hooks, handle action errors, implement idempotent operations'.
Include additional natural trigger terms users might say, such as 'provider hooks', 'pre-create action', 'post-destroy hook', 'terraform provider lifecycle', or 'custom provider actions'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Terraform Provider, Plugin Framework) and a general action (implement actions/imperative operations at lifecycle events), but doesn't list multiple specific concrete actions like 'define action functions, register lifecycle hooks, handle error responses'. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement Terraform Provider actions using the Plugin Framework) and 'when' (Use when developing imperative operations that execute at lifecycle events before/after create, update, destroy) with explicit trigger guidance. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'Terraform Provider', 'Plugin Framework', 'lifecycle events', 'create, update, destroy', but misses common variations users might say such as 'provider actions', 'terraform hooks', 'pre-create', 'post-destroy', or 'ephemeral operations'. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche targeting Terraform Provider actions with the Plugin Framework at lifecycle events — this is unlikely to conflict with general Terraform skills, IaC skills, or other provider development skills due to the precise scoping around 'actions' and 'lifecycle events'. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is comprehensive in coverage but suffers from significant verbosity and redundancy, explaining many patterns Claude already understands (Go error handling, pagination, basic testing). The code examples are partially actionable but use generic placeholder types rather than fully executable snippets. The content would benefit greatly from being split into a concise overview with references to detailed sub-files, and from removing explanations of concepts Claude already knows.
Suggestions
Reduce content by at least 50% by removing explanations of concepts Claude already knows (basic error handling, pagination, Go testing patterns) and eliminating redundancy between the schema issues section and the schema validation checklist.
Make code examples fully concrete by using a specific real-world action (e.g., an EC2 instance reboot action) as a running example throughout, rather than generic placeholder types.
Split into a concise SKILL.md overview (~100 lines) with references to separate files for detailed topics: SCHEMA.md, TESTING.md, PATTERNS.md, DOCUMENTATION.md.
Add an explicit numbered workflow at the top showing the end-to-end development sequence with validation gates (e.g., 'Step 1: Create action file → Step 2: Define schema → Step 3: go build to validate types → Step 4: Implement Invoke → ...').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~400+ lines, with significant redundancy (e.g., schema validation checklist repeats schema issues section, pre-submission checklist repeats earlier points). It explains many concepts Claude already knows (error handling patterns, pagination, basic Go testing) and includes generic patterns (batch operations, command execution) that are described abstractly rather than providing unique value. | 1 / 3 |
Actionability | Code examples are provided for schema definition, invoke method, error handling, polling, and testing, which is good. However, many examples use placeholder/generic types (e.g., `actionType`, `actionModel`, `ResourceType`) that aren't fully executable, and several sections like 'Common Action Patterns' provide only abstract descriptions without concrete code. The polling example references a `wait` package with unclear provenance. | 2 / 3 |
Workflow Clarity | The skill covers the full lifecycle (schema → invoke → test → document → changelog) but lacks a clear sequential workflow tying these together. The pre-submission checklist provides validation steps, but there are no explicit feedback loops for error recovery during development. The document reads more like a reference manual than a guided workflow. | 2 / 3 |
Progressive Disclosure | The content is a monolithic document with no bundle files to offload detailed content to. Sections like Common Action Patterns, Testing, and Documentation Standards could each be separate reference files. External links are provided but all detailed content is inline, making the skill very long. The structure has clear headings but everything is in one large file. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
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.