# Question Asking Policy

## Purpose

Help Nimrod ask fewer, better questions.

The goal is not to avoid clarification. The goal is to avoid repeatedly asking low-value, defaultable, premature, or already-answerable questions.

## Core Rule

Before asking the user a question, decide whether it is:

1. **Known** — already documented; retrieve it instead.
2. **Defaultable** — use documented defaults and state the assumption.
3. **Premature** — defer until after research/spec/design.
4. **Judgment-bearing** — ask the user because it affects direction, risk, cost, privacy, or preference.

Ask mostly judgment-bearing questions.

## Preferred Pattern

Use this pattern for one or two lightweight clarifications:

```text
I will assume <documented default> unless you want otherwise.

The decisions I need from you now are:
1. <high-impact judgment question>
2. <high-impact judgment question>
```

When several pieces of information are needed, use the interactive `questionnaire` tool instead of a plain numbered question list. Also use `questionnaire` for closed/select-from-options questions when practical, especially when asking the user to choose between options. Each questionnaire should provide concise likely options while relying on the tool's custom response and edit-before-submit behavior for user-specific answers, corrections, and extensions.

Avoid asking a long list of implementation details at the start of a task.

Do not ask closed questions in plain text when the interactive questionnaire is available and the user is expected to select from options.

## Do Not Repeatedly Ask These Defaults

For homelab service work, use `docs/service-deployment-defaults.md` before asking about:

- LAN/Tailscale vs public exposure
- simple `dropcutstud.io` service hostnames
- LXC vs VM default
- whether markdown tickets remain current source of truth
- generic backup need
- generic DNS/TLS need

State assumptions and ask only if the task appears to deviate.

## Good Early Questions

Good early questions usually decide direction:

- Is this experimental, important, or critical?
- Are we replacing an existing workflow or adding a temporary bridge?
- Are there must-have features that would rule out common options?
- Is there a privacy/security constraint that changes the architecture?
- Should we optimize for speed, reliability, learning, or long-term maintainability?

## Questions to Defer

Usually defer these until product selection or spec/design:

- exact auth provider
- exact TLS mechanism
- exact DNS name when convention is obvious
- exact backup retention when backup classes are not yet defined
- detailed UI preferences before MVP workflow is agreed
- exact implementation framework before research, unless recommending a default

## Response Review Heuristic

If an initial response asks more than about 3–5 questions, check whether some can be replaced with:

- documented defaults
- assumptions
- research tasks
- spec placeholders
- later-phase decisions