tasks
npx machina-cli add skill skullninja/coco-workflow/tasks --openclawCoco Tasks Skill
Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts, then run cross-artifact consistency analysis.
When to Use
- Generating a task list as part of the coco pipeline
- Called by
/coco:phase(Step B) or/coco:planning-session tactical - When a tasks.md is needed in
specs/{feature}/before tracker import
Prerequisites: design.md must exist. If missing, use the design skill first.
Legacy fallback: If design.md doesn't exist, check for spec.md + plan.md as legacy artifacts and load both.
Setup
- Read
.coco/config.yamlforproject.specs_dir(default:specs). - Determine the current feature by:
- Checking the current git branch name
- Looking for the matching directory in
{specs_dir}/{branch-name}/ - Or from conversation context if a feature was recently discussed
- Load design documents from
{specs_dir}/{feature}/:- Required: design.md (user stories, tech stack, structure, API contracts, research decisions)
- Optional: data-model.md (entities, if generated separately)
- Legacy fallback: If
design.mddoesn't exist, loadspec.md+plan.md+data-model.md+contracts/+research.mdas legacy artifacts
- Load the tasks template from
.coco/templates/tasks-template.mdif it exists, otherwise use${CLAUDE_PLUGIN_ROOT}/templates/tasks-template.md.
Execution
1. Extract Context
- From design.md: tech stack, libraries, project structure, user stories with priorities (P1, P2, P3...), API contracts, research decisions
- From data-model.md (if exists): entities, map to user stories
Legacy mode (if loading spec.md + plan.md instead):
- From plan.md: tech stack, libraries, project structure
- From spec.md: user stories with priorities
- From data-model.md, contracts/, research.md (if exist): entities, endpoints, decisions
2. Generate Tasks
Organize tasks by user story. Every task MUST use this format:
- [ ] [TaskID] [P?] [Story?] Description with file path
- Checkbox: Always
- [ ] - Task ID: Sequential (T001, T002, T003...)
- [P]: Include only if parallelizable (different files, no dependencies)
- [Story]: Required for user story phases only ([US1], [US2], etc.)
- Description: Clear action with exact file path
3. Sub-Phase Structure
- Sub-Phase 1: Setup - Project initialization
- Sub-Phase 2: Foundational - Blocking prerequisites (MUST complete before user stories)
- Sub-Phase 3+: User Stories - One sub-phase per story in priority order (P1, P2, P3...)
- Each includes: goal, independent test criteria, acceptance criteria (min 3), implementation tasks
- Tests are OPTIONAL (include only if design requests TDD)
- Order within story: Tests -> Models -> Services -> Endpoints -> Integration
- Final Sub-Phase: Polish - Cross-cutting concerns
Each sub-phase MUST have an Acceptance Criteria section with specific, testable outcomes.
4. Dependencies, Parallel Map & File Ownership
Generate:
- Dependency graph showing sub-phase completion order
- File ownership per sub-phase with conflict risk
- Parallel execution opportunities
File Ownership (owns_files) Annotations:
If design.md contains file-level implementation details (in the Project Structure or Technical Approach sections), extract file ownership per sub-phase. For each user story sub-phase, identify the files/directories it exclusively modifies:
### Sub-Phase 3: User Authentication
**owns_files**: `src/auth/**`, `tests/auth/**`
These annotations are consumed by the import skill to populate task metadata, enabling worktree-based parallel execution. Only include owns_files when file paths are determinable from the design -- omit for sub-phases with unclear file boundaries.
5. Write tasks.md
Write to {specs_dir}/{feature}/tasks.md.
6. Cross-Artifact Consistency Analysis
After generating tasks.md, automatically run the full consistency analysis. This replaces what was previously the /coco:analyze command.
STRICTLY READ-ONLY: Do not modify any files during analysis. Output findings inline.
Load from {specs_dir}/{feature}/:
- design.md (required; or spec.md + plan.md in legacy mode)
- tasks.md (just generated)
- data-model.md (if exists)
.coco/memory/constitution.mdif it exists
Detection Passes (limit 50 findings total)
A. Duplication Detection
- Near-duplicate requirements across artifacts
- Mark lower-quality phrasing for consolidation
B. Ambiguity Detection
- Vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria
- Unresolved placeholders (TODO, ???,
<placeholder>)
C. Underspecification
- Requirements with verbs but missing object or measurable outcome
- User stories missing acceptance criteria alignment
- Tasks referencing files or components not defined in design
D. Constitution Alignment
- Any requirement or plan element conflicting with a constitution MUST principle
- Missing mandated sections or quality gates
- Constitution conflicts are automatically CRITICAL severity
E. Coverage Gaps
- Requirements with zero associated tasks
- Tasks with no mapped requirement/story
- Non-functional requirements not reflected in tasks
F. Inconsistency
- Terminology drift (same concept named differently across files)
- Data entities in data-model.md but absent in design (or vice versa)
- Task ordering contradictions
- Conflicting requirements
Severity Assignment
- CRITICAL: Constitution violation, missing core artifact, requirement with zero coverage blocking baseline
- HIGH: Duplicate/conflicting requirement, ambiguous security/performance attribute, untestable criterion
- MEDIUM: Terminology drift, missing non-functional task coverage, underspecified edge case
- LOW: Style/wording improvements, minor redundancy
Analysis Output
## Specification Analysis Report
| ID | Category | Severity | Location(s) | Summary | Recommendation |
|----|----------|----------|-------------|---------|----------------|
| A1 | ... | ... | ... | ... | ... |
**Coverage Summary:**
| Requirement Key | Has Task? | Task IDs | Notes |
**Metrics:**
- Total Requirements / Total Tasks / Coverage %
- Ambiguity Count / Duplication Count / Critical Issues Count
**Next Actions:**
- [Prioritized recommendations based on severity]
After the report, ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?"
7. Report
Output:
- Path to tasks.md
- Total task count and count per user story
- Parallel opportunities identified
- Independent test criteria for each story
- Suggested MVP scope (typically User Story 1)
- Analysis findings (from consistency analysis step)
- Suggested next step: tell the user to ask Claude to "import tasks into the tracker" (this triggers the
importskill automatically -- skills are NOT slash commands, so never suggest/coco:import)
Rules
- Tasks must be specific enough for an LLM to complete without additional context
- Each user story must be independently implementable and testable
- No vague acceptance criteria ("works correctly", "looks good")
- Include exact file paths in every task description
- Never hallucinate missing sections in the analysis
- Prioritize constitution violations (always CRITICAL)
- Report zero analysis issues gracefully with coverage statistics
Source
git clone https://github.com/skullninja/coco-workflow/blob/main/skills/tasks/SKILL.mdView on GitHub Overview
Generates an actionable tasks.md for a feature by reading design.md and available artifacts under specs/{feature}/. It outputs a dependency-aware plan with sub-phases, acceptance criteria, and cross-artifact consistency checks to keep design, data models, and contracts aligned.
How This Skill Works
The skill extracts context from design.md (tech stack, user stories with priorities, API contracts) and maps them into a task set organized by sub-phase. It outputs tasks in the required format (- [ ] [TaskID] [P?] [Story?] Description with file path) and produces a dependency graph and owns_files annotations for parallel execution; it uses a legacy fallback if design.md is missing.
When to Use It
- When generating a new feature plan in the coco pipeline
- When a tasks.md is required before tracker import
- When design.md exists and you need a dependency-ordered task list
- When design.md is missing or incomplete and legacy artifacts must be used
- When you want explicit file ownership and parallelization opportunities for sub-phases
Quick Start
- Step 1: Ensure design.md exists in specs/{feature} (or enable legacy artifacts)
- Step 2: Run the tasks generator; it will use .coco/templates/tasks-template.md if present
- Step 3: Review Acceptance Criteria and owns_files annotations before cross-artifact analysis
Best Practices
- Validate design.md exists and includes user stories with priorities
- Use - [ ] Task format with [P] only for parallelizable tasks
- Keep TaskIDs sequential and consistent across runs
- Define acceptance criteria for each sub-phase (minimum 3, testable)
- Verify owns_files annotations reflect determinable file paths from design
Example Use Cases
- Generate a tasks.md for specs/checkout using design.md as the source of truth
- Legacy mode: generate from specs/auth/spec.md + plan.md when design.md is missing
- Sub-Phase 1 Setup creates repo skeleton under src/ and tests/
- Sub-Phase 3: User Authentication includes owns_files: `src/auth/**`, `tests/auth/**`
- After generation, tasks.md is ready for tracker import with sequential T001..