running-stabilization-loop

Use after major refactors or risky infrastructure changes to run iterative stabilization loops in kube-test: clean state, run the v3 matrix (k3s/rke2, autoscaler, leapmicro/microos, multi-arch), proactively debug failures over SSH/journalctl, apply fixes, retest until green, then validate upgrade paths from the latest tag to current staging.

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Medium

Suggest reviewing before use

Quality

Content

77%Weight 40%Scale 1-3

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

The body is highly actionable with a clear, well-validated multi-step workflow. Its weaknesses are conciseness (repeated gate blocks and a duplicated buddy template) and progressive disclosure (a monolithic file with no external references or split-out detail).

Suggestions

De-duplicate the terraform/tofu validation gate block: define it once and reference it from Step 6 instead of repeating it verbatim.

Move the large buddy prompt template and the known-high-frequency-failure catalog into separate reference files (e.g. references/buddy-prompt.md, references/known-failures.md) and link to them from the body, improving progressive disclosure and token efficiency.

Factor the shared SSH invocation flags into a single defined snippet or alias to avoid restating the full -o IdentitiesOnly=yes -i ... options in multiple steps.

Dimension	Reasoning	Score
Conciseness	The body is largely lean executable commands with no concept-explaining fluff, but it repeats the terraform/tofu validation gate block verbatim in Step 1 and Step 6 and the buddy prompt template duplicates guidance also covered in the steps, so it could be tightened — fitting the mostly-efficient-but-could-be-tightened anchor rather than the every-token-earns-its-place anchor at 3.	2 / 3
Actionability	Guidance is fully executable — exact bash commands, absolute file paths, and specific hcloud/terraform/journalctl invocations that are copy-paste ready — matching the fully-executable anchor rather than the pseudocode/incomplete anchor at 2.	3 / 3
Workflow Clarity	A clear 9-step sequence with a dot-graph, explicit validation gates (terraform/tofu validate), and a fix -> targeted rerun -> full regression rerun feedback loop plus an abort/cleanup shortcut, matching the explicit-checkpoints-with-feedback-loops anchor rather than the validation-gaps anchor at 2.	3 / 3
Progressive Disclosure	No bundle files exist and all detail (buddy template, nine steps, known-failure catalog) is inline in a ~350-line monolithic file that is well-sectioned but offers no one-level-deep references or navigation, fitting the some-structure-but-inline-content anchor; it is above 1 because sections are organized, but below 3 because nothing is split out and the file far exceeds the under-50-line simple-skill allowance.	2 / 3
	Total	10 / 12 Passed

Description

85%Weight 40%Scale 1-3

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 strong: it states concrete capabilities and an explicit use-when trigger with a distinctive niche. Its only weakness is trigger-term quality, which relies on project-internal jargon rather than broad natural-language variations a user would naturally say.

Suggestions

Broaden trigger terms with natural-language phrasings a user might actually say (e.g., "stabilize the cluster after a refactor", "run the full test matrix and fix failures") alongside the existing kube-test/v3 jargon.

Consider trimming the parenthetical matrix detail (k3s/rke2, autoscaler, leapmicro/microos, multi-arch) in the description and relegating it to the body, since it inflates the description without adding trigger discoverability.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — "clean state, run the v3 matrix (k3s/rke2, autoscaler, leapmicro/microos, multi-arch), proactively debug failures over SSH/journalctl, apply fixes, retest until green, then validate upgrade paths" — matching the multiple-specific-actions anchor rather than the single-domain anchor at 2.	3 / 3
Completeness	Explicitly answers both what (run iterative stabilization loops with the listed debug/fix/retest/upgrade actions) and when ("Use after major refactors or risky infrastructure changes"), matching the explicit-trigger anchor; the when is stated, not merely implied, so it is above 2.	3 / 3
Trigger Term Quality	Relevant triggers exist ("after major refactors or risky infrastructure changes", "stabilization loops") but they lean on internal project jargon ("kube-test", "v3 matrix", "leapmicro/microos") without broad natural-language variations a user would commonly say, fitting the "some relevant keywords but missing common variations" anchor rather than the broad-coverage anchor at 3.	2 / 3
Distinctiveness Conflict Risk	The niche is highly specific (kube-test v3 stabilization matrix across k3s/rke2, autoscaler, multi-arch, and upgrade paths), giving it distinct triggers unlikely to fire for unrelated skills, matching the clear-niche anchor rather than the overlapping anchor at 2.	3 / 3
	Total	11 / 12 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: mysticaltech/terraform-hcloud-kube-hetzner
Path: .claude/skills/running-stabilization-loop/SKILL.md
Commit: a8b696d

Reviewed: 11 days 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.