flow-explorelisted

## When to use this The ask is too thin or the codebase area too unfamiliar to shape a brief or a plan yet - a one-line request, a bare link to a ticket or doc with little inline description, or a task that touches a part of the codebase nobody here has mapped recently. The goal is a findings report surveying what the task likely needs and how it could be built, not a committed brief or plan. Use `/meta-feature` instead when the ask is already clear enough to shape into acceptance criteria without codebase research. Use `/flow-plan` instead when the task and a chosen approach are both already confirmed. ## Procedure 0. Resolve external context. If $ARGUMENTS contains a URL with little or no inline description, resolve it before anything else: identify which connected service the URL belongs to from its domain, use ToolSearch to find a matching fetch/read tool for that service (e.g. a URL under `app.clickup.com` points at the ClickUp tools, `notion.so` at the Notion tools, `github.com` at `gh` via Bash or the GitHub tools), and call it to pull the content. Treat the resolved text as the effective $ARGUMENTS for the rest of the procedure - never hand a bare link to a sub-agent. If no connected tool matches the URL's domain, say so and ask for the content pasted inline instead. 1. State the task in one sentence, your own words. Run the requirements-clarity check from `/flow-plan` (testable, unambiguous, complete, consistent) against it. Unlike `/flow-plan`, do not stop on a