phase

User Input

$ARGUMENTS

$ARGUMENTS is a phase identifier or description. If empty, ask the user which phase to start.

Setup

1. Read .coco/config.yaml for project configuration.

Execution

This command runs to completion in one turn. After the plan gate in step 3, there are no further checkpoints. Do not end a turn on a statement about the next feature ("Next I'll design X", "Continuing with feature 2") -- take the step instead. Do not offer to pause between features. The user approved the phase; the only legitimate stops are a hard failure or Phase Completion. Same four rules as /coco:loop -- see The Loop Does Not Stop To Report in commands/loop.md.

Report progress as one line per feature as it resolves, so the user can see phase position without asking:

[phase "{name}" | feature {i}/{n} | {done} complete] {feature} -> {stage}

1. Identify Specs for the Phase

Read discovery.roadmap_dir from config (default: docs/roadmap).

Structured roadmap lookup (preferred):

1. Glob {roadmap_dir}/*.md for roadmap files
2. If $ARGUMENTS matches a phase name or number in a roadmap file (e.g., "Phase 1: Foundation"):
   • Parse the phase table to get the feature list with slugs, priority order, and scores
   • Extract cross-feature dependencies from the phase section
3. If $ARGUMENTS is a release name (e.g., "v1.0"):
   • Open {roadmap_dir}/{release}.md and ask the user which phase to execute

Fallback (no roadmap files found):

• Search project README or docs for a roadmap section
• Use $ARGUMENTS as a description of features to implement
• Check existing spec directories in {specs_dir}/

Extract all features for the phase. When sourced from a roadmap, preserve the priority order and scores for reporting.

2. Audit Existing State

For each feature:

a. Check for existing spec directories using the Glob tool for each feature: {specs_dir}/{feature}/*

b. Check for existing code using Grep and Glob tools to search the codebase for related files (do NOT delegate to subagents for this).