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?

...