spec-kit-checklist
Audit requirement quality across change artifacts. This is a requirements linter, not a test runner.
Input: Optionally specify a change name. If omitted, infer from context or ask.
Steps
-
Load artifacts
Load what exists under
specs/changes/<name>/:spec.md,plan.md,tasks.md
Also load FRAMEWORK.md for governing principles alignment.
-
Ask up to 3 clarifying questions (skip if context is clear)
Focus on: scope, risk prioritisation, audience, boundary exclusions.
-
Generate requirement quality checklists
Create or update files in
specs/changes/<name>/checklists/grouped by domain (e.g.,api.md,ux.md,security.md).Each checklist item must:
- Use question format: "Are [requirement aspect] defined for [scenario]?"
- Include a quality dimension tag:
[Completeness],[Clarity],[Consistency],[Measurability],[Gap],[Ambiguity],[Conflict] - Reference the source:
[Spec §X]or[Plan §X] - Never duplicate existing checklist IDs — continue numbering from the last
CHK-N
Quality dimensions to cover:
- Completeness — are all scenarios and edge cases specified?
- Clarity — are terms unambiguous and objectively measurable?
- Consistency — do requirements contradict each other?
- Measurability — can success criteria be verified without interpretation?
- Coverage — are all user stories traceable to tasks?
- Non-functional — are performance, security, and scale requirements present?
❌ Prohibited: "Verify button clicks", "Test API returns 200" — these are implementation tests. ✅ Required: "Is fallback behavior defined when X fails?", "Can 'fast' be objectively measured?"
-
Report
Produce a summary:
- Total items by dimension
- High-priority gaps
- Items that block proceeding to the
spec-kit-planorspec-kit-implementskills
Guardrails
- Never delete existing checklist items — only append.
- Maintain ≥80% traceability across checklist items.
- Flag FRAMEWORK.md principle gaps as CRITICAL.
- This skill audits requirements, not code behavior.
More from aircury/ai-framework
open-spec-explore
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
35spec-kit-plan
Create a technical implementation plan from a feature spec. Documents architecture, data models, and interface contracts without generating code. Run after spec-kit-clarify.
33open-spec-apply
Implement tasks from a working change. Use when the user wants to start implementing, continue implementation, or work through planned tasks.
33open-spec-propose
Propose a change with optional working artifacts. Use when the user wants a structured proposal with design notes, tasks, and a clear path to implementation.
33open-spec-complete
Mark a change as complete. Syncs specs/features/ to reflect current system behavior, then cleans up optional workflow artifacts. Framework-agnostic and independent of any external spec tool.
33airsync
Collaborative memory system for AI agents and teams. Three-layer architecture (INBOX → PUBLISHED → ARCHIVED) ensures only high-quality knowledge reaches the shared team memory.
32