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
73%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/infrastructure-ops/SKILL.mdQuality
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.
| Dimension | Reasoning | Score |
|---|---|---|
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.
| Dimension | Reasoning | Score |
|---|---|---|
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.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (766 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
4863aaf
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.