---
name: zen-ask
description: Orient a Zen request and select the next useful workflow from the user's outcome and project evidence. Use when the user asks what to do next or the right mode is unclear.
---
# Zen ask

Find the smallest useful next action. Do not turn every question into a project or require the user to learn mode names.

For a vague or new project, offer a guided intake with accessible choices and an open answer, or a plain conversational alternative. Tailor the explanation to the selected experience level, recommend a direction with its reason, and leave material owner choices open. See [personalization and guided intake](../zen/references/personalization.md). For a request to see connections, use [the project brain](../zen/references/brain.md) and state when its graph adapter is unavailable.

1. Identify the outcome, repository/workspace and settled decisions. For a code question, trace the implementation before answering; docs are navigation, not proof.
2. If tools exist, use `zen_state` for metadata, then a narrow `zen_research_search`. Read the relevant task, handoff and applied feedback/memory. Check scope and status before treating a lesson as active; avoid loading the whole archive.
3. Route by uncertainty: grill for owner decisions; research for facts; wayfinder for a large decision map; prototype for an interaction that needs to be seen; spec for settled intent; tasks for executable slices; implement for assigned work; diagnose for an observable symptom; triage for readiness; review for an actual diff; explain for understanding. Setup repairs access. Pre-checks/pre-push verify readiness. Feedback/memory/retro retain learning.
4. Answer a straightforward question directly. If another mode helps, explicitly read its SKILL.md. Do not claim a nested Skill call when the host lacks it. See [host behavior](../zen/references/hosts.md).
5. Follow the [shared decide-and-ask guidance](../zen/SKILL.md#decide-and-ask): use `zen_ask_question` or the host native ask tool for material ambiguity, with 2–3 concrete options, one recommended and a reason. Discover code facts yourself. Do not reopen agreed scope, ask for a model merely to answer a question, or replace a complete product request with an MVP.
6. State the chosen mode and next concrete action briefly. Keep earlier work active when a new message is steering or requesting status.

## Output and storage

Give the destination, known facts, important uncertainty and next action. Persist an IDE or handoff DOC only when durable capture is wanted; an ordinary answer need not create a file. Use [actual tool calls](../zen/references/tools.md) or the initialized [standalone writer](../zen/references/standalone.md). With neither, deliver a labelled draft and never invent a saved reference.

Example: “Why do offline edits disappear?” starts with diagnose and the command/write path, not a proposal to replace the database. “Which flow feels right?” calls for prototype. A missing owner model choice blocks a launch, not investigation or a specification. See [the routing example](references/output.md).