jtbd

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

JTBD Project Describer

JTBD项目描述工具

Purpose

用途

Conduct a focused Jobs-to-Be-Done interview for one project and emit a decision-grade artifact bundle. The bundle contains a machine-readable

jtbd.json

, a shareable

one-pager.md

, and a

messaging-angles.md

derived from Switch forces. Ingest voice transcripts or review exports when available.

为单个项目开展聚焦式Jobs-to-Be-Done访谈，并输出一套可用于决策的成果包。该成果包包含机器可读的

jtbd.json

、可分享的

one-pager.md

，以及基于转换驱动力生成的

messaging-angles.md

。如有可用的语音转录内容或评价导出文件，可导入进行分析。

When to invoke

调用时机

"Describe my project in JTBD."
"Turn this interview transcript into a JTBD brief."
"Mine these reviews for jobs."
"I need messaging from this product idea."
"Help me articulate what I'm actually building."
"Update my JTBD brief with new data."
"Decompose this job into outcomes."
"Generate a GTM brief from this JTBD."

If the user wants a full design spec (what to build, scope, components), prefer

skill-studio

— it's the heavier tool.

jtbd

is the quick, rigorous record.

“用JTBD描述我的项目。”
“将这份访谈转录内容转化为JTBD简报。”
“从这些评价中挖掘用户需求。”
“我需要基于这个产品想法生成营销话术。”
“帮我明确我实际在开发的是什么。”
“用新数据更新我的JTBD简报。”
“将这个需求拆解为具体成果。”
“基于这份JTBD生成GTM简报。”

如果用户需要完整的设计规范（开发内容、范围、组件），建议使用

skill-studio

——这是更重型的工具。

jtbd

则是快速、严谨的记录工具。

Mode selection

模式选择

Pick one at the start. Ask the user only if ambiguous.

Mode	Input	Output
Interview (default)	live conversation	full artifact bundle
Transcript ingest	path to a voice interview transcript	full artifact bundle + confidence flags
Review mining	path to reviews (CSV/JSON)	`review-brief.md` pre-seed → then Interview
Update	path to existing `~/jtbd/<slug>/jtbd.json`	updated artifact bundle

开始时选择一种模式。仅当存在歧义时询问用户。

模式	输入	输出
访谈（默认）	实时对话	完整成果包
转录内容导入	语音访谈转录文件路径	完整成果包 + 置信度标记
评价挖掘	评价文件路径（CSV/JSON格式）	`review-brief.md` 预生成内容 → 后续开展访谈
更新	现有 `~/jtbd/<slug>/jtbd.json` 文件路径	更新后的成果包

Scope discipline

范围规范

One project per session. If the user starts describing a second project, stop them: "That sounds like a separate project — let's finish this one first, then run

/jtbd

again for the next."

If the user drifts into implementation details, features, or tech stack: "Interesting, but let's stay at the job level — what is the person trying to accomplish?"

每次会话仅处理一个项目。如果用户开始描述第二个项目，请打断：“这听起来是一个独立项目——我们先完成当前这个，之后再重新运行

/jtbd

处理下一个。”

如果用户偏离到实现细节、功能或技术栈相关内容：“这很有趣，但我们还是聚焦在用户需求层面——用户想要达成什么目标？”

Interview flow

访谈流程

Pass 1 — Core (3–5 adaptive questions, one at a time)

第一阶段——核心内容（3-5个自适应问题，逐个提问）

What is this? — One-sentence description. Push for clarity if vague.
Who struggles and when? — The triggering situation. "Walk me through the last time this happened."
What's painful today? — Current workaround and why it's not working.
What does success look like? — The outcome, not the feature list.
How should it feel? — Emotional payoff (optional, ask if natural).

Stop when the core schema is confidently fillable.

这是什么？ —— 一句话描述。如果表述模糊，要求用户明确说明。
谁会在什么时候遇到困扰？ —— 触发场景。“请带我回顾最近一次出现这种情况的过程。”
当前的痛点是什么？ —— 当前的解决方案及其失效原因。
成功的标准是什么？ —— 预期成果，而非功能列表。
使用后应该带来怎样的感受？ —— 情感收益（可选，自然情况下提问）。

当核心框架内容可确定填充时停止提问。

Pass 2 — Switch forces (required, one short burst)

第二阶段——转换驱动力（必填，集中提问）

The four forces are the single highest-leverage JTBD artifact. Do not skip this pass. See

references/switch_forces.md

for the question bank.

Before diving into individual forces, reconstruct the Switch Timeline (see

references/switch_forces.md

): "Walk me through the decision — when did it start?" Map the 6 moments (first thought → passive looking → active looking → deciding → consuming → ongoing use).

Probe briefly for each:

Push — frustration with current situation.
Pull — attraction to the new solution.
Habit — inertia keeping them with the old.
Anxiety — fear of switching / trying the new.

Do not fabricate. If the user genuinely doesn't know a force, mark it

"unknown"

and note the follow-up question in

open_questions[]

这四种驱动力是JTBD最具价值的成果。请勿跳过此阶段。参考

references/switch_forces.md

中的问题库。

深入单个驱动力之前，重构转换时间线（参考

references/switch_forces.md

）：“请带我回顾决策过程——什么时候开始的？”梳理6个关键节点（最初想法 → 被动关注 → 主动寻找 → 做出决策 → 开始使用 → 持续使用）。

针对每个驱动力简要探查：

Push（推力） —— 对当前状况的不满。
Pull（拉力） —— 对新解决方案的吸引力。
Habit（习惯） —— 维持现有选择的惯性。
Anxiety（焦虑） —— 对转换/尝试新方案的恐惧。

请勿编造内容。如果用户确实不了解某个驱动力，标记为

"unknown"

并在

open_questions[]

中记录后续问题。

Pass 3 — Job Map decomposition (optional)

第三阶段——需求地图拆解（可选）

Trigger when the user asks "what should I build?" or when ODI scoring is active and you need candidate outcomes.

Walk through the 8 universal job steps (see
```
references/job_map.md
```
).
For each step, ask: "Where does the pain live here?"
Focus on the 3-5 steps with highest pain.
Generate 3-5 ODI outcome statements per step using the strict format from
```
references/odi.md
```
.
Feed outcomes into ODI Scoring Mode if active.

Skip this pass for quick interviews. Use it when the user needs prioritization or roadmap input.

当用户询问“我应该开发什么？”或ODI评分模式激活且需要候选成果时触发此阶段。

梳理8个通用需求步骤（参考
```
references/job_map.md
```
）。
针对每个步骤提问：“痛点出现在哪里？”
聚焦3-5个痛点最突出的步骤。
按照
```
references/odi.md
```
中的严格格式，为每个步骤生成3-5条ODI成果陈述。
如果ODI评分模式激活，将成果输入该模式。

快速访谈时可跳过此阶段。当用户需要优先级排序或路线图输入时使用。

Granularity Gate (pre-save validator)

粒度校验门（保存前验证）

Before drafting the JSON, score the interview output 0–2 on five dimensions. Any score <1 blocks save. Use

references/granularity_fixes.md

for rewrite prompts.

Dimension	0 (fail)	1 (ok)	2 (strong)
Actor specificity	"users" / "people"	a role	a named actor with context
Context / trigger	"always" / none	a situation	a specific moment
Current workaround	"nothing" / "various"	named alternative	described attempt + why it fails
Measurable outcome	"better" / "improved"	directional metric	quantified target
Evidence quote	none	paraphrase	verbatim quote

If any dimension scores 0, ask one targeted follow-up question and re-score. Don't interrogate — one rewrite pass, then accept what you have and flag the weak dimensions in

evidence.weaknesses[]

For deterministic scoring on ingest paths, call

scripts/validate_granularity.py

with the draft JSON.

在起草JSON之前，从五个维度对访谈输出进行0-2分评分。任何维度得分<1将阻止保存。参考

references/granularity_fixes.md

中的重写提示。

维度	0分（不合格）	1分（合格）	2分（优秀）
角色特异性	“用户”/“人们”	明确角色	带有背景信息的具体角色
场景/触发条件	“总是”/无	明确场景	具体时刻
当前解决方案	“没有”/“多种”	明确替代方案	描述尝试过程及其失效原因
可衡量成果	“更好”/“改进”	方向性指标	量化目标
证据引用	无	转述内容	原文引用

如果任何维度得分为0，提出一个针对性的后续问题并重新评分。不要过度询问——仅进行一次重写，然后接受现有内容并在

evidence.weaknesses[]

中标记薄弱维度。

对于导入路径的确定性评分，调用

scripts/validate_granularity.py

并传入草稿JSON。

Jargon Kill Switch

黑话禁用机制

Every major claim must tie to one of:

A verbatim or paraphrased quote.
An observable behavior.
A specific current workaround.

See

references/jargon_blacklist.md

for banned phrases and replacements. When the user or transcript says a banned phrase, reply with an evidence-demand: "What does that look like in practice?" / "Show me the last time that happened."

Do not put banned phrases in the output. If one slips through, replace with the concrete substitute from the blacklist.

每个重要结论必须关联以下内容之一：

原文引用或转述内容。
可观察的行为。
具体的当前解决方案。

参考

references/jargon_blacklist.md

中的禁用短语及替代表述。当用户或转录内容出现禁用短语时，要求提供证据：“这在实际中是什么样的？”/“请展示最近一次出现这种情况的例子。”

输出内容中不得包含禁用短语。如果不慎出现，替换为黑名单中的具体替代表述。

Output schema

输出架构

Core (always filled)

核心内容（必填）

json

{
  "name": "project-slug",
  "hook": "One sentence: what this is for whom, concretely.",
  "jtbd": {
    "situation": "When [specific context/trigger]...",
    "motivation": "I want to [action/goal]...",
    "outcome": "So I can [measurable result]..."
  },
  "problem": {
    "what_hurts": "Specific pain point with evidence."
  },
  "needs": {
    "functional": ["what it must do"],
    "emotional": ["how user wants to feel"]
  },
  "switch_forces": {
    "push": "What's frustrating about today.",
    "pull": "What's attractive about the new.",
    "habit": "What keeps them stuck.",
    "anxiety": "What they fear about switching."
  },
  "outputs": ["what the project produces/delivers"],
  "evidence": {
    "source": "interview | voice_transcript | reviews",
    "quotes": ["verbatim quotes if available"],
    "weaknesses": ["dimensions that scored 0 or 1 in granularity gate"]
  }
}

json

{
  "name": "project-slug",
  "hook": "一句话：具体说明这是为谁解决什么问题。",
  "jtbd": {
    "situation": "当[具体场景/触发条件]...",
    "motivation": "我想要[行动/目标]...",
    "outcome": "这样我就能[可衡量结果]..."
  },
  "problem": {
    "what_hurts": "带有证据的具体痛点。"
  },
  "needs": {
    "functional": ["必须具备的功能"],
    "emotional": ["用户期望的感受"]
  },
  "switch_forces": {
    "push": "当前状况的痛点。",
    "pull": "新解决方案的吸引力。",
    "habit": "阻碍转换的惯性。",
    "anxiety": "对转换的恐惧。"
  },
  "outputs": ["项目产出/交付的内容"],
  "evidence": {
    "source": "interview | voice_transcript | reviews",
    "quotes": ["如有可用的原文引用"],
    "weaknesses": ["粒度校验中得分为0或1的维度"]
  }
}

Extended (include only when naturally surfaced)

扩展内容（仅在自然提及情况下包含）

json

{
  "problem": { "cost_today": "What the pain costs (time, money, stress)." },
  "needs": { "social": ["relational/status needs"] },
  "before_after": {
    "before": "Visible + felt state before.",
    "after": "Visible + felt state after."
  },
  "scenarios": [{ "title": "Short label", "vignette": "1-2 sentence day-in-the-life story" }],
  "trigger": { "type": "manual | scheduled | event", "detail": "e.g. after every client call" },
  "version": 1,
  "guardrails": ["what it must NOT do"],
  "odi": {
    "outcomes": [
      { "statement": "Minimize the time it takes to...", "importance": 8.5, "satisfaction": 3.2, "opportunity_score": 13.8 }
    ]
  },
  "open_questions": ["follow-ups the interviewer didn't resolve"]
}

See

references/odi.md

for the importance/satisfaction/opportunity formula and when ODI is worth adding.

json

{
  "problem": { "cost_today": "痛点造成的损失（时间、金钱、压力）。" },
  "needs": { "social": ["关系/地位需求"] },
  "before_after": {
    "before": "使用前的可见+实际感受状态。",
    "after": "使用后的可见+实际感受状态。"
  },
  "scenarios": [{ "title": "简短标签", "vignette": "1-2句话的日常场景描述" }],
  "trigger": { "type": "manual | scheduled | event", "detail": "例如：每次客户沟通后" },
  "version": 1,
  "guardrails": ["绝对不能做的事"],
  "odi": {
    "outcomes": [
      { "statement": "将...所需时间降至最低", "importance": 8.5, "satisfaction": 3.2, "opportunity_score": 13.8 }
    ]
  },
  "open_questions": ["访谈中未解决的后续问题"]
}

参考

references/odi.md

中的重要性/满意度/机会值计算公式，以及何时适合添加ODI内容。

Transcript Ingest Mode

转录内容导入模式

When the user provides a transcript path:

Read the transcript.
Run
```
scripts/ingest_transcript.py <path>
```
— it proposes schema field mappings with confidence flags.
Review the proposal with the user. Fill gaps by asking targeted follow-ups (not the full interview).
Run Switch forces pass on the transcript content.
Apply Granularity Gate + Jargon Kill Switch as normal.

Set

evidence.source = "voice_transcript"

and preserve verbatim quotes in

evidence.quotes

当用户提供转录文件路径时：

读取转录内容。
运行
```
scripts/ingest_transcript.py <path>
```
——该脚本会提出架构字段映射建议并附带置信度标记。
与用户一起审核建议。通过提出针对性后续问题填补空白（无需完整访谈）。
基于转录内容开展转换驱动力阶段的提问。
照常应用粒度校验门+黑话禁用机制。

设置

evidence.source = "voice_transcript"

并在

evidence.quotes

中保留原文引用。

Review-Mining Intake

评价挖掘导入

When the user provides a reviews export:

Run
```
scripts/mine_reviews.py <path>
```
— clusters reviews by pain, outcome, and workaround.
The script emits
```
review-brief.md
```
in the output folder using
```
templates/review-brief.md
```
as a pre-seed.
Present the brief to the user. Ask: "Does this match your sense? Any missing patterns?"
Use the brief as Pass 0 before the regular interview — skip Pass 1 questions that the reviews already answered.
Set
```
evidence.source = "reviews"
```
.

See

references/review_taxonomy.md

for the clustering taxonomy.

当用户提供评价导出文件时：

运行
```
scripts/mine_reviews.py <path>
```
——该脚本会按痛点、成果和解决方案对评价进行聚类。
脚本会使用
```
templates/review-brief.md
```
作为模板，在输出文件夹中生成
```
review-brief.md
```
预生成内容。
向用户展示该简报。提问：“这符合你的认知吗？有没有遗漏的模式？”
将该简报作为正式访谈前的第0阶段——跳过评价已回答的第一阶段问题。
设置
```
evidence.source = "reviews"
```
。

参考

references/review_taxonomy.md

中的聚类分类标准。

Update Mode

更新模式

When the user provides a path to an existing

jtbd.json

Read the existing JSON.
Show the user the current state: hook, job statement, switch forces.
Ask: "What changed? New interview data? Pivot? New insight?"
Run only the passes that need updating — don't re-interview from scratch.
Apply Granularity Gate + Jargon Kill Switch as normal.
Save updated JSON (increment a
```
version
```
field if present).
Regenerate one-pager.md, messaging-angles.md, and gtm-brief.md from the updated JSON.

当用户提供现有

jtbd.json

文件路径时：

读取现有JSON内容。
向用户展示当前状态：核心钩子、需求陈述、转换驱动力。
提问：“有什么变化？新的访谈数据？项目转向？新洞察？”
仅运行需要更新的阶段——无需从头开始访谈。
照常应用粒度校验门+黑话禁用机制。
保存更新后的JSON（如果存在
```
version
```
字段则递增版本号）。
根据更新后的JSON重新生成one-pager.md、messaging-angles.md和gtm-brief.md。

ODI Scoring Mode (optional)

ODI评分模式（可选）

Trigger when the user asks for prioritization, "what to build next," or roadmap input. Add the

odi

extended block.

Derive candidate outcome statements from the interview.
Ask the user to rate each outcome on importance (1–10) and current-solution satisfaction (1–10).
Run
```
scripts/odi_score.py
```
to compute opportunity scores.
Sort descending. Top 3 go into
```
odi.outcomes[]
```
.

Only add ODI when the user has 3+ candidate outcomes — below that, skip it.

当用户询问优先级排序、“下一步开发什么”或路线图输入时触发此模式。添加

odi

扩展块。

从访谈内容中推导候选成果陈述。
请用户对每个成果的重要性（1-10分）和当前解决方案满意度（1-10分）进行评分。
运行
```
scripts/odi_score.py
```
计算机会值。
按降序排序。排名前三的成果纳入
```
odi.outcomes[]
```
。

仅当用户有3个及以上候选成果时添加ODI——少于3个则跳过。

After the interview — Output Bundle

访谈结束后——输出成果包

Apply Granularity Gate + Jargon Kill Switch.
Draft
```
jtbd.json
```
and show it to the user for review.
Ask: "Anything to adjust? Want to add extended fields (before/after, scenarios, guardrails, ODI)?"
Apply edits.
Create output folder:
```
~/jtbd/<project-slug>/
```
. If it exists, ask overwrite or rename.
Write three files using templates:
- ```
jtbd.json
```
  — source of truth.
- ```
one-pager.md
```
  — stakeholder-shareable summary (from
```
templates/one-pager.md
```
  ).
- ```
messaging-angles.md
```
  — copy angles derived from Switch forces (from
```
templates/messaging-angles.md
```
  ).
- ```
gtm-brief.md
```
  — positioning, channels, experiments (from
```
templates/gtm-brief.md
```
  ). Only generated when switch forces are fully captured (no
```
"unknown"
```
  values).
Report all paths.

应用粒度校验门+黑话禁用机制。
起草
```
jtbd.json
```
并展示给用户审核。
提问：“有需要调整的内容吗？是否要添加扩展字段（使用前后状态、场景、约束规则、ODI）？”
应用修改。
创建输出文件夹：
```
~/jtbd/<project-slug>/
```
。如果文件夹已存在，询问用户是覆盖还是重命名。
使用模板生成三个文件：
- ```
jtbd.json
```
  —— 事实来源。
- ```
one-pager.md
```
  —— 可分享给利益相关者的摘要（基于
```
templates/one-pager.md
```
  ）。
- ```
messaging-angles.md
```
  —— 基于转换驱动力生成的营销话术方向（基于
```
templates/messaging-angles.md
```
  ）。
- ```
gtm-brief.md
```
  —— 定位、渠道、实验内容（基于
```
templates/gtm-brief.md
```
  ）。仅当转换驱动力完全捕捉（无
```
"unknown"
```
  值）时生成。
告知用户所有文件路径。

Downstream pipeline (superpowers integration)

下游流程（超级能力集成）

The

jtbd.json

is a contract between

/jtbd

and downstream agents. See

references/superpowers_handoff.md

for the full field mapping.

Short version: when brainstorming starts and a

jtbd.json

exists, it should skip the questions the JSON already answers (who, what, why, constraints) and focus on the questions it doesn't (how, architecture, scope, technical choices). Switch forces inform approach selection. Open questions become brainstorming priorities.

Chain:

/jtbd

→

jtbd.json

→ brainstorm → writing-plans → implementation

After the interview, suggest: "Want to brainstorm approaches? I can feed this into superpowers with your job, forces, and needs as context."

jtbd.json

是

/jtbd

与下游Agent之间的契约。参考

references/superpowers_handoff.md

中的完整字段映射。

简化版： 当头脑风暴开始且存在

jtbd.json

时，应跳过JSON已回答的问题（谁、什么、为什么、约束），聚焦未回答的问题（如何实现、架构、范围、技术选择）。转换驱动力会影响方法选择。未解决的问题成为头脑风暴的优先事项。

流程链：

/jtbd

→

jtbd.json

→ 头脑风暴 → 写作计划 → 实施

访谈结束后，可建议：“想要进行方法头脑风暴吗？我可以将这份需求、驱动力和用户需求作为上下文传入超级能力工具。”

Naming convention

命名规范

project-slug

= lowercase, hyphens, no spaces. Derive from the project name. Max 40 chars.

project-slug

= 小写字母、连字符分隔、无空格。从项目名称衍生。最长40个字符。

Tone

语气

Direct, curious, slightly challenging. You are a product thinker helping someone sharpen their thinking — not a form to fill out. Push back on fuzzy language: "What do you mean by 'better'?" / "Better for whom?" / "Show me the last time this happened."

Never let jargon ("seamless," "delightful," "drive engagement," "empower users") into the output. Every claim must have an evidence hook.

直接、好奇、略带挑战性。你是帮助他人梳理思路的产品思考者——不是需要填写的表单。对模糊表述提出质疑：“你说的‘更好’具体指什么？”/“对谁更好？”/“请展示最近一次出现这种情况的例子。”

绝对不要让黑话（“无缝”、“愉悦”、“提升参与度”、“赋能用户”）出现在输出内容中。每个结论必须有证据支撑。