pocket-pitching

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pocket Pitching

Pocket Pitching

Pre-grinding problem exploration. Scans project context before making project-specific claims, picks 3-5 brainstorming methods based on problem type, runs them with independent advisor curation, investigates technical unknowns that could change the approach, then produces a pitch exploration doc with a problem statement and 2-3 approach directions.
Core principle: Diverge first, converge second. Never propose solutions until the problem is fully explored.
Start from the user's request. Use clear instructions, corrections, and approvals already given; do not ask the user to repeat them or select a numbered option. Ask only when an unanswered product decision or fact would materially change the exploration. Otherwise, inspect available context, proceed, and label any assumption that affects the result.
pocket-grinding 前的问题探索。在提出项目特定主张之前扫描项目上下文,根据问题类型选择 3-5 种头脑风暴方法,使用独立 advisor 评审结果,调查可能改变方案方向的技术未知项,随后生成包含问题陈述和 2-3 个方案方向的 pitch 探索文档。
核心原则: 先发散,后收敛。在问题得到充分探索之前,绝不提出解决方案。
从用户请求开始。使用对话中已经给出的明确指令、修正和批准;不要要求用户重复这些内容或选择编号选项。仅当某个尚未回答的产品决策或事实会实质影响探索结果时才提问。否则,检查可用上下文并继续执行,同时标注任何会影响结果的假设。

When to Use

使用时机

Trigger when:
  • Problem is vague, unformed, or needs exploration before spec-writing
  • User says "pitch", "explore", "I have a rough idea", "help me think through this"
  • Starting a new feature with no clear direction
Do NOT use:
  • When problem is already clearly defined (use pocket-grinding)
  • When a spec already exists (use pocket-grinding or pocket-planning)
  • For "brainstorm" keyword — pocket-grinding owns that trigger
触发条件:
  • 问题模糊、尚未成形,或在编写 spec 前需要探索
  • 用户说“pitch”、“explore”、“I have a rough idea”、“help me think through this”
  • 启动尚无明确方向的新功能
不要用于:
  • 问题定义已经明确的情况(使用 pocket-grinding)
  • 已经存在 spec 的情况(使用 pocket-grinding 或 pocket-planning)
  • “brainstorm”关键词——该触发条件归 pocket-grinding 所有

Boundary with pocket-grinding

与 pocket-grinding 的边界

pocket-pitchingpocket-grinding
Explores the problem spaceSpecifies the solution
Produces: directions (sync vs async, new module vs extension)Produces: concrete architecture + GWT scenarios
No GWT scenarios — just directionalFull BDD spec with acceptance criteria
2-3 approach directions, no designDesign proposals with scenarios-validated tradeoffs
When pitching output lands in
docs/pocket/spec/
, grinding reads it as INPUT context — not as a spec.
pocket-pitchingpocket-grinding
探索问题空间明确解决方案
产出:方向(sync vs async、new module vs extension)产出:具体架构 + GWT 场景
不包含 GWT 场景——只提供方向包含验收标准的完整 BDD spec
提供 2-3 个方案方向,不做设计提供经过场景验证权衡的设计提案
当 pitch 输出落盘到
docs/pocket/spec/
时,grinding 会将其作为 INPUT 上下文读取,而不是将其视为 spec。

Operating Rules

操作规则

  • Use project evidence. Scan the project before making project-specific claims. If the user already gave the topic, begin exploring it; do not restart intake with a generic greeting.
  • Confirm only new decisions. Restate the problem and continue when the summary preserves the user's meaning. Ask for confirmation only when your interpretation adds a consequential assumption or a product choice remains open. Treat the user's clear correction or approval as the answer.
  • Get independent curation. After all method results are visible, call
    advisor()
    . If it is unavailable or fails, use the
    advisor
    subagent fallback in
    references/advisor-brainstorm-protocol.md
    . Do not present your own synthesis as independent review.
  • Change approach when evidence stalls. For a technical unknown, try a distinct source or investigation mode when the first attempt does not answer it. A call count or retry limit is a cue to reassess, not a reason to stop. Record the evidence and carry any unresolved question into the brief and pocket-grinding.
  • Honor an authorized handoff. If the user asks to continue to pocket-grinding, invoke it and pass the brief and open questions. If they have not chosen what to do next, present the choices once and wait.

  • 使用项目证据。 在提出项目特定主张之前扫描项目。如果用户已经给出主题,直接开始探索;不要用通用问候重新开始需求收集。
  • 仅确认新的决策。 重述问题;当摘要保留用户原意时继续。只有当你的理解引入了一个重要假设,或仍存在未决的产品选择时,才请求确认。将用户明确的修正或批准视为答案。
  • 获得独立评审。 所有方法结果都呈现出来后,调用
    advisor()
    。如果该调用不可用或失败,使用
    references/advisor-brainstorm-protocol.md
    中的
    advisor
    子代理 fallback。不要把自己给出的综合结论当作独立评审。
  • 当证据陷入停滞时改变方法。 对于技术未知项,如果首次尝试没有得到答案,请改用不同来源或调查方式。调用次数或重试上限是重新评估的提示,而不是停止的理由。记录证据,并将任何未解决的问题带入 brief 和 pocket-grinding。
  • 遵循已授权的交接。 如果用户要求继续进入 pocket-grinding,则调用它并传递 brief 和未决问题。如果用户尚未选择下一步操作,则一次性呈现选项并等待。

Phase 0: Preflight

阶段 0:预检

Goal: Understand project context before making project-specific claims.
Scan (read-only):
  • Stack: detect from project root files (package.json, Cargo.toml, requirements.txt, go.mod, pom.xml)
  • Architecture: scan top-level dirs (src/, lib/, app/, services/, packages/)
  • Recent commits:
    git log --oneline -10
  • Existing pitch/spec docs: check
    docs/pocket/spec/
    for recent work
Then respond to the request already in the conversation. Include a concise project summary when useful. Ask what the user wants to explore only if they have not already provided a topic.
Example when no topic has been provided:
Project: [name] · Stack: [detected stack] · [architecture pattern]
Recent: [3 most relevant recent commits]

What would you like to explore or pitch today?

目标: 在提出项目特定主张之前理解项目上下文。
扫描(只读):
  • 技术栈:从项目根目录文件检测(package.json、Cargo.toml、requirements.txt、go.mod、pom.xml)
  • 架构:扫描顶层目录(src/、lib/、app/、services/、packages/)
  • 近期提交:
    git log --oneline -10
  • 现有 pitch/spec 文档:检查
    docs/pocket/spec/
    中的近期工作
然后响应对话中已经提出的请求。 在有帮助时附上简洁的项目摘要。仅当用户尚未提供主题时,才询问用户想探索什么。
未提供主题时的示例:
项目:[名称] · 技术栈:[检测到的技术栈] · [架构模式]
近期:[3 个最相关的近期提交]

您今天想探索或 pitch 什么?

Phase 1: Problem Intake

阶段 1:问题收集

Goal: Establish a shared problem framing before diverging.
Process:
  1. Extract the problem, affected person or system, and why it matters from the user's request and available project context.
  2. Identify only missing facts that could change the framing or exploration direction. Ask a focused question for each consequential gap; usually one or two will be enough. Do not stop at an arbitrary question count if a material ambiguity remains.
  3. State the problem in one or two sentences. If it preserves the user's meaning, move to Phase 2. If it adds a consequential assumption, ask the user to correct or confirm that assumption before diverging.
If the problem is too broad to explore usefully, offer a small set of concrete angles and ask which one to pursue. Do not ask for confirmation of facts or choices the user has already made. Silence is not approval for a consequential choice the user has not made.

目标: 在发散前建立共同的问题框定。
流程:
  1. 从用户请求和可用的项目上下文中提取问题、受影响的人员或系统,以及该问题为何重要。
  2. 仅识别可能改变问题框定或探索方向的缺失事实。针对每个关键缺口提出一个聚焦问题;通常一两个就足够。如果仍存在实质性歧义,不要因达到任意问题数量而停止。
  3. 用一两句话陈述问题。如果陈述保留了用户原意,则进入阶段 2。如果陈述引入了一个重要假设,则在发散前请用户纠正或确认该假设。
如果问题过于宽泛,无法进行有效探索,请提供少量具体角度,并询问用户希望继续探索哪一个。不要要求用户确认已经做出的事实或选择。用户尚未做出的重要选择不能因沉默而被视为已批准。

Phase 2: Diverge

阶段 2:发散

Goal: Explore the problem from several useful angles, then have an independent advisor curate the results.
→ Read
references/brainstorming-methods.csv
to select methods
→ Load
references/method-selection.md
for selection criteria and default trio
目标: 从多个有用角度探索问题,然后由独立 advisor 整理结果。
→ 读取
references/brainstorming-methods.csv
以选择方法
→ 加载
references/method-selection.md
以获取选择标准和默认组合

2a — Method Selection

2a——方法选择

Read CSV. Select 3-5 methods based on problem type. Default trio: Question Storming + First Principles Thinking + Six Thinking Hats State selection rationale (1 line per method): "Chose [X] because [reason]..."
读取 CSV。根据问题类型选择 3-5 种方法。 默认组合:Question Storming + First Principles Thinking + Six Thinking Hats 说明选择理由(每种方法一行):“选择 [X],因为 [原因]……”

2b — Sequential Execution + Output

2b——顺序执行与输出

For each method, output results to conversation (visible text):
undefined
对于每种方法,将结果输出到对话中(可见文本):
undefined

[Method Name] — [category]

[方法名称]——[类别]

[4-6 insights or ideas generated by applying this method to the problem]

Output every selected method before calling advisor.
[通过将该方法应用于问题而生成的 4-6 个洞察或想法]

在调用 advisor 前,输出所有已选方法的结果。

2c — Independent Advisor Curation

2c——独立 advisor 评审

After outputting ALL method results, call
advisor()
. The advisor reads the full conversation including all method outputs. Do NOT phrase this as "passing context" — advisor auto-reads conversation.
If the call is unavailable or fails, follow the independent
advisor
subagent fallback in
references/advisor-brainstorm-protocol.md
. That protocol defines the persona, context, and required response. If neither route can provide an independent review, continue useful work that does not depend on curation, state what is missing, and do not present a final synthesis or claim the pitch is complete.
Expected advisor return: key insights, patterns, connections, candidates to discard.
输出全部方法结果后,调用
advisor()
。 advisor 会读取完整对话,包括所有方法输出。 不要将其表述为“传递上下文”——advisor 会自动读取对话。
如果该调用不可用或失败,请遵循
references/advisor-brainstorm-protocol.md
中独立的
advisor
子代理 fallback。该协议定义了 persona、上下文和必需响应。如果两条路径都无法提供独立评审,则继续进行不依赖评审的有用工作,说明缺少什么,并且不要给出最终综合结论或声称 pitch 已完成。
advisor 预期返回:关键洞察、模式、关联、应舍弃的候选项。

2d — Synthesis Presentation

2d——综合呈现

Present to user:
undefined
向用户呈现:
undefined

Brainstorm Synthesis — [N] methods explored

头脑风暴综合——已探索 [N] 种方法

Key Insights

关键洞察

  • [3-5 insights from advisor curation]
  • [来自 advisor 评审的 3-5 个洞察]

Patterns

模式

  • [pattern across methods]
  • [各方法之间共有的模式]

Ideas Worth Pursuing

值得推进的想法

  • [shortlisted ideas]
  • [候选想法]

Discarded (why)

已舍弃(原因)

  • [what got cut and why]

If a technical unknown could change the approach, investigate it in Phase 3 before converging. If the answer depends on information only the user can provide, ask for that information; otherwise use the available code or documentation sources. Carry unresolved questions forward with the evidence gathered.

---
  • [被舍弃的内容及其原因]
如果某个技术未知项可能改变方案方向,请在收敛前进入阶段 3进行调查。如果答案只能由用户提供,请向用户索取该信息;否则使用可用的代码或文档来源。带着已收集的证据继续追踪未决问题。

---

Phase 3: Spike (When Needed)

阶段 3:Spike(按需执行)

Goal: Resolve a technical unknown that could change which approach is worth pursuing.
→ Load
references/spike-protocol.md
for trigger criteria and execution
Triggered when Phase 2 surfaces: "can X do Y?", "does Z already exist?", "what does library W support?"
Agent chooses the available mode based on the unknown:
  • Code scan → architectural unknowns (what's in the codebase)
  • Web search → library/API capability unknowns
  • Both → when unknown spans external + internal
Investigate one unknown at a time and present the result before Phase 4. If a search does not answer it, use the next relevant source or mode in the spike protocol. At about five tool calls, reassess whether the current path is producing evidence and switch strategy if it is not. This is a strategy checkpoint, not a stop condition. If distinct approaches still leave the answer uncertain, state what you checked, what the evidence supports, and the exact open question; carry it into the pitch brief for pocket-grinding.

目标: 解决可能改变后续方案选择的技术未知项。
→ 加载
references/spike-protocol.md
以获取触发标准和执行方式
阶段 2 出现以下情况时触发:“X 能做 Y 吗?”、“Z 是否已经存在?”、“library W 支持什么?”
Agent 根据未知项选择可用模式:
  • 代码扫描 → 架构未知项(代码库中有什么)
  • Web 搜索 → library/API 能力未知项
  • 两者结合 → 未知项同时涉及外部与内部时
一次调查一个未知项,并在进入阶段 4 前呈现结果。如果搜索未能回答该问题,请按照 spike 协议使用下一个相关来源或调查模式。在大约五次工具调用时,重新评估当前路径是否正在产生证据;如果没有,则切换策略。这是策略检查点,而不是停止条件。 如果采用不同方法后仍无法确定答案,请说明检查了什么、证据支持什么,以及确切的未决问题;并将其带入 pocket-grinding 的 pitch brief。

Phase 4: Converge

阶段 4:收敛

Goal: Synthesize diverge + spike results into a clear problem statement.
Output to user:
undefined
目标: 将发散和 spike 结果综合成明确的问题陈述。
向用户输出:
undefined

Problem Synthesis

问题综合

Problem: [1-2 sentences — clear, actionable] Root tension: [the core tradeoff or challenge] Key constraints: [from context scan + brainstorm + spike if ran] Success looks like: [directional success signal — not GWT, just intent]

Adjust when the user adds nuance. If the user already supplied the framing, treat
that instruction as acceptance; ask only about a consequential choice the user has
not made.

---
问题:[1-2 句话——清晰、可操作] 根本张力:[核心权衡或挑战] 关键约束:[来自上下文扫描 + 头脑风暴 + spike(如已执行)] 成功应是什么样:[方向性的成功信号——不是 GWT,只是意图]
当用户补充细微差别时进行调整。如果用户已经提供了问题框定,将其指令视为已接受;仅询问用户尚未做出的重要选择。

---

Phase 5: Approach Directions

阶段 5:方案方向

Goal: Propose 2-3 solution directions. Keep them at the direction level; leave detailed architecture and scenarios to pocket-grinding.
Directions at this level: sync vs async, new module vs extension, library vs custom, etc. Leave architecture and scenario validation to pocket-grinding.
Format:
undefined
目标: 提出 2-3 个方案方向。保持在方向层面;将详细架构和场景留给 pocket-grinding。
这一层面的方向包括:sync vs async、new module vs extension、library vs custom 等。 将架构和场景验证留给 pocket-grinding。
格式:
undefined

Approach Directions

方案方向

Direction A: [name] [1-2 sentences]
  • [main advantage] − [main risk or tradeoff]
Direction B: [name] [1-2 sentences]
  • [main advantage] − [main risk or tradeoff]
Direction C: [name] (only if genuinely distinct from A and B) [1-2 sentences]
  • [main advantage] − [main risk or tradeoff]
Recommended: Direction [X] — [1-sentence reasoning based on constraints + insights]

---
方向 A:[名称] [1-2 句话]
  • [主要优势] − [主要风险或权衡]
方向 B:[名称] [1-2 句话]
  • [主要优势] − [主要风险或权衡]
方向 C:[名称](仅当其与 A 和 B 确实存在明显差异时提供) [1-2 句话]
  • [主要优势] − [主要风险或权衡]
推荐:方向 [X]——[基于约束 + 洞察的一句话理由]

---

Phase 6: Brief + Handoff

阶段 6:Brief 与交接

Goal: Write the pitch exploration doc and continue according to the user's stated intent.
→ Load
references/brief-template.md
for full document format
Save to:
docs/pocket/spec/YYYY-MM-DD-kebab-slug/pitch-exploration.md
If the user has not already said what to do next, present these choices in natural language:
Pitch doc written to: docs/pocket/spec/[path]

What would you like to do next?
  1. Invoke pocket-grinding now (starts from this pitch)
  2. Iterate on [specific phase] before proceeding
  3. Save and stop here — I'll come back to this later
If the user asks to proceed to specification or otherwise clearly authorizes the handoff, invoke
pocket-grinding
and pass the pitch doc path, problem statement, recommended direction, and unresolved questions. If the user asks to revise, return to the named phase and update the brief. If the user asks to stop, confirm the saved path. Do not require the user to reply with an option number.

目标: 编写 pitch 探索文档,并根据用户已表明的意图继续执行。
→ 加载
references/brief-template.md
以获取完整文档格式
保存到:
docs/pocket/spec/YYYY-MM-DD-kebab-slug/pitch-exploration.md
如果用户尚未说明下一步操作,请用自然语言呈现以下选项:
Pitch 文档已写入:docs/pocket/spec/[路径]

接下来想做什么?
  1. 立即调用 pocket-grinding(从此 pitch 开始)
  2. 在继续之前迭代 [具体阶段]
  3. 保存并在此停止——我稍后会回来继续
如果用户要求继续编写 spec,或以其他方式明确授权交接,请调用
pocket-grinding
,并传递 pitch 文档路径、问题陈述、推荐方向和未决问题。如果用户要求修改,请返回指定阶段并更新 brief。如果用户要求停止,请确认已保存的路径。不要求用户回复选项编号。

Reference Triggers

参考资料触发条件

ReferenceWhen to Load
references/brainstorming-methods.csv
Phase 2a: read to select methods
references/method-selection.md
Phase 2a: selection criteria + default trio
references/advisor-brainstorm-protocol.md
Phase 2c: LLM-to-LLM curation mechanics
references/spike-protocol.md
Phase 3: trigger criteria + execution modes
references/brief-template.md
Phase 6: pitch doc format
参考资料何时加载
references/brainstorming-methods.csv
阶段 2a:读取以选择方法
references/method-selection.md
阶段 2a:选择标准和默认组合
references/advisor-brainstorm-protocol.md
阶段 2c:LLM-to-LLM 评审机制
references/spike-protocol.md
阶段 3:触发标准和执行模式
references/brief-template.md
阶段 6:pitch 文档格式