The Problem Hammer

What Problem It Solves

When debugging product friction, architecture conflicts, or business decisions, the hard part is often not finding an answer but identifying the real question. The Problem Hammer focuses on deconstructing vague problems by separating surface symptoms from core contradictions, hidden assumptions, goal conflicts, and irreversible constraints. It is not designed to give a final engineering answer; it is designed to push an ambiguous input toward a clearer first-principles question and a possible way forward.

How It Works

The skill uses a Socratic questioning workflow. After receiving user input, it first locks the target by restating the problem and locating the core contradiction. It then enters a loop of structured questioning. Each layer combines two dimensions:

• Vertical logic drills: questions along causal chains, purpose, definition, assumptions, and inversion, asking why something happens, what goal it serves, what its core definition is, which assumptions are hidden, and whether the opposite would hold.
• Lateral counter-intuitive hammers: challenges from counter-intuition, counter-consensus, counter-patterns, counter-human nature, and counter-mainstream perspectives, so the analysis does not simply follow default beliefs.

Each layer produces a question process, a brief analysis, and an insight. The loop stops when the reasoning reaches an axiomatic point, becomes circular, or reaches a state of extreme simplicity. At that point, the skill extracts the first-principles question and a breakthrough direction, then renders the result as a structured Markdown card. This makes it useful for design reviews, requirement decomposition, architecture discussions, and postmortems.

Boundaries and Caveats

This skill is most useful for ambiguous, high-level, or conflicting-goal problems, such as “why does this requirement keep changing,” “why does this caching design fail,” or “should this KPI exist at all.” For simple factual questions, direct operational commands, or tightly scoped implementation tasks, the questioning loop may be overkill. Providing business context, constraints, and rejected alternatives will improve the result. The generated “breakthrough direction” should be treated as an analytical clue rather than a ready-to-run engineering plan.