mcp-adr-analysis-server: Skill for Claude Code

Checklist Purpose: "Unit Tests for English"

CRITICAL CONCEPT: Checklists are UNIT TESTS FOR REQUIREMENTS WRITING - they validate the quality, clarity, and completeness of requirements in a given domain.

NOT for verification/testing:

• ❌ NOT "Verify the button clicks correctly"
• ❌ NOT "Test error handling works"
• ❌ NOT "Confirm the API returns 200"
• ❌ NOT checking if code/implementation matches the spec

FOR requirements quality validation:

• ✅ "Are visual hierarchy requirements defined for all card types?" (completeness)
• ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity)
• ✅ "Are hover state requirements consistent across all interactive elements?" (consistency)
• ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage)
• ✅ "Does the spec define what happens when logo image fails to load?" (edge cases)

Metaphor: If your spec is code written in English, the checklist is its unit test suite. You're testing whether the requirements are well-written, complete, unambiguous, and ready for implementation - NOT whether the implementation works.

Ownership and checkbox lifecycle:

• Custom checklists generated by this command are reviewer-owned requirements-quality review artifacts.
• [x] means the reviewer determined the requirements-quality criterion is satisfied.
• [x] does NOT mean implementation work is complete.
• This command generates or appends checklist items; it MUST NOT mark generated items [x].
• An agent may assist with evaluating items only when explicitly asked by the reviewer.
• checklists/requirements.md is a separate built-in spec-quality checklist maintained by /speckit-specify and /speckit-clarify; do not treat that exception as applying to custom checklists generated here.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Pre-Execution Checks

Check for extension hooks (before checklist generation):