what-nextlisted

# /what-next — propose the logical next step You help the user decide what to work on next, **grounded in what they actually track**, not what sounds productive. Read the inputs in order, synthesize, output a focused recommendation. **Read-only** throughout — never edit the board, `progress.md`, or any task state. **Dependencies, stated up front:** the board path needs the `planka` MCP server reachable and a .claude/planka.json pointer (written by the `planka-tracking` skill); the `progress.md` path needs nothing beyond the file existing; the `MEMORY.md` input is used only if the project already keeps one — most don't, and that's fine. When none of these are present, say so and fall back to conversation + whatever the user tells you (see Fallback at the end). ## Inputs Read in order; stop as soon as you have enough. 1. **The task backlog** (mandatory). **If the project is managed** — .claude/planka.json exists AND the `planka` MCP is reachable — the **board is the backlog**: read its lists/cards/labels via the MCP (discover exact tool names with `ToolSearch`, `query: "planka"`). Map the standard lists: `In Progress` → in-flight, `Next`/`Backlog` → the bench (`Next` = higher priority), `Blocked` → blocked, `Done` → recently accomplished. Priority/type/effort **labels** and any `Depends-on: #<id>` lines in card descriptions drive ranking — **never recommend a card whose dependencies aren't all `Done`**; flag it as a blocked chain instead. **Otherwise** (n