ce-doc-review

Review requirements, plans, or specs with role-specific lenses. Use when the user wants to improve an existing planning document.

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

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

Quality

Content

85%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 body is a highly actionable, clearly sequenced multi-phase workflow with strong validation checkpoints and a well-structured one-level-deep reference bundle. Its only real weakness is conciseness: it is long and carries internal rationale and defensive explanation that could be trimmed or delegated to references.

Suggestions

Move the R29/R30 evidence-overlap matching internals out of the decision-primer section into references/synthesis-and-presentation.md, keeping only the operational rule (include an Evidence line per entry) in SKILL.md.

Tighten the Interactive mode rules: collapse the enumerated reasons a question might be rendered as narrative into a single crisp 'a decision question must fire the tool or fall back loudly' statement.

Consider relocating the detailed docs_root validation rules to a short reference, leaving the resolve/validate/use summary and an error-stop note inline.

Dimension	Reasoning	Score
Conciseness	The body contains no basic-concept padding Claude already knows, but at ~260 lines it embeds lengthy rationale (e.g. the R29/R30 evidence-substring overlap internals and defensive prose in the Interactive mode rules) that could be tightened or moved into references.	2 / 3
Actionability	It gives concrete, executable guidance throughout — exact commands ('git rev-parse --show-toplevel', 'ToolSearch' with 'select:AskUserQuestion'), precise file paths ('references/personas/<reviewer-name>.md'), and copy-paste-ready templated blocks for the team announcement and decision primer.	3 / 3
Workflow Clarity	The workflow is sequenced as named phases (0 through 5) with explicit validation checkpoints — the 'Missing-document gate — verify before any dispatch', subagent failure error handling, and docs_root config validation — providing the feedback loops the score-3 anchor expects for a batch dispatch operation.	3 / 3
Progressive Disclosure	SKILL.md acts as an orchestration overview with well-signaled, one-level-deep references (walkthrough, bulk-preview, synthesis-and-presentation, cross-model-review) and per-persona prompt files, all of which exist on disk; detail is appropriately split rather than nested.	3 / 3
	Total	11 / 12 Passed

Description

75%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 cleanly answers both what and when with an explicit, third-person 'Use when' trigger and a distinct niche. It is held back from a top score by a single named action rather than several, and by trigger-term coverage that is relevant but not comprehensive.

Suggestions

Expand the action list from the single verb 'Review' to two or three concrete actions (e.g. 'Review and stress-test requirements, plans, or specs ... ') to lift specificity.

Broaden trigger terms to include natural variations users say, such as 'design docs', 'RFCs', 'PRDs', or 'critique/pressure-test a plan', and drop or gloss the jargon 'role-specific lenses' in favor of 'multiple reviewer perspectives'.

Dimension	Reasoning	Score
Specificity	The phrase 'Review requirements, plans, or specs with role-specific lenses' names the domain and a single concrete action plus its method, but it does not list multiple specific concrete actions (e.g. extract, fill, merge) as the score-3 anchor requires.	2 / 3
Completeness	It explicitly states what the skill does ('Review requirements, plans, or specs with role-specific lenses') and when to use it ('Use when the user wants to improve an existing planning document'), matching the both-what-and-when anchor with an explicit 'Use when' trigger and third-person voice.	3 / 3
Trigger Term Quality	'requirements, plans, or specs' and 'planning document' are natural user terms, but 'role-specific lenses' is mild jargon and the coverage lacks common variations a user might say (e.g. 'design doc', 'RFC', 'PRD', 'critique').	2 / 3
Distinctiveness Conflict Risk	The multi-persona lens method combined with the 'improve an existing planning document' trigger carves a clear niche unlikely to fire for unrelated skills, rather than the broad overlap of the score-2 anchor 'Works with document files'.	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: EveryInc/compound-engineering-plugin
Path: skills/ce-doc-review/SKILL.md
Commit: a9f6d53

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