> 融合 GSD discuss-phase 与 gstack office-hours 的预编码设计讨论技能。 在 /team-intake 之后、/team-plan 之前,通过苏格拉底式质疑捕获灰色地带、 用户偏好和关键假设,产出 CONTEXT.md 供后续规划和实现消费。
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill discuss-phase --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Discuss Phase?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-discuss-phase)More formats (shields.io, HTML) on the badges page.
---
name: discuss-phase
description: "> 融合 GSD discuss-phase 与 gstack office-hours 的预编码设计讨论技能。 在 /team-intake 之后、/team-plan 之前,通过苏格拉底式质疑捕获灰色地带、 用户偏好和关键假设,产出 CONTEXT.md 供后续规划和实现消费。"
category: general-purpose
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/Colin4k1024/tsp/skills/discuss-phase/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/Colin4k1024/tsp/skills/discuss-phase/SKILL.md
---
# Discuss Phase
## 用途
- 把"需求文字看起来清楚了就开干"改成"先把灰色地带和隐含假设摊开讨论"。
- 适合需求有模糊空间、存在多种可行路线、或用户偏好尚未表达的场景。
- 在 `/team-intake` 完成后、`/team-plan` 之前推荐触发。
## 两种模式
### discuss(交互质疑模式)
逐项质疑需求中的灰色地带,引导用户做出偏好选择。适用于用户在场、可以即时回答的场景。
### assumptions(代码分析优先模式)
先扫描代码库识别现有模式和约束,把代码中已有的事实作为假设基础,仅对代码无法回答的灰色地带提问。适用于代码库已有大量存量逻辑的迭代场景。
## 默认做法
1. **收集输入**:读取 `/team-intake` 的产出(PRD、需求简报),提取目标、范围、约束和待确认项。
2. **识别灰色地带**:按以下维度自动扫描未锁定的决策点:
- **UI 交互**:状态管理方式、加载/空/错误态策略、动效取舍
- **API/数据**:分页策略、错误码规范、缓存策略、数据保留周期
- **架构**:同步/异步、推/拉、单体/微服务边界
- **业务规则**:边界条件处理、权限粒度、审批流程节点
- **质量**:性能预算、浏览器兼容基线、可访问性等级
- **部署**:环境策略、Feature Flag、灰度比例
3. **Forcing Questions**(来自 gstack office-hours 方法论):
- 如果这个功能只能做一件事,那件事是什么?
- 这个功能的用户是谁?他们当前的替代方案是什么?
- 半年后回看,什么情况下我们会认为这是浪费时间?
- 最小可交付版本是什么?跟完整版的差距在哪?
- 有哪些假设一旦不成立,方案就会完全不同?
- 哪个决策如果做错了代价最大?
4. **逐项讨论**:每个灰色地带呈现为:
- 背景:为什么这是一个需要讨论的点
- 选项:可行方案列表,每个带利弊分析
- 推荐:基于代码分析和最佳实践的建议
- 等待用户确认或修改
5. **产出 CONTEXT.md**:将所有讨论结论写入 `docs/artifacts/{slug}/context.md`,包含:
- 确认的技术偏好和约束
- 灰色地带的最终决策
- 待进一步验证的假设(标记为 `[ASSUMPTION]`)
- 明确排除的选项及排除原因
## 触发信号
- `/team-intake` 产出中包含 3 个以上待确认项。
- 需求涉及新领域或新技术栈,团队缺乏先验经验。
- 存在多个合理的技术路线,无法在 intake 阶段直接锁定。
- 需求涉及跨团队或跨系统边界。
- 用户显式要求"先讨论一下再开始"。
## 配套约束
1. **不替代 intake**:discuss-phase 消费 intake 的输出,不重新做需求收集。
2. **不替代 plan**:discuss-phase 产出偏好和约束,不产出任务拆解和排期。
3. **时间控制**:单次 discuss 控制在 6-10 个灰色地带以内,超出时建议分批或升级给 `architect`。
4. **结论必须落盘**:所有讨论结论写入 `context.md`,不停留在对话上下文中。
5. **assumptions 模式红线**:代码分析得出的假设必须标注证据来源(文件路径 + 行号),不能凭直觉编造。
---
**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/Colin4k1024/tsp/skills/discuss-phase/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!