Natural-language command suggestions in Ask: optional, reviewed, never auto-run (proposal) #432

Proposal (not approved, not implemented)

Let a person describe a terminal task in words from the composer ("find files over 100 MB changed this week"), review a suggested shell command, insert it into the composer, and run it with their own Enter — then carry on with ordinary commands. Full design: docs/design/v022-natural-language-commands.md (v0.22 slice 0 PR). Tracked by #431.

What exists today

Ask (/btw, /ask, /btw <request> from the composer) resolves requests deterministically into NMSh's own capabilities; an optional local model may only choose among those capabilities and can never introduce a command. Paste review and /track already classify commands as read-only, writing, destructive, network or privileged.

The proposal in one paragraph

One optional, off by default CommandSuggester outcome inside the existing Ask, consulted only after the deterministic resolver. A request is entered through an NMSh surface (/btw, or an explicit Ask mode in the composer), so it can never reach the shell as syntax. The suggestion is validated (one line unless asked otherwise, ≤ 1 KiB, no control or escape sequences), labelled by NMSh's own classifier (the model supplies no risk field), and shown with Insert / Copy / Refine. Nothing runs until the person presses Enter in the composer. By default only the request text, the shell and the OS family are sent; anything more is attached per request and shown first.

Providers (each optional)

• Local — the existing user-global model service gains a command task; the person's own llama.cpp / Ollama / LM Studio. The bundled 0.6B recommendation is not adequate for writing commands; NMSh never downloads a model for this.
• Anthropic, bring your own key — Messages API, claude-haiku-5-5, low effort, JSON-schema-constrained output re-validated locally. About $0.0001–0.0003 per suggestion at current list prices.
• OpenAI-compatible endpoint — URL plus optional key, covering other services without per-vendor code.

Keys come from an environment variable the person names (NMSh stores the name, never the key). No cookies, consumer-app sessions or chat subscriptions, and no assumption that a consumer subscription includes API access.

Decisions needed

1. Remote providers at all? The ROADMAP principle keeps the core experience free of cloud inference. Yes / no / local only?
2. Provider order (recommendation: local first, then Anthropic, then generic OpenAI-compatible).
3. Entry: /btw only, or also a composer Ask mode — and which key (after the Configurable semantic keymap and terminal-host conflict guidance #335 conflict review)?
4. Key storage: environment-variable name only (recommended first), or also Keychain / Secret Service?
5. Dependency: the official Anthropic SDK (loaded only when that provider is chosen), if approved.

Not in scope

Agent loops, tool use, file reading, multi-step plans, automatic execution, conversation memory beyond one refinement, a second assistant surface.