CtrlK
BlogDocsLog inGet started
Tessl Logo

reviewer-protocol

Reviewer rejection workflow and strict lockout semantics

60

Quality

70%

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

Fix and improve this skill with Tessl

tessl review fix ./.copilot/skills/reviewer-protocol/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

A well-crafted protocol skill: deterministic rules with explicit enforcement checkpoints, concrete refusal dialogue, and worked examples covering edge cases including deadlock and reviewer misassignment. The only weakness is mild redundancy between the Context paragraph, the Anti-Patterns list, and the numbered rules.

DimensionReasoningScore

Conciseness

The body is mostly efficient: lean numbered rules ('The Coordinator MUST verify that the selected agent is NOT the original author'), no explanations of concepts Claude already knows, and examples that earn their place. Not 5 because the Context paragraph's closing sentences and several Anti-Patterns ('Allowing the original author to self-revise after rejection', 'Skipping verification that the revision agent is not the original author') restate rules 1-7 and could be trimmed.

4 / 5

Actionability

Fully actionable instruction-only guidance: unambiguous MUST/NOT directives, exact refusal phrasing ('The original author is locked out. Please name a different agent.'), and four worked examples covering the common cases (reassign, escalate, deadlock, reviewer mis-naming the author). Per the scoring notes, absence of code is not penalized when guidance is this concrete.

5 / 5

Workflow Clarity

Clear sequence with an explicit validation checkpoint ('Before spawning a revision agent, the Coordinator MUST verify that the selected agent is NOT the original author'), a refuse-and-retry feedback loop (Example 4), per-cycle lockout progression (rule 6), and deadlock escalation to the user (rule 7, Example 3). This matches the anchor for explicit validation steps with feedback loops for error recovery.

5 / 5

Progressive Disclosure

The skill is self-contained with no bundle files, and the body is well organized into Context / Patterns / Examples / Anti-Patterns sections with nothing that clearly belongs in a separate file. Per the scoring notes, a well-organized single-purpose skill with no need for external references scores 5 on progressive disclosure.

5 / 5

Total

19

/

20

Passed

Description

48%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 names a specific, distinguishable domain but reads as a topic label rather than a capability description: it contains no concrete actions and no 'when to use' trigger guidance. It is far above generic filler like 'Helps with documents' but below the good examples that pair action lists with explicit 'Use when...' clauses.

Suggestions

Add concrete actions to the description, e.g. 'Enforces strict lockout semantics on reviewer rejection: reassigns revisions to a different agent, escalates to spawn expert agents, and escalates deadlocks to the user.'

Add an explicit 'Use when...' clause with natural trigger terms, e.g. 'Use when a reviewer rejects an agent's work, when lockout enforcement is needed, or when the user mentions reviewer rejection or self-revision prevention.'

Include natural keyword variations users would actually say (reject/rejected, approve, code review, PR review) to strengthen trigger-term coverage.

DimensionReasoningScore

Specificity

The description names the domain ("Reviewer rejection workflow") and a concept ("strict lockout semantics") but lists no concrete actions — no verbs like 'enforce lockout', 'reassign revision', or 'escalate'. This matches the anchor 'Names the domain but actions are minimal or generic'; a 3 would require 1-2 concrete actions, which are absent.

2 / 5

Completeness

The 'what' is present ("Reviewer rejection workflow and strict lockout semantics") but there is no 'Use when...' clause or any equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not 2 because the 'what' is clearly stated, not vague.

3 / 5

Trigger Term Quality

"Reviewer", "rejection", and "lockout" are relevant keywords a user might naturally say in an orchestration context, but common variations and synonyms ("reject", "approve", "code review", "self-revise") are missing. Fits 'Some relevant keywords but missing common variations or synonyms'; not 4 given the thin keyword set.

3 / 5

Distinctiveness Conflict Risk

"Reviewer rejection workflow and strict lockout semantics" carves out a distinct niche with low conflict risk against unrelated skills. Not 5 because without trigger phrases it could still mildly overlap with generic code-review or PR-review skills.

4 / 5

Total

12

/

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
bradygaster/squad
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.