Structured problem-framing discipline before solving non-trivial problems. Activate ONLY when the user explicitly requests it — phrases like "frame this", "think through this first", "elegance-first", "analyze before solving", "structure this problem", or "step back and think". Do NOT auto-trigger on general coding or implementation requests.
Before solving the problem, work through these four checkpoints and output each one visibly under its own header. A checkpoint can be a single sentence — the discipline is structure before solution, not structure instead of solution.
Identify explicitly:
If the user's description doesn't answer these, stop and ask. Don't assume and proceed.
Before optimizing, verify the framing is correct:
If you reframe the problem, say so explicitly — never reframe silently.
When multiple solutions work, prefer the one that:
If only one approach is viable, state that and why.
Only after steps 1–3 are complete:
Return to step 1 if during implementation you encounter:
Do not resolve these silently. Surface the issue and re-run the relevant checkpoints.
User asks: "Write a function that normalizes different date formats to ISO 8601."
1. Structural Analysis
→ Question: should the function handle timezone-aware inputs, or assume naive dates?
2. Framing Check The natural approach is a chain of format-specific parsers tried in order. But that makes every new format a new branch. Reframing: treat it as "parse any unambiguous date representation" using a single flexible parser, and reject genuinely ambiguous inputs (like 01/02/03) rather than guessing.
3. Solution Selection Single parser with explicit ambiguity rejection > format-specific chain. Collapses the per-format branches and makes adding new formats zero-cost.
4. Implementation [proceeds after user confirms the timezone question]