| name | report |
| description | Survey the whole spec tree: what is complete, in progress, blocked, and actionable next. Reads the spec files, task files, and git history rather than any hand-maintained table. Read-only. Use for "where do things stand"; use validate to check the tree is structurally sound. |
Spec Tree Report
Generate a live status report by reading specs, task files, and git history.
If a specific spec is given, report on that spec only. Otherwise, report across
all specs.
Step 0: Parse arguments
If an argument is provided, treat it as a spec file path for focused status.
Otherwise, report on the full project.
Step 1: Discover specs and tasks
- Glob for all spec files recursively:
specs/**/*.md (excluding README.md).
Specs are grouped by track: a directory under specs/ where one exists,
otherwise the track: frontmatter field. An NNN- filename prefix is an
independent, per-directory ordering convention — report in that order where
it is present, but never read it as the dependency order. Take the track set
from what is on disk, never from a list memorized here or in an earlier run.
- For each spec, parse YAML frontmatter to extract
title, status,
depends_on, affects, effort, dispatched_task_id, and track (where
the path does not already supply it).
- Determine parent-child relationships from the filesystem: a spec at
specs/<track>/foo.md with a directory specs/<track>/foo/ is a non-leaf
spec; its children are the specs inside that directory.
- Read
specs/README.md for track organization and dependency context.
Step 2: Classify each spec
For each spec file, use the frontmatter field as the primary source of
truth:
