engineering-solution-pivotlisted

Deep-reasoning escalation method, not a default workflow, for engineering problems where the obvious path is exhausted or is heading toward a dead end or an expensive path. It is evidence-driven, escapes blocked or thrashing approaches, and challenges designs, constraints, and assumptions — including transforming a constraint rather than working around it. Use when the same causal hypothesis has failed twice; a workaround is growing more complex than the problem it solves; a constraint, dependency, platform limit, or security control appears to make the goal impossible; a request is framed as "do X using Y" and Y may not be required; an architecture, migration, or design decision carries significant security, reliability, performance, or cost trade-offs; or the user asks for alternative approaches, a devil's-advocate or adversarial review of a technical plan, an engineering pivot, or invokes /engineering-solution-pivot. Not for routine tasks with a clear, working path.
alexandrenunes-cs/engineering-solution-pivot · ★ 0 · AI & Automation · score 75

Install: claude install-skill alexandrenunes-cs/engineering-solution-pivot

# Engineering Solution Pivot A deep-reasoning escalation method for technical problems where the obvious path is exhausted — blocked, failing, or suspiciously complex — or is heading toward a hidden constraint, a dead end, or an expensive path, and for stress-testing important designs before committing to them. This is not the default workflow. Normal engineering work uses normal development, debugging, and design practices. Apply this method deliberately, when those practices stop producing progress or when a decision warrants deeper, more skeptical analysis. It trades speed for depth, but not for rigor: it does not brainstorm endlessly, does not propose alternatives without evidence, and does not treat every problem as an architectural crisis. ## Core principles 1. **Optimize the objective, not the first implementation chosen.** A proposed implementation is a hypothesis about how to reach an outcome, not the outcome itself. 2. **Ask both questions.** Not only *"How do we solve this within the current constraints?"* but also *"Can we change the architecture, abstraction, interface, dependency, data flow, workflow, or assumption so that the constraint no longer exists?"* Most wasted engineering effort comes from asking only the first. 3. **Diagnose before pivoting.** Many "impossible" problems are ordinary defects. Changing the architecture to escape a misconfigured secret is not a pivot; it is a misdiagnosis. 4. **Evidence over plausibility.** Every claim that a decision