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. For a request to see connections, use the project brain and state when its graph adapter is unavailable.

Identify the outcome, repository/workspace and settled decisions. For a code question, trace the implementation before answering; docs are navigation, not proof.
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.
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.
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.
Follow the shared decide-and-ask guidance: 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.
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 or the initialized standalone writer. 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.