infra-setup

Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance.

Quality

70%

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 ./plugins/evo/npm/skills/infra-setup/SKILL.md

Quality

Content

72%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 content is well-structured and highly actionable with concrete commands and a clean one-level reference, but it loses points on conciseness (duplicated provider config) and workflow clarity (no post-mutation verification loop). Tightening the duplication and adding a verify step would raise both.

Suggestions

Remove the provider-specific minimum-config list from Pre-assumptions and defer to references/provider-matrix.md to eliminate the duplicated config table.

Add an explicit post-config verification step, e.g. 'Verify: evo config backend should report <provider>; if evo new --remote fails, re-check SDK import and auth then retry.'

State the --provider-config keys come from provider-matrix.md so the 'evo config backend remote … --provider-config ...' placeholder is explicitly justified rather than left as '...'.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence (no concept explanations), but the Pre-assumptions provider-config list duplicates references/provider-matrix.md and the 'evo new --remote' note repeats across sections, so it could be tightened.	2 / 3
Actionability	It gives concrete, executable commands (evo --version, uv tool install …, pipx inject …, evo config backend worktree/pool, evo env load …); the few placeholders are justified by provider-specific variability.	3 / 3
Workflow Clarity	The 8-step Flow is clearly sequenced with explicit prerequisite validation (steps 3–5), but there is no post-config verification or fix-and-retry feedback loop for the mutating config step, leaving a validation gap.	2 / 3
Progressive Disclosure	The body is an overview that points to a real, clearly signaled, one-level-deep references/provider-matrix.md (cited in step 5 and Provider notes), with no nested references and easy navigation.	3 / 3
	Total	10 / 12 Passed

Description

67%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 concise, specific, and distinct, but it answers 'what' without an explicit 'when to use it' trigger clause and only partially covers natural trigger-term variations. Adding a 'Use when…' clause would lift the two weakest dimensions.

Suggestions

Append an explicit trigger clause such as 'Use when the user wants to switch where evo experiments run (local worktree/pool vs. a remote provider like Modal, E2B, Daytona, AWS, Azure, or SSH).'

Broaden natural trigger terms (e.g., 'evo backend', 'switch provider', 'run experiments on Modal/E2B/AWS') so users' phrasings match more reliably.

Drop the meta 'Non-user-invocable…reference' framing from the description and lead with the capability, since trigger matching keys off capabilities, not invocation mechanics.

Dimension	Reasoning	Score
Specificity	The description lists multiple concrete actions — 'evo backend switching, prerequisite checks, and auth/install guidance' — rather than vague abstractions, matching the anchor for several specific concrete actions.	3 / 3
Completeness	It clearly states what the skill does but provides no 'Use when…' clause or equivalent explicit trigger guidance, which the guidelines cap at 2 ('has what, but when is missing or only implied').	2 / 3
Trigger Term Quality	It contains relevant domain keywords (evo, backend, provider, auth, setup) but offers limited natural variation a user would say, fitting 'some relevant keywords but missing common variations' rather than full coverage.	2 / 3
Distinctiveness Conflict Risk	The evo-specific provider/backend niche is narrow and distinct, making it unlikely to trigger for unrelated skills.	3 / 3
	Total	10 / 12 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
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: evo-hq/evo
Path: plugins/evo/npm/skills/infra-setup/SKILL.md
Commit: ab5fbd6

Reviewed: 12 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.