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 'what' and 'when' clause, targeting a very specific niche in Terraform provider development. Its main weakness is that it could be more specific about the concrete actions it enables and could include more natural trigger term variations that developers might use when seeking this skill.
Suggestions
Add more specific concrete actions, e.g., 'Define action functions, register before/after hooks, handle action errors, implement idempotent side effects'.
Include additional trigger term variations users might naturally say, such as 'terraform plugin', 'provider development', 'resource hooks', 'side effects', or 'ephemeral operations'.
| 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 'terraform plugin', 'provider development', 'resource actions', 'hooks', or 'side effects'. | 2 / 3 |
Distinctiveness Conflict Risk | Very specific niche targeting Terraform Provider Plugin Framework actions at lifecycle events — this is unlikely to conflict with general Terraform skills, IaC skills, or other provider development skills due to the precise scoping to '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 (error handling, pagination, retry logic). The code examples are partially actionable but mix real framework APIs with placeholder/hypothetical code, reducing copy-paste readiness. The content would benefit greatly from being trimmed to ~40% of its current size and split into a concise overview with linked reference files.
Suggestions
Cut the content by at least 50% — remove generic programming advice (error handling patterns, pagination, retry logic) and deduplicate the schema issues section with the schema validation checklist and pre-submission checklist.
Make code examples fully concrete and executable by using real terraform-plugin-framework types and method signatures, or clearly mark which parts are project-specific placeholders.
Add an explicit numbered development workflow at the top (e.g., '1. Create action file → 2. Define schema → 3. Implement Invoke → 4. Write tests → 5. Add docs → 6. Validate with checklist') to provide clear sequencing.
Split into SKILL.md (overview + quick start + workflow) with references to separate files like SCHEMA_PATTERNS.md, TESTING.md, and DOCUMENTATION.md for detailed content.
| 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, retry logic) and includes generic patterns like 'Handle partial failures gracefully' that add no specific value. | 1 / 3 |
Actionability | Code examples are present and somewhat concrete (schema definition, invoke method, test pattern, polling), but many are incomplete templates with placeholder types like `actionType`, `actionModel`, and `wait.WaitForStatus` that may not correspond to real framework APIs. The 'Common Action Patterns' section is entirely abstract bullet points with no code. Several examples mix real and hypothetical APIs. | 2 / 3 |
Workflow Clarity | The document covers the full lifecycle (implement → test → document → changelog → submit) and includes a pre-submission checklist, but the overall workflow sequence is implicit rather than explicitly ordered. There's no clear 'Step 1, Step 2, Step 3' development workflow, and validation checkpoints are scattered across sections rather than integrated into a coherent flow. | 2 / 3 |
Progressive Disclosure | The document has clear section headers and some external references, but it's monolithic — all content is inline in one large file. The 'Common Action Patterns' section, testing details, documentation standards, and sweep functions could all be split into separate reference files. The references section at the end links to external docs but doesn't organize internal content across files. | 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.
b129bb5
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.