gza-spec-review-alllisted

# Spec Review Skill Review specification documents in `specs/` for accuracy against the current implementation. ## When to Use - User asks to review specs - User asks "are the specs accurate?" or "which specs are outdated?" - Before a release to ensure specs reflect current state - After a major refactor to find specs that reference old code ## Important: Aspirational vs Outdated Specs can be **forward-looking** (describing planned features) or **outdated** (describing old behavior). Use this heuristic: - **Aspirational (skip)**: Describes functionality that doesn't exist in code but sounds intentional/planned. Leave these alone. - **Outdated (flag)**: Describes functionality that *used to* work differently, or references old file paths, old command names, or deprecated patterns. When in doubt, flag it with a note that it "may be aspirational." ## Process ### Step 1: Discover specs ```bash ls specs/ ``` ### Step 2: For each spec, verify against implementation Read the spec file, then search the codebase to verify its claims. **Check for concrete, verifiable claims:** 1. **File paths** — Does the spec reference files that exist? - Search with Glob for referenced paths - Flag paths that don't exist and aren't plausible future additions 2. **Command/option names** — Does the spec describe CLI commands or flags? - Compare against `uv run gza --help` and `uv run gza <command> --help` - Flag commands that were renamed or flags that changed 3. **Config fi