tasks

Generate a dependency-ordered task list (tasks.md) with sub-phases and cross-artifact consistency analysis from design.md in specs/{feature}/.

Coco 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

  1. Read .coco/config.yaml for project.specs_dir (default: specs).
  2. 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
  3. 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.md doesn't exist, load spec.md + plan.md + data-model.md + contracts/ + research.md as legacy artifacts
  4. Load the tasks template from .coco/templates/tasks-template.md if 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.md if 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 import skill 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