Conciseness

The body is dense, directive prose with no concept explanations Claude already knows ('The spec is wrong until proven right', 'This prevents anchoring bias' are brief purposeful rationales). Not 5 because the ~60-line lens-priority ID index partially duplicates the constitution that Step 1 already requires reading in full, and could be trimmed to priorities only.

Actionability

Guidance is copy-paste ready for an instruction skill: an exact finding-format block ('[PRINCIPLE-ID] Severity: ... Location: ... Evidence: ...'), an exact output-structure markdown template, a binary verdict rule (PASS/BLOCK with explicit anti-hedging), and a concrete sampling rule ('minimum 3 or 20%, whichever is larger'). Everything needed to execute is specified; not 4 because there are no material gaps.

Workflow Clarity

Eight clearly sequenced steps with explicit validation checkpoints: an anchoring-bias countermeasure (build an independent model before reading the spec), codebase verification of claims with a failure escalation rule ('If ANY verification fails, flag ALL unverified claims as suspect'), a pre-verdict completeness checklist, and a binary verdict. This matches the feedback-loop/checklist anchor exactly; not 4 because checkpoints are explicit at every stage.

Progressive Disclosure

References are clearly signaled (read '.opencode/rules/review-constitution.md' in full; '.opencode/rules/documentation-style.md'; '.opencode/skills/ideate/spec-template.md'), but the bulk of the body is an inlined index of principle IDs (AMB-01..CPX-07) that duplicates detail belonging in the constitution file. Not 4 because roughly a third of the body is inlined material that belongs in the referenced file; not 2 because structure and navigation are otherwise sound and references are explicit, not buried.

Specificity

Phrases like 'Deep adversarial specification review', 'Evaluates design documents, plans, and specs for ambiguity, completeness, feasibility, security, and MockServer-specific concerns' name the domain plus several concrete evaluation dimensions. Not 5 because the actions are evaluation criteria rather than a comprehensive list of concrete operations; not 3 because coverage goes beyond 1-2 actions.

Completeness

The 'what' is clear (adversarial spec review across named quality dimensions), but there is no 'Use when...' or equivalent trigger clause; 'Loaded by review-cheap and review-final agents' describes internal orchestration, not when Claude should invoke it. Per the guideline, a missing explicit trigger guidance caps completeness at 3; it is not 2 because the 'what' is fully explicit.

Trigger Term Quality

Relevant keywords exist ('specification review', 'design documents', 'plans', 'specs', 'ambiguity', 'security'), which a user might plausibly say, but common variations/synonyms ('review my spec', 'check this design doc', 'RFC') are missing. Not 4 because natural phrasing coverage is thin; not 2 because several genuinely natural domain terms are present.

Distinctiveness Conflict Risk

The niche is fairly distinct ('adversarial specification review', '8-lens review constitution', 'MockServer-specific concerns'), though the generic word 'review' and evaluation dimensions like 'security' create minor overlap risk with general code-review or security skills. Not 5 due to that overlap risk; not 3 because the framing is clearly specialized to spec/design documents.