CtrlK
BlogDocsLog inGet started
Tessl Logo

matthew-a-carr/review-implementation

Repo-aware review of an implementation PR (the `ai:done` PR) against the SPEC it implements, the constitution, the ADRs, and the doc-staleness rules. Use when a routine fires on a PR labelled `ai:done`, when a human says "review impl PR #NNN" / "review the implementation for SPEC-NNN", or as a self-review step inside `implement-spec` before the PR is opened. Read-only — produces a structured report and never edits code or merges.

85

1.06x
Quality

90%

Does it follow best practices?

Impact

69%

1.06x

Average score across 3 eval scenarios

SecuritybySnyk

Advisory

Suggest reviewing before use

Overview
Quality
Evals
Security
Files

Quality

Content

77%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a highly actionable and well-structured review skill with clear workflows, explicit severity criteria, and a concrete output template. Its main weakness is length — the seven passes contain significant detail that could be split into referenced files for better progressive disclosure, and there's some redundancy between the 'always Critical' preamble and the individual pass descriptions. Despite the verbosity concern, nearly every line serves a purpose in preventing false positives/negatives during code review.

Suggestions

Extract the seven detailed pass definitions into a separate reference file (e.g., PASSES.md) and keep only a summary checklist in SKILL.md to improve progressive disclosure and reduce the monolithic feel.

Consolidate the 'always Critical' list with the per-pass details to eliminate redundancy — either keep only the per-pass version or make the preamble a terse summary table that references the passes.

DimensionReasoningScore

Conciseness

The skill is thorough and most content earns its place — the seven passes, severity definitions, and report template are all necessary. However, there's some redundancy: the 'always Critical' list in the preamble repeats nearly verbatim in Passes 2-5, and some explanatory framing (e.g., the 'When to use' section's cross-references to other skills) could be tighter. Overall mostly efficient but not maximally lean.

2 / 3

Actionability

Extremely actionable: each pass has concrete, specific criteria with exact file paths, naming conventions, tool names, and MCP function signatures. The report template is copy-paste ready with a fixed contract. Verification commands are fully specified (`pnpm lint && pnpm db:check:migrations && ...`). The severity rules are unambiguous with concrete examples (e.g., 'new Drizzle*Repository(...) outside the composition root').

3 / 3

Workflow Clarity

The workflow is clearly sequenced: identify inputs → load context (4 ordered steps) → run seven named passes → verify evidence → produce report → post/return based on mode. Validation checkpoints are explicit (confirm PR body shows green suite, run checks if no evidence). The verdict logic includes clear decision branches (Ready/Needs changes/Blocked) with specific follow-up actions for each. Error recovery is addressed (e.g., ambiguous input → ask, plugin not loaded → note and continue).

3 / 3

Progressive Disclosure

The skill is a single monolithic file with no bundle files to offload detail into. At ~300+ lines, the seven detailed passes with their sub-bullets could benefit from being split into referenced files (e.g., a checklist file per pass, or a separate conventions reference). The content is well-organized with clear headers, but the sheer volume in one file works against progressive disclosure principles.

2 / 3

Total

10

/

12

Passed

Description

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 an excellent skill description that clearly articulates what the skill does (repo-aware review of implementation PRs against multiple reference documents), when to use it (three distinct trigger scenarios), and its constraints (read-only, structured report output). It uses third person voice throughout and provides highly specific, distinctive trigger terms that minimize conflict risk with other skills.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: reviewing an implementation PR against SPEC, constitution, ADRs, and doc-staleness rules. Also specifies it produces a structured report and is read-only (never edits code or merges).

3 / 3

Completeness

Clearly answers both what (repo-aware review of implementation PR against SPEC, constitution, ADRs, doc-staleness rules; produces structured report; read-only) and when (PR labelled 'ai:done', human says 'review impl PR #NNN', or as self-review step inside implement-spec). Explicit 'Use when' clause is present.

3 / 3

Trigger Term Quality

Includes highly natural trigger terms: 'ai:done' label, 'review impl PR #NNN', 'review the implementation for SPEC-NNN', 'self-review step inside implement-spec', and 'PR labelled ai:done'. These cover multiple natural phrasings a user or automation would use.

3 / 3

Distinctiveness Conflict Risk

Highly distinctive with a clear niche: specifically reviews 'ai:done' implementation PRs against SPECs, ADRs, and constitution. The combination of triggers ('ai:done' label, SPEC-NNN references) and the read-only constraint make it very unlikely to conflict with other skills like general code review or spec writing.

3 / 3

Total

12

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents