lateraluslisted

Understand the goal first. Break tunnel vision. Generate from outside the failed approach. ## Step 0 — Interrogate before ideating (always first, no exceptions) ### Phase 1 — Read the codebase (before asking anything) **Do this silently before presenting options to the user:** 1. Check for `CLAUDE.md` (or `AGENTS.md`, `GEMINI.md`) at the repo root — read it fully if present. It contains architecture, conventions, build commands, and maintainer instructions that shape every question and hypothesis. 2. If no `CLAUDE.md`, do a quick orientation scan: - Detect language/framework from `go.mod`, `package.json`, `requirements.txt`, `Cargo.toml`, `pom.xml`, etc. - Read `README.md` (first 60 lines) for architecture context. - Run `git log -10 --oneline` to see recent changes. - Glob for key config files (`docker-compose.yml`, `k8s/`, `.env.example`, `Makefile`). 3. Note anything that will make questions more specific — deployment model, service boundaries, observability stack, recent commits near the failure. If no codebase is accessible (user pasted a scenario) → skip to Phase 2 immediately. --- ### Phase 2 — Present options and ask the user to choose **Open with this every time (after Phase 1):** ``` I can help in four ways — which fits your situation? [1] Tier 1 · Ground — concrete, testable hypotheses outside the obvious layer [2] Tier 2 · Balanced — question assumptions while staying loosely verifiable [3] Tier 3 · Wild — speculative reframes