Go through the entire Go codebase, improve code comments, add logic explanations for non-trivial implementations, document uncommented exported symbols, and note any discovered bugs in BUGS.md without fixing them. Uses parallel sub-agents grouped by package area.

Decompose a spec into smaller child specs. The output is either **design specs** (sub-design problems that need further iteration) or **implementation tasks** (leaf specs ready to dispatch to the kanban board).

Check GitHub Actions CI results for the current branch. Shows job statuses, failed test output, and lint errors. If failures are found, automatically diagnoses and fixes the issues, then commits and pushes.

Analyze what existing code and specs a proposed change will affect. Use before implementing a spec to understand blast radius, identify risks, and find specs that need updating.

Break down a spec into sub-design specs, each focused on one design problem. Unlike task-breakdown (which produces implementation-ready leaves), this produces non-leaf design specs that need further iteration before dispatch. Children are ordered and indexed on the parent spec.

Implement the design spec at `$ARGUMENTS`. The first token is the spec file path (e.g., `specs/04-file-explorer.md`). Remaining tokens are optional focus instructions — if provided, implement only the specified items/sections instead of the full spec.

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.

Validate a task breakdown produced by `/task-breakdown` before starting implementation. Catch structural issues that would cause failures mid-execution.

Scan the Go codebase for common patterns, duplicated logic, and extractable abstractions, then refactor each into a standalone package under `internal/pkg/`. If `$ARGUMENTS` is provided, limit the scan to those packages/directories. Otherwise, scan the entire codebase.

Compare what a dispatched task actually built against what the spec asked for. This is the non-deterministic layer 2 of the task completion feedback loop — it goes beyond the mechanical status flip (layer 1) to assess whether the implementation truly satisfies the spec's intent.

Debug frontend issues interactively using Playwright. Builds the server, launches it on a temporary port, writes and runs Playwright scripts to reproduce and diagnose the issue, then applies the fix.

Run structural validation on spec documents as defined in `specs/local/spec-document-model.md`. If a specific spec file is given as `$ARGUMENTS`, validate only that spec (and run cross-spec checks it participates in). Otherwise, validate the entire spec tree.

Review an implementation against its spec or task. Check that acceptance criteria are met, no unintended changes were made, and tests cover the requirements. Use after implement-spec or after a task completes.

Create a new design spec in specs/. Gathers context, explores the codebase, writes the spec with proper frontmatter, and updates specs/README.md. Use when the user says "create a spec", "write a spec", "new spec", or "/spec".

Dispatch a validated spec to the kanban task board. Validates prerequisites, resolves dependency wiring, creates the task, and updates the spec's dispatched_task_id atomically. Also supports undispatching (cancel + clear link). Use when a spec is ready for execution.

Finalize the spec at `$ARGUMENTS` after all implementation tasks are done.