Menu
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.
| name | iikit-05-tasks |
| description | 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. |
| license | MIT |
| metadata | {"version":"1.6.4"} |
Generate an actionable, dependency-ordered tasks.md for the feature.
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Load constitution per constitution-loading.md (basic mode — note TDD requirements for task ordering).
Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/check-prerequisites.sh --phase 05 --json
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/check-prerequisites.ps1 -Phase 05 -Json
Parse JSON for FEATURE_DIR and AVAILABLE_DOCS. If missing plan.md: ERROR. If script exits with testify error: STOP and tell the user to run /iikit-04-testify first.
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.
Checklist gate per checklist-gate.md.
Report readiness per formatting-guide.md (Plan Readiness section).
plan.md, spec.mddata-model.md, contracts/, research.md, quickstart.md, tests/features/ (.feature files)If .feature files exist (or legacy test-specs.md), tasks reference specific test IDs (e.g., "T012 [US1] Implement to pass TS-001").
If Tessl installed: query primary framework tile for project structure conventions and testing framework tile for test organization. Apply to file paths and task ordering. If not available: skip silently.
Extract tech stack from plan.md, user stories from spec.md, entities from data-model.md, endpoints from contracts/, decisions from research.md. Organize by user story with dependency graph and parallel markers.
- [ ] [TaskID] [P?] [Story?] Description with file path
- [ ]Examples:
- [ ] T001 Create project structure per implementation plan (setup, no story)- [ ] T005 [P] Implement authentication middleware in src/middleware/auth.py (parallel, no story)- [ ] T012 [P] [US1] Create User model in src/models/user.py (parallel, story)- [ ] T014 [US1] Implement UserService in src/services/user_service.py (sequential, story)Wrong — missing required elements:
- [ ] Create User model (no ID, no story label)T001 [US1] Create model (no checkbox)- [ ] [US1] Create User model (no task ID)Traceability: When referencing multiple test spec IDs, enumerate them explicitly as a comma-separated list. Do NOT use English prose ranges like "TS-005 through TS-010" — these break automated traceability checks.
Correct: [TS-005, TS-006, TS-007, TS-008, TS-009, TS-010]
Wrong: TS-005 through TS-010
Map each component to its user story. Shared entities serving multiple stories go in Setup/Foundational. Each contract gets a contract test task. Story dependencies marked explicitly.
After generating, validate:
Use tasks-template.md with phases, dependencies, parallel examples, and implementation strategy.
Output: path to tasks.md, total count, count per story, parallel opportunities, MVP scope suggestion, format validation.
If tasks.md exists: preserve [x] completion status, map old IDs to new by similarity, warn about changes to completed tasks. Ask confirmation before overwriting. Use format from formatting-guide.md (Semantic Diff section).
git add specs/*/tasks.md
git commit -m "tasks: <feature-short-name> task breakdown"
Regenerate the dashboard so the pipeline reflects the new tasks:
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
Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/next-step.sh --phase 05 --json
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/next-step.ps1 -Phase 05 -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.Format:
Tasks generated!
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 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.
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.
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 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.