メニュー
Generate quality checklists that validate requirements completeness, clarity, and consistency — produces scored checklist items linked to specific spec sections (FR-XXX, SC-XXX). Use when reviewing a spec for gaps, doing a requirements review, verifying PRD quality, auditing user stories and acceptance criteria, or gating before implementation.
| name | iikit-03-checklist |
| description | Generate quality checklists that validate requirements completeness, clarity, and consistency — produces scored checklist items linked to specific spec sections (FR-XXX, SC-XXX). Use when reviewing a spec for gaps, doing a requirements review, verifying PRD quality, auditing user stories and acceptance criteria, or gating before implementation. |
| license | MIT |
| metadata | {"version":"2.7.16"} |
Generate "Unit Tests for English" — checklists that validate REQUIREMENTS quality, not implementation.
Every checklist item evaluates the requirements themselves for completeness, clarity, consistency, measurability, and coverage. Items MUST NOT test implementation behavior.
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Load constitution per constitution-loading.md (basic mode).
Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/bash/check-prerequisites.sh --phase 03 --json
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/powershell/check-prerequisites.ps1 -Phase 03 -Json
Parse JSON for FEATURE_DIR and AVAILABLE_DOCS.
If JSON contains needs_selection: true: present the features array as a numbered table (name and stage columns). Follow the options presentation pattern in conversation-guide.md. After user selects, run:
bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/bash/set-active-feature.sh --json <selection>
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/powershell/set-active-feature.ps1 -Json <selection>
Then re-run the prerequisites check from step 1.
Derive up to THREE contextual questions (skip if unambiguous from $ARGUMENTS):
Read from FEATURE_DIR: spec.md (required), plan.md (optional), tasks.md (optional).
Starting point: FEATURE_DIR/checklists/requirements.md already exists (created by /iikit-01-specify). Review it, extend it with additional items, and resolve gaps. Do NOT create a duplicate — work with the existing file.
Additional domain checklists (optional): if the spec has distinct domains that warrant separate review (e.g., security, performance, accessibility), create additional files as FEATURE_DIR/checklists/[domain].md. These supplement requirements.md, not replace it.
Item structure: question format about requirement quality, with quality dimension tag and spec reference.
Correct: "Are visual hierarchy requirements defined with measurable criteria?" [Clarity, Spec SFR-1] Wrong: "Verify the button clicks correctly" (this tests implementation)
Categories: Requirement Completeness, Clarity, Consistency, Acceptance Criteria Quality, Scenario Coverage, SC-XXX Test Coverage, Edge Case Coverage, Non-Functional Requirements, Dependencies & Assumptions.
Traceability: >=80% of items must reference spec sections or use markers: [Gap], [Ambiguity], [Conflict], [Assumption].
See checklist-examples.md for correct/wrong examples and required patterns.
Use checklist-template.md for format structure.
For each [Gap] item: follow the gap resolution pattern in conversation-guide.md. Present missing requirement, explain risk, offer options. On resolution: update spec.md and check item off. Skip if --no-interactive or no gaps.
After gap resolution, validate ALL unchecked [ ] items against spec/plan/constitution:
[Gap] and resolve or deferContinue until all items are [x] or explicitly deferred.
IMPORTANT: Checklists are optional — not creating one is fine. But once created, they MUST reach 100% before the skill reports success.
Output: checklist path, item counts (total/checked/deferred), gap resolution summary, completion percentage.
git add specs/*/checklists/ .specify/context.json
git commit -m "checklist: <feature-short-name> requirements review"
Write a timestamp to .specify/context.json so the dashboard knows the checklist phase was run (not just that requirements.md exists from specify):
CONTEXT_FILE=".specify/context.json"
[[ -f "$CONTEXT_FILE" ]] || echo '{}' > "$CONTEXT_FILE"
jq --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" '.checklist_reviewed_at = $ts' "$CONTEXT_FILE" > "$CONTEXT_FILE.tmp" && mv "$CONTEXT_FILE.tmp" "$CONTEXT_FILE"
Regenerate the dashboard so the pipeline reflects checklist completion:
bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/bash/generate-dashboard-safe.sh
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/powershell/generate-dashboard-safe.ps1
Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/bash/next-step.sh --phase 03 --json
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-03-checklist/scripts/powershell/next-step.ps1 -Phase 03 -Json
Parse the JSON and present:
clear_after is true: suggest /clear before proceedingnext_step as the primary recommendationalt_steps non-empty: list as alternativesnext_step and each alt_step, include the model_tier from the JSON so the user knows which model is best for each option. Look up tiers in model-recommendations.md for agent-specific switch commands.If deferred items remain, warn that downstream skills will flag incomplete checklists.
Format:
Checklist complete!
Next: [/clear → ] <next_step> (model: <tier>)
[- <alt_step> — <reason> (model: <tier>)]
- Dashboard: file://$(pwd)/.specify/dashboard.html (resolve the path)
Create or update a CONSTITUTION.md that defines project governance — establishes coding standards, quality gates, TDD policy, review requirements, and non-negotiable development principles with versioned amendment tracking. Use when defining project rules, setting up coding standards, establishing quality gates, configuring TDD requirements, or creating non-negotiable development principles.
Create a feature specification from a natural language description — generates user stories with Given/When/Then scenarios, functional requirements (FR-XXX), success criteria, and a quality checklist. Use when starting a new feature, writing a PRD, defining user stories, capturing acceptance criteria, or documenting requirements for a product idea.
Generate a technical design document from a feature spec — selects frameworks, defines data models, produces API contracts, and creates a dependency-ordered implementation strategy. Use when planning how to build a feature, writing a technical design doc, choosing libraries, defining database schemas, or setting up Tessl tiles for runtime library knowledge.
Generate Gherkin .feature files from requirements before implementation — produces executable BDD scenarios with traceability tags, computes assertion integrity hashes, and locks acceptance criteria for test-driven development. Use when writing tests first, doing TDD, creating test cases from a spec, locking acceptance criteria, or setting up red-green-refactor with hash-verified assertions.
Generate dependency-ordered task breakdown from plan and specification. Use when breaking features into implementable tasks, planning sprints, or creating work items with parallel markers.
Validate cross-artifact consistency — checks that every spec requirement traces to tasks, plan tech stack matches task file paths, and constitution principles are satisfied across all artifacts. Use when running a consistency check, verifying requirements traceability, detecting conflicts between design docs, or auditing alignment before implementation begins.