/explore is a new slash command in Dawn. Type it at the start of a question and Dawn shifts into an investigation-first mode — reading across the workspace and connected sources, following the threads the question implies, and only then composing the answer. It trades a few extra seconds, sometimes a minute or two, for substantially better answers on broad or ambiguous questions.
The command is one extra word in the chat composer. The difference in answer quality on the right kind of question is what makes the wait worth it — questions like “where would this feature actually live?”, “why does this regression keep coming back?”, or “what would change if we moved this validation to the API gateway?” stop landing on the first plausible interpretation and start arriving with evidence.
When Reaching for It Is Worth the Wait
The cost of /explore is time. A normal Dawn response on a focused question takes a handful of seconds; an explore on the same workspace takes anywhere from twenty seconds to a couple of minutes depending on how far the agent has to range. That extra time is wasted on questions that have a single-file answer, and earns its keep on questions that do not.
Architecture questions are the clearest case. “If I add a new permission tier, where in the codebase do I need to change?” is the kind of question that benefits from Dawn first reading the existing permission definitions, the middleware that enforces them, the migration files that introduce them, and the tests that cover them — and then synthesising. A normal response would land on the first place the change is needed and call it done; an explored response gives you the full list and flags the places that look adjacent but actually do not need to change.
Multi-module bug hunts are the second. “Why does the share link sometimes break for guest users?” usually has its root cause in code far from where the symptom shows up. /explore gives Dawn permission to walk back through the chain — link generation, signing, validation, the guest-session middleware — instead of guessing at the first hop. The answer arrives later, but it arrives with evidence.
Pre-implementation scoping is the third, and arguably the highest-value. Before someone opens a substantial pull request, an explored response can map likely touchpoints, surface earlier decisions in adjacent areas, and call out the parts that look small but tend to grow. That kind of map is useful at sub-PR scale too — /explore before drafting a Linear ticket gives you a paragraph that the engineer who picks the ticket up genuinely benefits from.
The pattern across all three is the same. The question is broad. The answer is non-obvious. The cost of being wrong on the first try is higher than the cost of waiting another minute for the right answer. That is the shape /explore is built for.
What It Actually Does
Behind the prompt, /explore opts the run into a longer investigation budget and a different shape of agent loop. The agent is allowed — and encouraged — to read more files, follow more cross-references, and consult more connected sources before writing its first sentence of the answer. It is not a different model; it is a different posture for the same agent.
That posture matters because Dawn’s investigation tools are the same regardless of mode. The agent can already read across connected sources like GitHub, Confluence, Notion, Jira, and Linear; it can already consult memory pages and skills; it can already follow links between issues and pull requests. What /explore changes is how aggressively it does so. A normal run treats those tools as fall-back lookups; an explored run treats them as the first move.
The transcript reflects the difference. An explored response usually includes a short paragraph at the top describing what the agent looked at — which files, which tickets, which docs — followed by the actual answer. That preamble is not garnish: it is the part that turns the answer from “trust me” into “here is the evidence.” If the agent’s investigation missed an area you know is relevant, the preamble is where you will spot it, and a follow-up message can redirect the next pass without starting the whole conversation over.
Asking the Question in Plain Language
The other thing /explore is built for is questions that arrive half-formed. “Something is off with how guest sessions expire.” “Can we simplify the way we resolve canonical URLs?” “What changed in the billing area over the last two months that might be related to this finance complaint?” None of those are precise, and they are not meant to be — they are the way real questions show up in real chat threads.
A normal Dawn response on a half-formed question lands on a plausible interpretation and answers that one. Sometimes that lucky guess is right; often it is close-but-not-quite. /explore lets the agent do the disambiguation work itself. It can read enough of the area to figure out what the question probably means, name that interpretation explicitly at the top of the answer, and then answer it — leaving the user free to redirect if the interpretation was wrong, with the benefit of the agent now having seen the area and being able to redirect quickly.
For mixed teams that is the part that matters most. Engineers, QA, and product teammates all ask questions in their own register; not everyone wants to spend two minutes phrasing a precise prompt. /explore does not make precision unnecessary — a precise question is still answered better than a vague one — but it raises the floor on how vague a question can be while still getting a useful first response.
When Not to Use It
/explore is the wrong default for the same reason it is the right one when needed. On a focused question — “what does this regex match?”, “rename this function and update its callers”, “summarise this PR” — the extra investigation budget gets spent on irrelevant context, and the answer arrives slower without being any better. The normal chat flow is better for those.
Two practical heuristics. If the question fits in your head as “look at exactly this file and tell me X”, skip /explore. If the question fits as “I am not sure where to start looking, but the area is roughly Y”, reach for it.
The other case where /explore does not earn its keep is when the workspace has not yet been connected to the things the question is about. The command can only investigate sources Dawn already has access to. If the area in question lives in a Notion page, a Jira project, or a GitHub repo that is not connected, the explored run will be no better than the normal one — usually a touch worse, because it spent time looking and finding nothing. The fix there is connecting the source, not changing the prompt.
Where Slash Commands Work
/explore joins the slash command catalogue alongside /help, /whats_new, and /link. Type / in the chat composer in Dawn Web, the VS Code extension, or a channel where slash commands are supported, and /explore will show up in the suggestion list with the rest. It accepts the question on the same line: /explore why does the share link break for guest users? is the full call.
The pattern stays the one teams already know. Type /, see what is available, use it. The new entry in the menu is the one to reach for when the question is broad, the area is spread out, and the cost of a shallow first pass is higher than the cost of waiting for a better one.