next-issuelisted

# Next Issue Help the user decide **what to work on next** and **whether they can start it immediately**. You survey the open issues, rank them by triage state and dependencies, recommend an execution order, and — when the user commits to one — check whether it's specified well enough to execute, routing fuzzy ones to a `grill-with-docs` session first. ## What this is, and what it is not - It **consumes** an already-triaged board. It does **not** re-triage incoming issues — that's the `triage` skill's job. If issues have no triage labels, say so and suggest triaging first; don't invent priorities for un-triaged work. - It **stops at the clarity gate**. It does **not** implement the issue. Once an issue is judged execution-ready, hand back to the user to start the work (or to whatever implementation flow they use); if it's not ready, hand off to `grill-with-docs`. Keeping this boundary tight is what makes the skill trustworthy: the user knows that invoking it surveys and sequences, never silently starts changing code. ## Workflow ### 0. Ask once: visual board, or terminal-only? Rendering the HTML map costs a round of clustering + annotation work and pops a browser window — some users just want the ranked list in the terminal. So before you start, ask with **AskUserQuestion**: - 问题：「要生成可视化 HTML 看板吗？」 - 选项：**生成看板（推荐）** — 业务线分组 + 依赖连线 + 解锁地图，自动在浏览器打开； **只要终端摘要** — 跳过 HTML，直接给排序和分组结果。 Two cases where you should **not** ask: - The user's request already answer