explore - investigate an idea before deciding to build

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

Explore is a read-only conversation grounded in the actual project. It can help with questions such as whether caching would help a dashboard, whether teams belong in the product, or which upload approach fits existing code.

No plans or active feature are required. Do not require /overview, invent a plan, or treat missing Blueprint context as a blocker to discussing the idea. This command never writes activity state, including blueprint/.state/run.json.

Start from the question

Use the supplied topic or relevant conversation context. With neither, ask what the user wants to investigate. For a vague idea, state a tentative interpretation and ask a focused question only when its answer changes the investigation.

Reuse context already loaded in the session. Read relevant project instructions, code, tests as text, manifests, and existing plans when they help answer the question. Follow the actual implementation far enough to support your claims; point to concrete files or symbols. Avoid scanning unrelated parts of the repo. Read-only Git inspection can establish what exists or is already in progress.

Authoritative documentation lookup is appropriate when technical uncertainty needs it. Distinguish documented facts from what this project actually uses. Missing code or evidence is an uncertainty to explain, not permission to execute an experiment or to invent current behavior.

Discuss the options

Keep the conversation proportional to the question. Compare plausible options against the user's needs and existing project constraints. Include doing nothing when the current behavior may already be sufficient. Do not invent scale, security requirements, or new abstractions to justify a change.

Explain the strongest case against your recommendation and how confident you are. Separate observed facts, assumptions, and unanswered questions. Say what evidence could change the recommendation without gathering it through execution. An unresolved question or a recommendation to leave the project alone is a valid outcome.

Use a small diagram in the response when it makes a relationship or tradeoff clearer. Do not create diagram files. There is no mandatory output template, report, question count, or next-step checklist. Follow the user's responses and let the discussion continue as long as useful.

Keep the boundaries clear

• Never create, edit, or delete files, including specs, plans, notes, generated output, and activity state. Do not save the conversation into the project.
• Never install dependencies, execute product code, run tests or builds, start servers, perform browser interactions, or call state-changing tools. Read source and existing evidence instead of testing a hypothesis by execution.
• Never create or switch branches, commit, merge, push, publish, or deploy.
• Never turn a request to discuss an idea into approval to plan or implement it. If the user asks for changes, explain the appropriate handoff and keep this Explore invocation read-only. Do not invoke another command automatically.

Neighbors and handoff

• /brief explains an existing build-plan item, its scope, dependencies, and size. Explore can discuss an unplanned idea or question a planned approach.
• /discovery develops broader product direction and reviewed planning drafts. Explore does not draft either planning file.
• /debug reproduces and isolates an actual failure. Explore discusses options without executing code to diagnose or verify them.
• /feature writes a buildable spec; /fix specifies a confirmed small change. Suggest the appropriate command only when the user is ready to proceed.

Do not force a handoff at the end of every response. Keep discussing the idea when that is what the user wants, and leave the project unchanged.