tasks

name	tasks
description	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