projectlisted

# Task Execute the requested action: $ARGUMENTS Calling rule: `/project <action> <arguments>`. If the requested action is ambiguous or contradictory (matches multiple actions, arguments conflict with the action, or the intent is unclear), do NOT guess: flag the ambiguity and ask for clarification before executing. Core principle: **work is done at WP level only.** Projects and sub-projects are organizational structure. If the user asks for work on a project or sub-project that has no suitable WP, suggest creating one first. **Tier check (read `axiom-config.md` first):** in **simple** tier, every project is 2-level — do not ask the depth question, do not mention 3-level structure, and manage numbering/IDs silently (apply them consistently; explain only when asked). In **advanced** tier, follow the depth rules below in full. --- ## Hierarchy depth (advanced tier — read before any action) Every project is either **2-level** or **3-level** (root CLAUDE.md, Hierarchy Protocol). The depth is chosen when the project is created and recorded in its registry as `Levels: **2**` or `Levels: **3**`. | Depth | Chain | Sub-projects | Task ID | | :--- | :--- | :--- | :--- | | 2-level | Project → WP → Task | Not allowed | `XX-WW-TT` | | 3-level | Project → Sub-project → WP → Task | Mandatory — every WP lives in one | `XX-SS-WW-TT` | Before any action other than "new project": read `vault/projects/<project>/ids.md`, take `Levels`, and obey it. **The depth is locked.** This skill nev