reviewer-protocol

Reviewer rejection workflow and strict lockout semantics

Quality

50%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

Quality

Content

50%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 well-organized, concrete policy skill with explicit verification and deadlock handling, but it carries redundancy between the rules and Anti-Patterns and never consolidates the workflow into a single sequenced flow with inline checkpoints.

Suggestions

Collapse the Anti-Patterns section into the rules (or trim it to only the non-obvious pitfalls) to remove the mirror of the seven lockout rules.

Add one canonical numbered workflow that inlines the verification checkpoint (rule 3) and the approval gate, so the full reject→lockout→reassign/escalate→revise→review loop reads as a single sequence.

Tighten abstract phrasing such as "selects the revision author based on the Reviewer's recommendation" into a concrete decision rule (reassign vs. escalate).

Dimension	Reasoning	Score
Conciseness	The body is mostly lean bullets and rules without explaining concepts Claude already knows, but the Anti-Patterns section largely restates the seven lockout rules and the Context intro repeats the Patterns section, so not every token earns its place.	2 / 3
Actionability	Concrete imperatives ("MUST verify that the selected agent is NOT the original author", "MUST refuse and ask the Reviewer to name a different agent") and worked examples with dialogue give specific guidance, but some phrasing stays abstract ("selects the revision author based on the Reviewer's recommendation") and it is policy prose rather than crisp executable steps.	2 / 3
Workflow Clarity	The numbered examples sequence the reject→lockout→revise→review flow and rule 3 is an explicit verification checkpoint with a deadlock escalation feedback loop, but the canonical workflow with inline checkpoints is distributed across rules and examples rather than presented as one coherent sequenced flow.	2 / 3
Progressive Disclosure	Sections (Context, Patterns, Examples, Anti-Patterns) are clearly organized and the skill is self-contained with no external references needed, but at ~70 lines with notable inline redundancy it exceeds the under-50-line simple-skill allowance for a top progressive-disclosure score.	2 / 3
	Total	8 / 12 Passed

Description

50%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 is a compact label that names a distinctive niche but lacks action verbs and any "Use when..." trigger guidance. It reads as a title rather than an actionable, trigger-rich skill description.

Suggestions

Rewrite as a third-person action sentence, e.g. "Enforces reviewer rejection workflows and lockout semantics that prevent the original author from self-revising."

Add a "Use when..." clause naming natural triggers, e.g. "Use when a Reviewer rejects an agent's work and a different agent must own the revision."

Surface concrete actions (approve/reject, reassign, escalate, verify non-authorship) so capabilities are explicit rather than implied by the domain label.

Dimension	Reasoning	Score
Specificity	"Reviewer rejection workflow and strict lockout semantics" names a concrete domain (rejection, lockout) and implies the reject action, but it is a label with no explicit action verbs, so it stops short of listing multiple concrete actions.	2 / 3
Completeness	It conveys what the skill covers (a rejection/lockout workflow) but gives no "when" trigger guidance at all, capping completeness at 2 per the missing-trigger guideline.	2 / 3
Trigger Term Quality	"Reviewer", "rejection", and "lockout" are domain terms a user might say in an orchestration context, but there is no "Use when..." clause or common variations, so coverage of natural trigger terms is partial.	2 / 3
Distinctiveness Conflict Risk	The niche (reviewer rejection with lockout semantics) is fairly specific within orchestration, but without explicit distinct triggers it could still overlap with adjacent reviewer-related skills, so it is not a clear 3.	2 / 3
	Total	8 / 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: microsoft/waza
Path: .copilot/skills/reviewer-protocol/SKILL.md
Commit: f466c4f

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