CtrlK
BlogDocsLog inGet started
Tessl Logo

infrastructure-ops

Use when you need to manage infrastructure across multiple servers interactively via wsh — deploying applications, configuring services, managing packages, performing rolling updates, and handling the prompts and judgment calls that declarative tools cannot. Examples: "deploy this application across 10 servers with health checks between each", "upgrade packages across the fleet and handle diverse prompts", "inspect and modify configuration across servers", "roll back a failed deployment".

62

Quality

73%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Risky

Do not use without reviewing

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/infrastructure-ops/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Discovery

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong skill description that clearly communicates what the skill does (interactive multi-server infrastructure management via wsh) and when to use it, with rich concrete examples. The trigger terms are natural and comprehensive, and the niche is well-defined with the distinction from declarative tools. The description is well-structured and concise without unnecessary fluff.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: deploying applications, configuring services, managing packages, performing rolling updates, handling prompts and judgment calls. The examples further add specificity with health checks, fleet upgrades, configuration inspection, and rollback.

3 / 3

Completeness

Clearly answers both 'what' (manage infrastructure across multiple servers — deploying, configuring, managing packages, rolling updates, handling prompts) and 'when' (opens with 'Use when you need to manage infrastructure across multiple servers interactively via wsh') with explicit trigger guidance and concrete examples.

3 / 3

Trigger Term Quality

Includes strong natural trigger terms users would say: 'deploy', 'servers', 'rolling updates', 'packages', 'fleet', 'roll back', 'health checks', 'configuration', 'infrastructure'. Also mentions 'wsh' as a specific tool keyword. These cover a good range of how users would phrase multi-server management requests.

3 / 3

Distinctiveness Conflict Risk

Clearly carved out niche: multi-server interactive infrastructure management via wsh, with emphasis on handling prompts and judgment calls that declarative tools cannot. The mention of 'wsh', 'multiple servers', 'fleet', and 'rolling updates' makes this highly distinct from single-server or declarative configuration management skills.

3 / 3

Total

12

/

12

Passed

Implementation

47%

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

The skill provides comprehensive coverage of fleet management patterns with excellent workflow clarity, including validation checkpoints, rollback procedures, and failure gates throughout. However, it is excessively verbose — spending many tokens explaining concepts Claude already knows (what Ansible does, why interactive operations are hard, what rolling deployments are) — and all guidance is pseudocode rather than executable code or concrete tool invocations. The monolithic structure would benefit from splitting into focused reference files.

Suggestions

Cut the introductory explanation (paragraphs 1-3 about Ansible vs wsh, the 80/20 split) and the 'When to Use This' section down to 2-3 bullet points — Claude understands these concepts already.

Make pseudocode actionable by showing at least one complete example with actual wsh tool calls (e.g., concrete `wsh_send_input`, `wsh_get_screen` invocations or curl commands) rather than abstract 'send to', 'wait for idle' descriptions throughout.

Split the monolithic content into separate files (e.g., ROLLING_DEPLOY.md, PACKAGE_MANAGEMENT.md, HEALTH_CHECKS.md, ROLLBACK.md) and keep SKILL.md as a concise overview with links to each.

Remove or drastically shorten the Pitfalls section — items like 'Don't Forget sudo', 'Clean Up Sessions', and 'Record What You Do' are common sense for an AI agent and waste tokens.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~500+ lines. It extensively explains concepts Claude already understands (what Ansible does, why declarative tools exist, what rolling deployments are, what configuration drift means). The introductory paragraphs explaining the 80/20 split of infrastructure work, the 'When to Use This' vs 'Don't use' sections, and the Rollback Decision Framework are all conceptual explanations that waste tokens. The pitfalls section rehashes common sense (clean up sessions, don't forget sudo, record what you do).

1 / 3

Actionability

The skill provides structured pseudocode patterns for fleet operations, rolling deployments, health checks, and rollbacks, which give clear procedural guidance. However, none of the code is executable — it's all pseudocode with natural language conditions like 'if config needs updating' and 'handle prompt'. The actual wsh tool invocations are described abstractly ('send to', 'wait for idle', 'read screen') rather than as concrete API calls or tool invocations.

2 / 3

Workflow Clarity

Multi-step workflows are clearly sequenced with explicit validation checkpoints throughout. The rolling deploy pattern includes health checks between batches, soak periods, failure gates that stop progression, and rollback procedures. The inspect-modify-verify configuration pattern includes backup, verification, and revert steps. Feedback loops are present for error recovery in nearly every workflow.

3 / 3

Progressive Disclosure

The skill references other skills (wsh:cluster-orchestration, wsh:drive-process, wsh:multi-session) for prerequisite knowledge, which is good. However, the document itself is monolithic — all patterns (rolling deploys, config management, package management, health checks, rollback) are inline in one massive file. These could be split into separate reference files with a concise overview in the main SKILL.md. No bundle files exist to support this.

2 / 3

Total

8

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (766 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
deepgram/wsh
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.