JaviMontano/iikit-03-checklist

Intent Integrity Kit Checklist

Generate "Unit Tests for English" — checklists that validate REQUIREMENTS quality, not implementation.

Core Principle

Every checklist item evaluates the requirements themselves for completeness, clarity, consistency, measurability, and coverage. Items MUST NOT test implementation behavior.

User Input

$ARGUMENTS

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

Constitution Loading

Load constitution per constitution-loading.md (basic mode).

Prerequisites Check

1. Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/check-prerequisites.sh --phase 03 --json Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/check-prerequisites.ps1 -Phase 03 -Json

2. Parse JSON for FEATURE_DIR and AVAILABLE_DOCS.

3. 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-core/scripts/bash/set-active-feature.sh --json <selection>
   

   Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/set-active-feature.ps1 -Json <selection>

   Then re-run the prerequisites check from step 1.

Execution Steps

1. Clarify Intent

Derive up to THREE contextual questions (skip if unambiguous from $ARGUMENTS):

• Scope: include integration touchpoints?
• Risk: which areas need mandatory gating?
• Depth: lightweight sanity list or formal release gate?
• Audience: author-only or peer PR review?

2. Load Feature Context

Read from FEATURE_DIR: spec.md (required), plan.md (optional), tasks.md (optional).

3. Generate Checklist

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.

4. Gap Resolution (Interactive)

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.

5. Remaining Item Validation

After gap resolution, validate ALL unchecked [ ] items against spec/plan/constitution:

• If covered: check off with justification
• If genuine gap: convert to [Gap] and resolve or defer

Continue 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.

6. Report

Output: checklist path, item counts (total/checked/deferred), gap resolution summary, completion percentage.

Commit

git add specs/*/checklists/ .specify/context.json
git commit -m "checklist: <feature-short-name> requirements review"

Record Phase Completion

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"

Dashboard Refresh

Regenerate the dashboard so the pipeline reflects checklist completion:

bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/generate-dashboard-safe.sh

Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/generate-dashboard-safe.ps1

Next Steps

Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/next-step.sh --phase 03 --json Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/next-step.ps1 -Phase 03 -Json

Parse the JSON and present:

1. If clear_after is true: suggest /clear before proceeding
2. Present next_step as the primary recommendation
3. If alt_steps non-empty: list as alternatives
4. For next_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.
5. Append dashboard link

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)