CtrlK
BlogDocsLog inGet started
Tessl Logo

ce-code-review

Review a named diff or PR for bugs, regressions, tests, and standards. Use when asked to review code or when a shipping skill needs a review receipt. Use when asked to apply this review's findings locally. Use ce-resolve-pr-feedback for feedback already left on a PR.

66

Quality

80%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

The canonical home for this skill is ce-code-review in EveryInc/compound-engineering-plugin

SKILL.md
Quality
Evals
Security

Quality

Content

77%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 body is an exemplary orchestration overview: a strictly ordered spine, real error-recovery and cleanup semantics, and a progressive-disclosure structure where every detail lives in an existing, clearly-signaled one-level reference. Its main weakness is prose density — several stages are long run-on paragraphs whose edge-case rules could be trimmed or converted to bullets without losing any governance content.

Suggestions

Conciseness (lowest score): break the Stage 3d and Stage 4 paragraphs into short bullet rules; the collection-semantics sentences ('a launch acknowledgement alone is not a result', 'a progress update is not one') can each be one bullet instead of chained clauses.

Conciseness: consolidate the repeated negative-space caveats ('a read made before that step does not satisfy it', 'never end the turn on progress to await it') into a single 'reading discipline' rule stated once near the Execution spine intro.

Actionability: inline the one-line shape of the 'intent summary' and 'Review depth gate' (or name the exact section of the owning reference) so the spine can be followed without opening a reference to learn what artifact a stage must produce.

DimensionReasoningScore

Conciseness

The body does not explain concepts Claude already knows, but the prose is dense run-on governance text that could be substantially tightened, e.g. Stage 4 packs collection semantics, failure recording, and cleanup rules into a single ~150-word paragraph ("Every successful launch is collected only when its terminal outcome is in hand: a valid compact return is consumed, a tool error or malformed output is recorded as a failed reviewer, and a launch acknowledgement alone is not a result..."). Repeated negative-space caveats ("a read made before that step does not satisfy it", "never end the turn on progress to await it") add tokens without adding distinct rules. Not 2: there is no padding or basic-concept teaching; not 4: multiple passages still need trimming to earn 'every token earns its place'.

3 / 5

Actionability

Concrete, executable direction throughout: an ordered spine that names exact files to read at each step ("Read references/modes-and-output.md first", "Read docs_root from <repo-root>/.compound-engineering/config.yaml"), a concrete command (git rev-parse --show-toplevel), and explicit do/don't rules (never run git checkout, never use AskUserQuestion). All referenced files exist in the bundle. Not 5: a few instructions remain abstract at this level ("write the intent summary every reviewer receives", "find the applicable standards files") and must be resolved by jumping into references; as an instruction-only skill the absence of code is not itself penalized.

4 / 5

Workflow Clarity

A clearly numbered 7-step spine with explicit checkpoints and error-recovery feedback loops, which matter here because this is a batch operation (concurrent reviewer dispatch). It defines a depth gate before Stage 2, a completion condition ("Once every reviewer result is in"), failure handling (malformed reviewer output recorded as a failed reviewer; uncollected reviewer after the bound is a failure), and cleanup-before-return for the persisted cross-model peer ("run the cleanup its reference describes before returning the failure result"). Matches the top anchor's validate-and-recover pattern.

5 / 5

Progressive Disclosure

SKILL.md is a genuine overview: ~35 lines of orchestration with no inlined bulk detail, and every detailed concern is delegated to one-level-deep, well-signaled references that state exactly when each is read (e.g. "Read references/scope.md and resolve the reviewed diff... then apply that Review depth gate"). All twelve files named in the body exist under references/, and the body even governs reference-reading discipline (a reference seeded to a leaf is read by the leaf, not the dispatcher). No nested-reference indirection appears in the body itself.

5 / 5

Total

17

/

20

Passed

Description

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

A strong description that clearly states what the skill does, gives multiple explicit 'Use when' triggers, and proactively routes edge cases to a sibling skill. Third-person voice is maintained throughout. Its only weaknesses are moderate keyword coverage (missing common variations like 'code review') and some overlap risk on the broad trigger 'review code'.

DimensionReasoningScore

Specificity

"Review a named diff or PR for bugs, regressions, tests, and standards" names the domain and enumerates several concrete review targets, plus a distinct apply action ("Use when asked to apply this review's findings locally"). Not 5: the action set is essentially one verb (review) qualified four ways plus routing, with no fuller capability enumeration; not 3: several specific actions are listed with only minor coverage gaps.

4 / 5

Completeness

Explicitly answers both: what ("Review a named diff or PR for bugs, regressions, tests, and standards") and when, via two concrete "Use when..." trigger clauses ("asked to review code", "a shipping skill needs a review receipt", "asked to apply this review's findings locally"). The routing clause ("Use ce-resolve-pr-feedback for feedback already left on a PR") further sharpens the when. Clearly matches the top anchor.

5 / 5

Trigger Term Quality

Natural phrases users would say are present: "review code", "diff", "PR", "apply this review's findings". Not 5: common variations like "code review", "look at my changes", or "review my PR" phrasings are missing; not 3: multiple natural terms beyond one or two generic keywords are covered.

4 / 5

Distinctiveness Conflict Risk

The skill has a clear niche (diff/PR review with receipt output) and even disambiguates its sibling ("Use ce-resolve-pr-feedback for feedback already left on a PR"). Not 5: "asked to review code" is a very common trigger that could overlap with other general review skills; not 3: it is more than 'somewhat specific' given the explicit boundary handling.

4 / 5

Total

17

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
crdant/compound-engineering-plugin
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.