Fpf Problem Framing

What this skill IS

This is creative problem design, not paperwork. You are designing the problem — choosing what to solve, defining what "solved" means, identifying trade-off axes. In a world of cheap solution generation, this is the scarce skill.

Work through the template as scaffolding for your thinking. Don't think in chat and fill the template afterward — the template IS the thinking tool.

Auto-invoke triggers

• Debugging or investigating anomaly
• Designing new feature or capability
• Facing architecture or design decision
• Requirements unclear or ambiguous
• Starting substantive work without a defined problem

Scope assessment

• Quick (ANOM-*): Localized bug, single hypothesis likely, fix straightforward
• Substantive (PROB-*): Multiple approaches, trade-offs exist, needs variant generation

When in doubt → start as ANOM-, promote to PROB- if complexity emerges. Graduation criteria: If you find yourself writing ≥3 hypotheses, or the fix isn't obvious, promote to PROB-*.

Creative problem design guidance

Framing matters more than solving. A well-framed problem makes the solution factory efficient. A poorly-framed problem produces noise regardless of how many variants you generate.

Ask these while filling the template:

• Is this a goldilocks problem? (feasible-but-hard, not trivial, not impossible)
• What's the zone of proximal development? (what can be solved with known methods but isn't obvious?)
• What trade-off axes exist? (if there's no trade-off, it's not on the frontier)
• Could reframing this problem open new solution spaces?
• What stepping stones might this produce even if the direct solution fails?

Reframing moves: If the initial framing feels too narrow or too broad:

• Split: one problem into multiple with different trade-off axes
• Merge: related symptoms into a single root-cause problem
• Invert: "prevent X" → "enable Y"; "fix bug" → "redesign for correctness"
• Zoom out: from symptom to system property
• Zoom in: from vague goal to specific measurable indicator

Output

• ANOM: .fpf/anomalies/ANOM-${CLAUDE_SESSION_ID}--<slug>.md
• PROB: .fpf/anomalies/PROB-${CLAUDE_SESSION_ID}--<slug>.md

Format rules (hooks check these patterns)

• Hypotheses MUST be labeled H1:, H2:, H3: etc. at line start
• This is required for mechanical validation by hooks

Constraints (quality bar)

• C1: Problem statement in ≤1 paragraph (signal, current state, desired state, impact)
• C2: ≥3 hypotheses for PROB-* (each with parsimony + explanatory power + falsifiability)
• C3: Prime hypothesis selected with predictions (what would confirm/falsify)
• C4: Minimum viable test plan defined
• C5: PROB-* MUST have goldilocks assessment (measurability, reversibility, stepping-stone potential, trade-off axes)
• C6: PROB-* MUST have acceptance spec (indicators from CHR-, criteria, baseline, required evidence). For simple T3, inline indicators with threshold: and measurement: in the acceptance spec can substitute for a separate CHR- artifact.
• C7: Separate observations (facts) from assumptions (design-time)
• C8: valid_until set — problem framings go stale (context changes, requirements shift). Set expiry date or "perpetual" with justification.

Format — ANOM-*

# Anomaly Record
- **ID:** ANOM-...  **Status:** Open  **Created:** YYYY-MM-DD

## What happened
(signal + observations — facts only, assumptions separate)

## Hypotheses
H1: ...
H2: ...

## Prime hypothesis + predictions
...

## Test plan
...

Format — PROB-*

# Problem Card
- **ID:** PROB-...  **Status:** Open  **Created:** YYYY-MM-DD
- **Lifecycle state:** Explore|Shape|Evidence|Operate
- **valid_until:** YYYY-MM-DD (when does this problem framing go stale?)

## Problem statement
- **Signal:** ...  **Current:** ...  **Desired:** ...  **Impact:** ...

## Constraints
...

## Hypotheses
H1: ... (parsimony, explanatory power, falsifiability)
H2: ...
H3: ...

## Prime hypothesis + predictions
...

## Goldilocks assessment
- Measurability: (can you verify a solution without guessing?)
- Reversibility: (what's the blast radius if wrong?)
- Stepping-stone potential: (does solving this open new solution spaces?)
- Trade-off axes: (what competing goals exist?)

## Acceptance spec
- Indicators: (from CHR-* passport)
- Criteria: (what "good enough" means)
- Baseline: (current measured state)
- Required evidence: (what EVID-* must show)

## What would change this problem?
...