setuplisted

# Task Execute the requested action: $ARGUMENTS Calling rule: `/setup <action> <arguments>`. If the requested action is ambiguous or contradictory, do NOT guess: flag it and ask for clarification before executing. First-run onboarding and module activation are owned by `/axiom` — if the user asks for initial setup, point them to `/axiom start`. --- ## If action is empty Describe this skill: its purpose and the actions table from "overview". Do not execute anything. ## If action is "overview" (or unknown) | Argument | Action | | :--- | :--- | | `new <capability idea>` | Guided interview + structure analysis → draft a new setup file in `setup/` | | `run <name>` | Execute a pending setup file and archive it to `setup/done/` | | `list` | Show pending and installed capabilities | | `overview` | This table | If the action was unknown, say so first, then show the table. --- ## If action is "new" Goal: turn a capability idea into a reviewable setup file — nothing is implemented in this action. 1. Check $ARGUMENTS (after "new"): the capability idea. If empty: ask what capability the user wants. **If the idea is a hierarchy-depth change** for an existing project or workstation, skip the capability interview and follow "Structural migrations" below instead — the file has a fixed content list. 2. **Interview**, one block at a time, only what the idea leaves open: - Goal: what should the capability do, for whom, how often (recurring or one-off)? - Inputs: what arrives,