infrastructure-work-conventions

Defines the conventions to follow when working with infrastructure and specifically terraform code.

Quality

63%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/infrastructure-work-conventions/SKILL.md

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is well-structured and appropriately brief for a conventions skill: it defines repository boundaries, a validation-gated workflow with a feedback loop, and a single clearly signaled verification script. Its main weakness is actionability — the workflow steps reference checks and applies without giving the concrete commands to run.

Suggestions

Make the workflow steps executable by naming the commands, e.g. step 1: "Run `bash scripts/check.sh`", step 3: "Run `terraform plan` to review, then `terraform apply`", instead of "check that everything is still working" and "apply your changes".

State the check mechanism inline in the workflow ("1. Run @scripts/check.sh") rather than deferring it to the trailing "How to verify infrastructure code" section, so each step is self-contained.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence (e.g. "Never add IAM bindings or service account changes to wheel-of-meeting here"), with only minor throat-clearing padding ("it's important to maintain a consistent style", "It is important to keep terraform valid and working") that could be trimmed. It is not a 5 because of those sentences, and not a 3 because nothing over-explains concepts Claude already knows.	4 / 5
Actionability	Concrete pointers exist (fresh branch, @scripts/check.sh as the verification entry point, commit, push), but the workflow steps themselves are not executable: "check that everything is still working" and "apply your changes" give no actual commands (no terraform validate/plan/apply). This matches the 'some concrete guidance but incomplete; missing key details' anchor rather than the mostly-executable level 4.	3 / 5
Workflow Clarity	A clear numbered sequence is present with explicit validation checkpoints (step 1 check, step 3 re-verify), a fix-and-retry feedback loop ("If something breaks, fix it and try again"), and a stop-and-ask condition ("if step 1 fails, DO NOT continue"), so the destructive-operation cap does not apply. It falls short of 5 because the validation mechanism is only revealed in a later section and "apply your changes" is ambiguous about what to actually run.	4 / 5
Progressive Disclosure	The skill is under 50 lines with no need for external reference files, and per the simple-skill guidance well-organized sections suffice: Repository setup, Workflow, and How to verify are cleanly separated, with one clearly signaled one-level-deep reference (@scripts/check.sh). It is not a 4 because there are no organization gaps to point to.	5 / 5
	Total	16 / 20 Passed

Description

40%Weight 40%Scale 1-5

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 names a clear domain (infrastructure/Terraform) but describes no concrete actions and entirely lacks a 'Use when...' trigger clause, leaving both specificity and completeness weak. Its main strength is the distinct terraform niche, which keeps conflict risk low.

Suggestions

Add an explicit trigger clause, e.g. "Use when working on Terraform (.tf) files, infrastructure-as-code changes, or repo setup for the wheel-of-meeting/kh-gcp-seed projects."

Name 1-3 concrete capabilities instead of "conventions to follow", e.g. "Defines repository boundaries for IAM vs application infrastructure, the branch-then-verify-then-apply workflow, and the check.sh validation entry point."

Include natural trigger variations users would actually type: "Terraform", ".tf files", "IaC", "infrastructure code".

Dimension	Reasoning	Score
Specificity	The description names the domain ("infrastructure and specifically terraform code") but its only action is the generic "Defines the conventions to follow" — no concrete capability is listed, matching the 'names the domain but actions are minimal or generic' anchor. It is not a 3 because not even one concrete action is enumerated.	2 / 5
Completeness	The 'what' is vague ("Defines the conventions to follow") and there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the guidelines; this fits the 'has a vague what and no when' anchor. It is not a 3 because the 'what' itself is generic rather than clear.	2 / 5
Trigger Term Quality	"infrastructure" and "terraform" are natural terms a user would say, but the description is missing common variations and synonyms ("Terraform files", ".tf", "IaC", "infra"), matching the 'some relevant keywords but missing common variations' anchor. It is not a 4 because only two terms are present with no broader coverage.	3 / 5
Distinctiveness Conflict Risk	"terraform code" carves a distinct niche with minor overlap risk only against closely related infra or CI skills. It is not a 5 because the bare domain wording provides no distinct trigger phrases that would fully separate it from neighboring skills.	4 / 5
	Total	11 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
referenced_paths_exist	Referenced path issues: 1 missing	Warning

	Total	15 / 16 Passed

Repository: koenighotze/wheel-of-meeting
Path: .claude/skills/infrastructure-work-conventions/SKILL.md
Commit: 4aca8e3

Reviewed: 16 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

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.