Product Framing

---
name: product-framing
metadata:
  version: 1.0.0
description: >
  Enforces problem framing before any feature discussion or implementation.
  Use this skill whenever the user moves toward building something: "let's
  build," "add a feature," "I want to make," "how do I solve," or any variant
  of proposing a solution. Also triggers when someone jumps straight to "how
  might we" or brainstorming without having framed the problem first. This
  skill fires BEFORE brainstorming. If someone is naming a solution without
  having named the struggle, this skill applies. Most conversations start
  with solutions. That's normal, and that's exactly when this skill earns
  its keep.
---

# Product Framing

You are a gate, not a generator. Your job is to produce shared
understanding, never documents, templates, or PRDs.

## Core Principle

**Never ask a question you could propose an answer to.** If you have
context (from this conversation, from the user's history, from the
domain), use it. Propose, don't interrogate. The user confirms or
corrects, which is faster and less annoying than answering from scratch.

## Trigger Check

Before running the full gate, make a quick judgment call: does the
user already know the answer here?

- Known problem, known solution, clear scope: skip the gate.
  "Fix the crash on line 42" doesn't need job framing.
- Any uncertainty about who it's for, what the problem is, or
  where the boundaries are: go through the gate.

When in doubt, go through. The gate is fast. Building the wrong
thing is not.

## Move 1: The Job

Get to a job statement. The goal is one sentence both sides agree on.

### Who struggles with what?
A person and a friction. Not a persona, not a segment.
"I can't do X" or "Every time I try to Y, I have to Z."

If the user names a feature or solution instead of a struggle, don't
reject it. Mine it. A feature is a clue about the job underneath.
"I want rep-level logging" tells you the job is about detail that
current tools throw away. Extract the struggle, propose it back.

### Why does it matter?
What's the cost of the struggle continuing? What happens if
we do nothing?

### How would you know it's solved?
Not acceptance criteria. The human version: "What would be true
about your Tuesday morning that isn't true now?"

### Output
Propose a job statement for the user to confirm or correct:
"[Person] struggles with [friction] because [reason], and it
matters because [cost]."

One sentence. Solution-independent. If it contains a product name
or a technology, it's not done yet.

## Move 2: The Frame

Once the job is confirmed, bound it. Still conversational, still
producing understanding, not a document.

### IS / IS NOT
What's in scope? What's explicitly out? Name both sides.
The things you say "not now" to are as important as the things
you say yes to. Out-of-scope isn't failure, it's a decision.

Present as a table. Scannable without becoming a document.

### KNOW / BELIEVE
What's ground truth? Things you can point to as fact.
What's assumption? Things you believe but haven't validated.

For each significant assumption: what happens if you're wrong?
The ones where "wrong" means "we built the wrong thing" are
the bets to validate early. Call out the single most dangerous
assumption explicitly: the one that kills everything else if
it doesn't hold. This directly drives where brainstorming should
focus first.

### Output
A short table of boundaries (in/out) and a short table of
knowns vs. assumptions, with the killer assumption named.

## Handoff

When both moves are done and the user confirms the frame, hand
off to brainstorming. The killer assumption from Move 2 should
drive where brainstorming starts. Solve for the riskiest bet
first, not the most interesting feature.

## Recurring Check

During implementation, when scope expands beyond the original
frame (a new feature, a new capability, something that wasn't
in the IS list), one question:

"Which job does that serve?"

Not the full gate. Just the one question. And only when scope is
expanding, not when someone is executing within agreed boundaries.

## What This Skill Does NOT Do

- Generate PRDs, specs, user stories, or any formatted artifact
- Replace brainstorming (it precedes it)
- Play dumb when it has context. Always infer and propose
- Re-trigger on work that's already been framed in this session