speclisted

# Spec-Driven Development Manage feature specs in `spec/{feature-name}/`. Each feature gets its own directory with lean, focused documents. Work too large for one buildable spec becomes an **epic**: a thin parent at `spec/{epic-name}/EPIC.md` that owns the goal, plus numbered child specs at `spec/{epic-name}/01-{child-name}/` that own the shippable slices. See [references/epics.md](references/epics.md). Resolve the active repository from the current working directory, then use its repo-root `spec/` path in commands and links. It may be a normal directory or a symlink; inspect the resolved path before editing. Use a specific kebab-case feature name. Prefix it with the affected component or product when that improves discoverability; use `shared-*` or `platform-*` for genuinely cross-cutting work. Keep active specs under `spec/`. If the repository has `spec-archive/`, read archived material for context but ask before reactivating it. Follow any repository-local `AGENTS.md` instructions for locations, naming, archive policy, and production boundaries. ## How It Works The user mentions a spec naturally — the agent determines intent from context: - If `spec/{name}/` doesn't exist → create it (new spec) - If `spec/{name}/EPIC.md` exists → this is an epic; read `EPIC.md` and `progress.md`, then work the active child - If `spec/{name}/progress.md` exists → read it, figure out where we are, continue - If only `spec-archive/{name}/` exists → read it for context and ask whether