framing-doc

name	framing-doc
description	Create a framing document from notes, messages, or conversation transcripts.

Framing Document

Use this skill when people have talked about a problem but the team still needs a clear statement of what matters and why this is the thing worth solving now.

Goal

Create a framing document with four main parts:

• source
• problem
• outcome
• boundaries

When the source already suggests standards by which a solution should be judged, also capture optional criteria candidates for the shaping step.

When the source material includes multiple options or directions, make clear why this frame is being chosen now instead of the others.

Before you start

If the user has transcripts or multiple source files, clarify:

1. which files or notes are in scope
2. what topic area they are about
3. whether there were other options under consideration

Read the source material before framing. Do not infer the frame from a partial read.

What a frame contains

Source

Capture the raw material first. Keep quotes, notes, or transcript excerpts separate from your interpretation.

This is ground truth. Everything else in the document is interpretation of this material.

Pre-work

When the conversations surfaced multiple possible directions, summarize the option landscape briefly:

• what options came up
• who they seemed to benefit
• why this problem is the one worth framing now
• why the others are not the priority right now

Do not invent a roadmap for the others.

Problem

Describe what is broken, painful, risky, or missing.

Outcome

Describe what success looks like at the level of effect.

Boundaries

Add boundaries when there is an obvious wrong direction to avoid.

Use Less about / More about when people were clearly drawing a line around what kind of solution fits and what kind does not.

Criteria candidates (optional)

Capture preliminary standards only when the source clearly suggests what a good solution must achieve or avoid.

Use IDs such as R0, R1, and R2, but mark the section as candidates rather than accepted requirements. The shaping step is responsible for testing, revising, prioritizing, or rejecting them.

Criteria candidates must:

• describe needs, outcomes, or constraints rather than mechanisms
• remain traceable to the source or be marked as inference
• avoid selecting a solution direction
• avoid must-have / nice-to-have status unless a human already made that decision

Key discipline: evidence, not editorializing

For every problem or outcome line, ask:

• what in the source supports this?
• who said this, and where?
• is this a direct quote, a clear implication, or a leap?
• did I accidentally slip a solution into the frame?

If you cannot trace the claim back to the source, cut it.

Common traps to avoid

• Do not turn a plausible inference into an established fact.
• Do not add rhetorical intensity that the source did not support.
• Do not pad the options landscape with weak signals.
• Do not hide solution design inside the problem statement.
• Do not summarize the conversations instead of distilling them.

Recommended structure

---
planning: true
shaping: true
artifact_type: frame
status: draft
source_of_truth: true
feeds:
  - shaping
  - context-packet
---

# [Project] — Frame

# Context Card

## Use this when
An agent is deciding whether later shaping, breadboarding, or implementation still fits the original problem and desired outcome.

## Must preserve
- source-separated evidence
- problem/outcome distinction
- explicit boundaries and non-goals

## Ignore unless asked
- rejected option details beyond the brief option landscape

## Source
> ...

## Pre-work
- option landscape
- why this one now

## Problem
- ...

## Outcome
- ...

## Less about
- ...

## More about
- ...

## Criteria candidates (optional)

| ID | Candidate criterion | Evidence or inference |
|---|---|---|
| R0 | ... | ... |

Rules

• Keep source separate from interpretation.
• Keep outcome focused on the result, not the mechanism.
• Make each problem and outcome line traceable to the source.
• Use boundaries only when they help prevent a likely wrong direction.
• Treat criteria candidates as preliminary input to shaping, not accepted requirements.
• The frame is the why, not the how.

Self-check before finishing

• Source material is separate from interpretation.
• Every problem and outcome claim is traceable to source material or explicitly marked as an inference.
• Outcome lines describe effects, not mechanisms.
• Boundaries prevent likely wrong directions without over-constraining the solution space.
• Criteria candidates, when present, describe needs or constraints, remain traceable, and are clearly preliminary.
• Any option landscape explains why this frame is chosen now without creating a roadmap for rejected options.
• The artifact has planning frontmatter and a Context Card when it will feed downstream agent work.