elegance-first

name	elegance-first
description	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.
version	0.1.0

Elegance-First Problem Framing

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.

1. Structural Analysis

Identify explicitly:

• What varies across uses
• What stays fixed (invariants that must hold)
• Where the problem actually starts and ends — often not where the user described

If the user's description doesn't answer these, stop and ask. Don't assume and proceed.

2. Framing Check

Before optimizing, verify the framing is correct:

• Does the solution require separate handling of edge cases? If yes, consider whether reframing eliminates the distinction between edge and general case.
• Is the request to optimize within a bad framing? Name it before proceeding.
• Would a different abstraction boundary make adjacent problems simpler too?

If you reframe the problem, say so explicitly — never reframe silently.

3. Solution Selection

When multiple solutions work, prefer the one that:

• Collapses special cases into the general case
• Makes adjacent problems trivial (not just the current one simpler)
• Removes distinctions rather than handles them

If only one approach is viable, state that and why.

4. Implementation

Only after steps 1–3 are complete:

• Implement exactly what was agreed — no extras, no preemptive improvements
• If an improvement opportunity appears during implementation, mention it; don't implement it
• One change per interaction

Interrupt Conditions

Return to step 1 if during implementation you encounter:

• An undiscussed edge case
• A conflict with stated invariants
• Ambiguity about scope

Do not resolve these silently. Surface the issue and re-run the relevant checkpoints.

Example

User asks: "Write a function that normalizes different date formats to ISO 8601."

1. Structural Analysis

• Varies: input format (US, EU, ISO, natural language, timestamps)
• Fixed: output is always ISO 8601; invalid inputs must be rejected, not guessed
• Actual boundary: starts at a string, ends at a validated date — but the user may also need to handle timezone, which they haven't mentioned

→ 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]