CtrlK
BlogDocsLog inGet started
Tessl Logo

homelab-safe-ops

Encodes read-first, no-destroy-by-default safety constraints for all homelab automation.

57

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/homelab-safe-ops/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

78%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.

A lean, well-structured safety-policy skill: terse rules, explicit confirmation/backup/staging checkpoints, and unusually dense verified environment facts (IPs, SSH quirks, the 5400 RPM bottleneck, router DNS NXDOMAIN behavior) that Claude could not know otherwise. The only weaknesses are light meta-padding in the intro/Invocation sections and no explicit consolidated operating sequence.

DimensionReasoningScore

Conciseness

Rules are terse imperatives ("Read before write.", "Never delete, stop, or remove a resource unless the user has explicitly requested it by name") and the Environment Facts pack non-obvious specifics with no explanations of concepts Claude already knows. Minor trimmable meta-text remains ("This skill is the standing safety contract for all homelab operations" and the Invocation block), keeping it below a 5.

4 / 5

Actionability

Concrete, executable guidance is present: `ssh root@192.168.2.9`, `ssh root@192.168.2.242`, the `ssh pve` WSL caveat, and "ssh + pvesh beats browser automation". For an instruction-only skill the directives are specific, though there are minor gaps such as no example of how a change is logged to the logbook.

4 / 5

Workflow Clarity

The rule ordering implies a sequence (inspect state → confirm destructive action → act → log), and explicit validation checkpoints exist: "pause and confirm with the user", "requires confirming a backup exists first", "Test in staging", plus a concrete escalation stop-list, so the destructive-ops no-validation cap does not apply. It falls short of 5 only because no explicit end-to-end procedure ties the rules into a single ordered workflow.

4 / 5

Progressive Disclosure

The body is under 50 lines with clean sections (Core Safety Rules, Escalation Rules, Companion Skills, Environment Facts, References), and all references are one level deep and clearly signaled — companion skill names, external doc URLs, and a single repo findings doc. No bundle files exist, so the simple-skill exception applies and organization alone justifies a 5.

5 / 5

Total

17

/

20

Passed

Description

53%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 states a concrete what with a recognizable safety niche, but omits any when-to-use guidance and lacks the natural trigger terms (VM, container, delete/restart/stop, Proxmox) a user would actually say. Per the rubric's completeness cap, a missing 'Use when...' clause holds it to the midpoint. Adding an explicit trigger clause and concrete capability verbs would raise specificity, trigger quality, and completeness together.

Suggestions

Add an explicit trigger clause, e.g. "Use in any session touching VMs, containers, Proxmox, networking, storage, or homelab services, or before any delete/stop/restart/migration operation."

List concrete capabilities instead of summarizing: e.g. "Requires inspecting state before changes, blocks destructive ops (delete, stop, wipe, format) until confirmed, mandates backup-before-migrate and staging-first testing."

Include natural synonyms users would say — "VM", "container", "Proxmox", "delete", "restart", "stop service" — so the description matches real user phrasing and the skill triggers reliably.

DimensionReasoningScore

Specificity

"Encodes read-first, no-destroy-by-default safety constraints for all homelab automation" names the domain and 1-2 concrete constraint behaviors, matching anchor 3. It is not 4 because no list of several specific actions is given, and not 2 because it goes beyond a bare domain label.

3 / 5

Completeness

The "what" is clear, but there is no "Use when..." clause or any trigger guidance — the when-clause is entirely absent rather than merely implicit, which per the rubric caps completeness at 3. Not 4 because "when" is not weakly implied anywhere in the description.

3 / 5

Trigger Term Quality

"homelab", "automation", "safety", "read-first", "no-destroy-by-default" are relevant keywords, but common natural phrases users would say are missing ("delete", "restart", "stop", "VM", "container", "Proxmox"), matching anchor 3 (some relevant keywords, missing common variations/synonyms).

3 / 5

Distinctiveness Conflict Risk

"...for all homelab automation" carves out a clear niche with minimal conflict risk against non-homelab skills, but the "all" scoping overlaps the territory of closely related companion homelab skills, matching anchor 4 rather than 5.

4 / 5

Total

13

/

20

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

Validation for skill structure

No warnings or errors.

Repository
pvnkmnk/AgenticSelfHostSkills
Reviewed

Table of Contents

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.