parallaxlisted

# Parallax LLMs converge early. Each token conditions the next, so the model anchors on its first viable answer and polishes it. For questions with one right answer, that's fine. For decisions with multiple viable paths, it produces competent, forgettable output. This skill forces genuine spread before commitment: frame the decision, generate approaches that differ on fundamental assumptions, surface the traps, then commit to one with explicit trade-offs. ## Gate Two skip signals beyond the description's routing: the user saying "quick," "just," "standard," or "one-line"; and inner-loop per-keystroke work. When in doubt, answer directly and offer: *"Want me to run /parallax on this for a wider look?"* ## The protocol Three phases. Do them in order. Do not blend them. ### Phase 1 -- Frame Before generating any options, answer three questions: 1. **What are we deciding?** One sentence. Not what we're building -- what choice we're making. 2. **What's fixed?** Constraints that can't or won't change. Language, platform, team size, deadline, existing code. 3. **What does good look like?** Pick 2-4 dimensions that matter for this specific decision: simplicity, performance, correctness, maintainability, reversibility, user experience, security, cost, time-to-ship. Don't list all of them. Pick the ones that would actually break a tie. Picking dimensions now -- before seeing any options -- prevents post-hoc rationalization. You evaluate on what matters, not