菜单
Create a framing document from conversation transcripts. Use when the user has transcripts (VTT, call notes, etc.) and wants to produce a frame that captures the problem worth solving and why it was chosen over alternatives.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/rjs/shaping-skills --skill framing-doc命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
| name | framing-doc |
| description | Create a framing document from conversation transcripts. Use when the user has transcripts (VTT, call notes, etc.) and wants to produce a frame that captures the problem worth solving and why it was chosen over alternatives. |
Produce a frame document from one or more conversation transcripts. The frame captures the "why" — what problem to solve and why this one, not the others.
Ask the user:
A frame has three sections:
Capture verbatim quotes from the transcripts. This is ground truth. Everything else in the document is interpretation of this material.
Survey the landscape of options that came up across conversations. This is not background — it's the argument for why we're framing this particular problem.
For each option that surfaced:
Then make the case for the one to pursue now:
Do not invent a roadmap or sequence for the other options. Whether and when they happen is a future decision. The only claim you're making is: this one first, for these reasons.
Problem: What's broken, what pain exists. Render as bullets for easy scanning.
Outcome: What success looks like. Also bullets. Stay high-level — this is not solution-specific.
A guardrail that orients the reader toward what kind of solution fits and away from what kind doesn't. It sits after Problem/Outcome as a separate section. Same format — two symmetric bullet lists.
What it does: Prevents someone from reading the Problem and Outcome correctly but proposing the wrong kind of solution. For example, a problem about getting programs into the system could reasonably lead someone to propose "AI that advises coaches on what to program" — which technically addresses the problem but completely misses the point.
When to include it: When there's a common misunderstanding or an obvious-but-wrong direction that people could easily head toward. The signal is that people in the conversations are actively drawing a line — saying what this is NOT. If nobody felt the need to draw that line, you probably don't need the section.
How it surfaces: This probably won't emerge mechanically from a first pass through the transcripts. It's more likely to surface during review — either the shaper notices a pattern of people saying "not about X," or someone reading the frame proposes something that fits the Problem/Outcome but misses the point. That's the moment where you realize the boundary needs to be made explicit.
What it looks like:
## Less about
- [What this project is NOT trying to solve]
- [The wrong direction people might naturally head toward]
## More about
- [What kind of solution actually fits]
- [The real nature of the problem being addressed]
No quotes or attribution needed — it's a synthesis. Keep it to the key points.
After writing each line in Problem and Outcome, ask: who said this, and where?
Don't connect dots and present inferences as facts. "Coaches bounce during trials because data entry is too hard" sounds plausible but if nobody said it, don't write it as established truth.
Don't embellish for vividness. Adding specificity that nobody stated ("every exercise, set, rep, and percentage") to make the problem sound more concrete is editorializing.
Don't inflate the options list. An idea that one person mentioned and nobody picked up is not an "option with traction." Be honest about signal strength. Ask yourself: did multiple people raise this independently? Did others build on it or let it die?
Don't editorialize in the Problem statement. Phrases like "TB has to earn the switch" or "the single biggest friction point" are rhetoric, not evidence. Make the case using what was said.
Don't present your framing as their words. Keep your interpretive voice separate from what was actually said. The Source section is theirs. Problem/Outcome are your distillation — and should be traceable back to Source.
After drafting, examine every line in Problem and Outcome:
Do the same for the pre-work options table. For each option listed, verify:
Be willing to shrink the options list. Fewer real options are better than a padded list.
---
shaping: true
---
# [Topic] — Frame
## Source
### [Speaker] ([Date])
> "Verbatim quote..."
> "Another quote..."
[Brief connective context where needed.]
### [Speaker] ([Date])
> "Verbatim quote..."
---
## Pre-work: [Topic] Options Landscape
[N] options surfaced with real traction across conversations:
| Option | What it does | Who benefits | Signal strength |
|--------|-------------|--------------|-----------------|
| **A. [Name]** | ... | ... | ... |
| **B. [Name]** | ... | ... | ... |
([Note on ideas that were mentioned but didn't get traction — dropped.])
**Why A now:** [Evidence-based argument for urgency/importance.]
---
## Problem
- [Bullet — traceable to source]
- [Bullet — traceable to source]
## Outcome
- [Bullet — high-level, not solution-specific]
- [Bullet — high-level, not solution-specific]
---
## Less about
- [What this is not]
## More about
- [What this is]
Turn a shaped project kickoff transcript into a reference document for the builder. Use when the user has a transcript (VTT, etc.) from a kickoff call and wants to produce a document that captures what was shaped and agreed.
Use this methodology when collaboratively shaping a solution with the user - iterating on problem definition (requirements) and solution options (shapes).
Transform a workflow description into affordance tables showing UI and Code affordances with their wiring. Use to map existing systems or design new ones from shaped parts.
基于 SOC 职业分类
