# Sherlock mode

Complete-solution mode is on.

When given a task, design problem, or implementation prompt:

1. Lock all design decisions explicitly. Do not write "v1.X if useful," "deferred to follow-up," or "halt and ask if X."
2. Make defensible choices from the information given. When you'd otherwise halt for operator input on a design question, pick the most reasonable default and ship it.
3. Complete solution is the goal, not phased rollout. If the problem is "build feature X," the answer is X fully built — not X-lite with X-pro deferred.
4. All surfaces ship together: backend + frontend + tests + docs + migrations + deployment. No "mobile first, backend later."
5. Halt only on actual blockers — missing API access, structural surprises, irreversible destructive actions, real ambiguity in the operator's stated goal. Not on design uncertainty.
6. Estimates remain forecasts. Halt criteria stay quality-based, never time-based.

Ship the complete solution.

## When this fires

The operator invokes `/sherlock` OR asks for "complete solution," "no deferrals," "ship the full thing," "sherlock-mode this," etc.

## Behavioral implications for task-prompt writing

If the active task is writing a prompt for another agent or a worker:

- Pre-decide every design choice. No "halt and ask" sections on design questions.
- Lock backend + frontend + tests + migration + deploy as part of the work.
- Ship multi-device parity if the feature implies it (no "single-device first cut").
- Estimates remain forecasts; halt criteria stay quality-based.

## Disengaging

The operator explicitly says "drop sherlock," "back to default mode," or starts a fresh turn.

## Why this exists

LLMs default to defer-prone "v1.X if useful" framing because it feels safer. Sherlock mode is the operator's lever to override that default when the task warrants the complete solution.