ce-setup

Check Compound Engineering health and repo-local config, or scaffold a Compound Pack with `pack:<id>`.

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/ce-setup/SKILL.md

Quality

Content

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

The content is a strong procedural skill: an executable health-check entry point with a fallback, explicit approval gates on every user-file write, clear phase sequencing with validation and feedback loops, and well-signaled one-level-deep references to real bundle files. Remaining improvements are minor — a couple of open-ended steps and a small second-level reference hop. No substantive weaknesses.

Dimension	Reasoning	Score
Conciseness	The body is almost entirely procedural with no concept explanations and no padding — every section instructs ("Run the bundled check script", "Display the diagnostic output", "Read `references/repo-fixes.md` before making any repo-local change"). A few dense conditional passages, such as Step 3's writable-checkout branching ("If this session has no writable checkout, but the user named a repository and the harness exposes a remote repo-work surface..."), could be tightened, matching the efficient-with-minor-trimming anchor of level 4 rather than the every-token-earns-its-place profile of level 5.	4 / 5
Actionability	Concrete executable guidance dominates: the bash snippet with the SKILL_DIR anchor, exact display text ("Compound Engineering -- checking your environment..."), an exact summary template, and named remediation items ("obsolete `compound-engineering.local.md`", "Invalid docs_root"). Minor gaps keep it at level 4: the `--version VERSION` placeholder must be hand-substituted, and "Detect the installed compound-engineering plugin version by reading the plugin metadata or manifest when the platform exposes it" is open-ended rather than a specific command.	4 / 5
Workflow Clarity	Phases 1-3 are clearly sequenced with explicit decision points ("decide Phase 2 from writable-checkout availability"), approval gates ("offered and applied only if the user approves"), explicit error stops ("Otherwise stop with an error naming `docs_root` and the value"), and a feedback loop ("A `Pack config error` ... means the scaffold is not done: fix the cause and run the check again"). This matches the anchor for clear sequence with explicit validation, feedback loops, and checkpoints.	5 / 5
Progressive Disclosure	The body is an orchestration overview that delegates detail to real, well-signaled reference files, each named with its purpose ("It carries Steps 4-9: removing the obsolete ... `compound-engineering.local.md`"; "read `references/pack-scaffold.md` ... and follow it in place of Phases 1-2"), and all referenced paths exist in the bundle. It stays at level 4 rather than 5 because `references/repo-fixes.md` itself points onward to `assets/compounding-directive.md`, `assets/noslop-directive.md`, and `references/config-template.yaml` — a second hop that slightly exceeds the one-level-deep ideal, though those are verbatim data files rather than nested instructions.	4 / 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 is concise, third-person, and names a distinct niche with two concrete capabilities, but it completely lacks trigger guidance (no "Use when..." clause) and misses the natural user phrasings and synonyms that drive invocation. It reads as a capability label rather than an invocation trigger. Adding a when-to-use clause with the phrases users would actually say would raise completeness, trigger-term quality, and specificity together.

Suggestions

Add an explicit trigger clause, e.g. "Use when setting up or troubleshooting Compound Engineering, checking the CE environment, or adding a Compound Pack (pack:<id>)", to lift completeness past the 3 cap.

Include natural user phrasings and synonyms ("set up", "environment check", "diagnose", "scaffold a pack") alongside the domain terms so trigger-term quality covers what users actually say.

Name one or two more concrete actions (e.g. "refresh config.example.yaml, offer to create config.yaml") to move specificity from 1-2 actions toward comprehensive coverage.

Dimension	Reasoning	Score
Specificity	"Check Compound Engineering health and repo-local config, or scaffold a Compound Pack with `pack:<id>`" names the domain plus two concrete actions (health/config check, pack scaffolding), but coverage stops there. This matches the anchor for 1-2 concrete actions without comprehensiveness, and is not level 4, which requires several specific actions.	3 / 5
Completeness	The description clearly answers "what" (check Compound Engineering health and repo-local config, or scaffold a Compound Pack) but contains no "Use when..." clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. It is not level 2 because the "what" is concrete and unambiguous.	3 / 5
Trigger Term Quality	Keywords like "Compound Engineering", "health", "repo-local config", "Compound Pack", and "pack:<id>" are relevant domain terms, but the natural phrases a user would say ("set up CE", "environment check", "install compound engineering") and their synonyms are absent. This is some relevant keyword coverage missing common variations, not the good coverage of level 4.	3 / 5
Distinctiveness Conflict Risk	"Compound Engineering" and "Compound Pack" with the distinct "pack:<id>" token form a clear niche with low conflict risk against other skills, though the generic words "health" and "config" alone could overlap broader setup/diagnostic skills. Mostly distinct with minor overlap risk fits level 4; the bare generic nouns keep it from the minimal-conflict profile of level 5.	4 / 5
	Total	13 / 20 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: EveryInc/compound-engineering-plugin
Path: skills/ce-setup/SKILL.md
Commit: 8a6e0a2

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