repo-native-alignment: Skill for Claude Code

/problem-statement

Define the framing. Change the statement, change the solution space.

A problem statement is not the problem itself—it's the lens through which you see the problem. Different framings open different solution spaces. The right framing makes good solutions obvious; the wrong framing makes them invisible.

When to Use

Invoke /problem-statement when:

• Starting new work - Before diving into solutions, articulate what you're actually solving
• Solutions feel off - When proposed solutions seem convoluted or like workarounds
• Oscillating on approach - When you keep changing direction, the framing might be wrong
• Suspected X-Y problem - When someone asks for a specific solution but the underlying need is unclear
• Requirements keep expanding - Scope creep often signals a framing mismatch
• After /aim but before /solution-space - The natural sequence: aim defines outcome, problem statement frames the challenge

Do not use when: You already have a crisp problem statement and are ready to explore solutions. Move to /solution-space.

The Framing Process

Step 1: Surface the Current Framing

Before reframing, understand how the problem is currently being seen:

"The problem is currently framed as: [how it's being described]"

Capture:

• What's the stated problem?
• What assumptions are embedded in how it's described?
• What's being treated as fixed vs. changeable?

Step 2: Detect X-Y Problems

Watch for the X-Y problem pattern: someone asks for Y (their attempted solution) when they actually need X (the real problem).

Signs of X-Y mismatch:

• Request is oddly specific for what seems like a simple goal
• The solution feels like a workaround
• "How do I do [technique]?" without explaining why
• Convoluted multi-step approach to something that should be simple

If X-Y problem detected:

"You're asking for [Y], but the underlying need seems to be [X]. Is that right? If so, we should reframe around [X]."