# Resolve Before You Ask

Always in force, every host. Before you stop to ask the user a **factual**
question, you must first try to answer it yourself with the tools and durable
knowledge already available. Asking the user for something findable wastes their
time; repeatedly re-deriving known context wastes tokens and loses continuity.

## Exhaust these first, in order

1. **Capability discovery — what can the environment already do?** Inspect the
   available host tools, installed plugins/skills, PRD MCP tools, read-only UTCP
   actions, deterministic workflows, and the configured Substrate handshake.
   Prefer a purpose-built query, recall, graph, status, or record tool over
   reconstructing the same answer from files. Do not assume a tool or the
   Substrate is active; verify availability and effective configuration.
2. **Substrate memory — what does durable runtime recall already know?** When a
   connected Substrate exposes long-term memory, repository recall, indexed
   records, graph, or event history, query it before raw repository search.
   Treat it as recall/derived knowledge, not canonical write authority. If it is
   unavailable, disabled, degraded, or stale, continue without treating that as
   a blocker.
3. **LLM wiki — has this understanding already been compiled?** Query
   `wiki/index.md` and the relevant articles through `project-llm-wiki` before
   re-deriving durable domain, architectural, operational, or codebase
   knowledge. Check article provenance/staleness when it affects the decision.
4. **Canonical project truth — what do the authoritative records say?** Use PRD
   MCP/UTCP tools such as bounded find/get/status/decisions/evidence/graph actions
   to read tracking, decisions, changelog, plans, evidence, memory, and recorded
   preferences. Read backing JSON directly only when a validated tool cannot
   answer the question or exact serialization is itself relevant.
5. **Raw repository search — what exact implementation fact remains?** Only now
   search code, documentation, and git history with `rg` or host read/search tools
   plus `git log`/`git blame`. Use this for exact implementation details,
   verification, stale-knowledge checks, and gaps the structured sources did not
   answer—not as the default substitute for memory and indexed knowledge.
6. **Local files — what is intentionally local?** Credentials live in `.env`;
   settings live in config files; intent may live in READMEs and design docs.
   Use the approved secret-loading method and never echo secret values.
7. **Web tools — what is external and current?** For versions, API behavior,
   library documentation, or facts outside the repo, use search/fetch tools
   before asking the user to look it up.

Higher-level knowledge is a starting point, not unquestionable truth. Widen to
raw sources whenever recall is missing, stale, contradictory, or insufficiently
precise, and verify consequential claims against canonical records or code.

## Only then ask — and show your work

If all applicable sources genuinely come up empty, ask and **state what you
checked**, for example:

> Checked available PRD/UTCP/Substrate tools, Substrate recall, the LLM wiki,
> canonical project records, raw repo/history, local config, and external docs
> for `<thing>` — not found. So: `<the question>`.

That sentence is the rule's teeth: it makes durable recall and self-service the
default and makes a lazy escalation obvious. If you skipped an applicable source,
use it instead of asking.

## What this does NOT cover

This is about **findable facts**. It does not change the consent floor: pushing,
merging, and publishing stay tier-governed (explicit consent in
`key_decision`/`guided`, standing consent in `autonomous`), while force-push,
editing another repo, or spending money still require explicit user consent no
matter how much you researched. A genuine **preference/decision that only the
user holds** is a legitimate ask—check recorded preferences first, but do not
manufacture an answer the user never gave.