kata-discuss-phase
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<objective>
Extract implementation decisions that downstream agents need — researcher and planner will use CONTEXT.md to know what to investigate and what choices are locked.
How it works:
- Analyze the phase to identify gray areas (UI, UX, behavior, etc.)
- Present gray areas — user selects which to discuss
- Deep-dive each selected area until satisfied
- Create CONTEXT.md with decisions that guide research and planning
Output: — decisions clear enough that downstream agents can act without asking the user again
</objective>
{phase}-CONTEXT.md<execution_context>
@./references/phase-discuss.md
@./references/context-template.md
</execution_context>
<context>
Phase number: $ARGUMENTS (required)
Load project state:
@.planning/STATE.md
Load roadmap:
@.planning/ROADMAP.md
</context>
<process>
1. Validate phase number (error if missing or not in roadmap)
2. Check if CONTEXT.md exists (offer update/view/skip if yes)
3. **Analyze phase** — Identify domain and generate phase-specific gray areas
4. **Present gray areas** — Multi-select: which to discuss? (NO skip option)
5. **Deep-dive each area** — 4 questions per area, then offer more/next
6. **Write CONTEXT.md** — Sections match areas discussed
7. Offer next steps (research or plan)
CRITICAL: Scope guardrail
- Phase boundary from ROADMAP.md is FIXED
- Discussion clarifies HOW to implement, not WHETHER to add more
- If user suggests new capabilities: "That's its own phase. I'll note it for later."
- Capture deferred ideas — don't lose them, don't act on them
Domain-aware gray areas:
Gray areas depend on what's being built. Analyze the phase goal:
- Something users SEE → layout, density, interactions, states
- Something users CALL → responses, errors, auth, versioning
- Something users RUN → output format, flags, modes, error handling
- Something users READ → structure, tone, depth, flow
- Something being ORGANIZED → criteria, grouping, naming, exceptions
Generate 3-4 phase-specific gray areas, not generic categories.
Probing depth:
- Ask 4 questions per area before checking
- "More questions about [area], or move to next?"
- If more → ask 4 more, check again
- After all areas → "Ready to create context?"
Do NOT ask about (Claude handles these):
- Technical implementation
- Architecture choices
- Performance concerns
- Scope expansion </process>
<success_criteria>
- Gray areas identified through intelligent analysis
- User chose which areas to discuss
- Each selected area explored until satisfied
- Scope creep redirected to deferred ideas
- CONTEXT.md captures decisions, not vague vision
- User knows next steps </success_criteria>
<objective>
提取下游Agent所需的实施决策——研究员和规划师将使用CONTEXT.md来了解需要调研的内容以及已确定的选择。
工作原理：
- 分析阶段以识别模糊点（UI、UX、行为等）
- 呈现模糊点——用户选择要讨论的内容
- 深入探讨每个选定领域直到满意
- 创建CONTEXT.md，记录指导研究和规划的决策
输出： —— 决策需足够清晰，确保下游Agent无需再次询问用户即可开展工作
</objective>
{phase}-CONTEXT.md<execution_context>
@./references/phase-discuss.md
@./references/context-template.md
</execution_context>
<context>
阶段编号：$ARGUMENTS（必填）
加载项目状态：
@.planning/STATE.md
加载路线图：
@.planning/ROADMAP.md
</context>
<process>
1. 验证阶段编号（若缺失或不在路线图中则报错）
2. 检查CONTEXT.md是否存在（若存在则提供更新/查看/跳过选项）
3. **分析阶段**——识别领域并生成阶段特定的模糊点
4. **呈现模糊点**——多选：要讨论哪些内容？（无跳过选项）
5. **深入探讨每个领域**——每个领域提出4个问题，然后提供更多/下一个选项
6. **编写CONTEXT.md**——章节与讨论的领域匹配
7. 提供后续步骤（研究或规划）
关键：范围护栏
- 来自ROADMAP.md的阶段边界是固定的
- 讨论明确的是如何实施，而非是否添加更多内容
- 若用户提出新功能：“这属于独立阶段，我会稍后记录。”
- 记录延迟的想法——不要丢失，但不要立即实施
领域感知模糊点：
模糊点取决于正在构建的内容。分析阶段目标：
- 用户可见的内容 → 布局、密度、交互、状态
- 用户调用的内容 → 响应、错误、认证、版本控制
- 用户运行的内容 → 输出格式、标志、模式、错误处理
- 用户阅读的内容 → 结构、语气、深度、流程
- 正在被整理的内容 → 标准、分组、命名、例外情况
生成3-4个阶段特定的模糊点，而非通用类别。
探索深度：
- 每个领域先提出4个问题再确认
- “关于[领域]是否需要更多问题，还是进入下一个？”
- 若需要更多 → 再提出4个问题，再次确认
- 所有领域完成后 → “是否准备好创建上下文？”
请勿询问以下内容（由Claude处理）：
- 技术实现
- 架构选择
- 性能问题
- 范围扩展 </process>
<success_criteria>
- 通过智能分析识别模糊点
- 用户选择了要讨论的领域
- 每个选定领域都探讨至用户满意
- 范围蔓延被引导至延迟想法
- CONTEXT.md记录的是决策，而非模糊愿景
- 用户了解后续步骤 </success_criteria>