Unified team skill for code review. 3-role pipeline: scanner, reviewer, fixer. Triggers on team-review.
67
60%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.codex/skills/team-review/SKILL.mdQuality
Discovery
35%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 conveys the general purpose (code review) and a unique structural element (3-role pipeline), but lacks specific concrete actions, natural user-facing trigger terms, and an explicit 'Use when...' clause. It reads more like an internal technical note than a description designed to help Claude select the right skill from a large pool.
Suggestions
Add natural trigger terms users would actually say, such as 'code review', 'review my PR', 'pull request', 'check my code', 'review changes'.
Include an explicit 'Use when...' clause describing user scenarios, e.g., 'Use when the user asks for a thorough code review, wants bugs identified, or needs automated fix suggestions.'
List specific concrete actions performed by each role (e.g., 'Scans for bugs and security issues, reviews code quality and style, suggests and applies fixes').
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (code review) and describes a structural approach (3-role pipeline: scanner, reviewer, fixer), but doesn't list specific concrete actions like 'identify bugs', 'suggest fixes', 'check style compliance', etc. | 2 / 3 |
Completeness | The 'what' is partially addressed (code review with a 3-role pipeline), but the 'when' is only implied through 'Triggers on team-review' which is an internal trigger name rather than an explicit 'Use when...' clause describing user scenarios. | 2 / 3 |
Trigger Term Quality | The only trigger term is 'team-review', which is a technical/internal command rather than a natural keyword a user would say. Missing natural terms like 'code review', 'review my PR', 'pull request', 'check my code'. | 1 / 3 |
Distinctiveness Conflict Risk | The '3-role pipeline' and 'team-review' trigger give it some distinctiveness from a generic code review skill, but 'code review' is broad enough to overlap with other review-related skills, and the description doesn't clearly delineate its niche. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured orchestration skill that clearly defines a multi-agent code review pipeline with concrete templates, explicit delegation rules, and good error handling. Its main strength is actionability—the spawn templates, tool allow/block lists, and pipeline flow are highly specific and executable. Minor verbosity in some sections (architecture diagram, some tables) could be tightened, but overall the content density is justified by the complexity of the orchestration task.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly dense and information-rich, but includes some sections that could be tightened—e.g., the ASCII architecture diagram, the verbose delegation lock table, and the agent health check pseudocode. Some of this is necessary for a complex orchestration skill, but there's redundancy (e.g., the spawn template and model selection guide overlap in structure). | 2 / 3 |
Actionability | Provides concrete spawn_agent call templates with exact parameters, specific tool call allow/block lists, exact file paths, CLI commands, message bus API calls, and a detailed worker spawn template that is copy-paste ready. The delegation lock table is highly specific and executable as a decision procedure. | 3 / 3 |
Workflow Clarity | The sequential 3-stage pipeline (scan -> review -> fix) is clearly defined with explicit skip conditions (0 findings -> skip review+fix, user declines fix -> skip fix). Timeout handling has a clear escalation sequence (wait -> STATUS_CHECK -> FINALIZE -> close). The error handling table provides explicit resolution for each failure scenario, and the delegation lock acts as a validation checkpoint before every tool call. | 3 / 3 |
Progressive Disclosure | SKILL.md serves as a clear router/overview pointing to one-level-deep role specs (roles/coordinator/role.md, roles/scanner/role.md, etc.) and spec files (specs/pipelines.md, specs/dimensions.md, etc.). The role registry table provides a clean navigation index. Content is appropriately split between the overview here and detailed role instructions in referenced files. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
Total | 10 / 11 Passed | |
227244f
Table of Contents
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.