$ loading_
通过层层追问与假设检验，帮助澄清需求、计划与设计中的关键不确定性。
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "deep-clarification" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/devsquad-copilot/main/.github/plugins/devsquad/skills/deep-clarification/SKILL.md 2. 保存为 ~/.claude/skills/deep-clarification/SKILL.md 3. 装好后重载技能，告诉我可以用了
请对这个功能需求做深度澄清：我们要做一个团队任务看板。请不要直接给方案，而是先像资深产品经理一样连续追问关键问题，逐层拆解目标用户、使用场景、边界条件、权限、异常情况、成功指标和潜在冲突，直到主要歧义被暴露出来。
一组结构化澄清问题与风险点，帮助补全需求定义并识别关键未知项。
挑战这个项目计划：我们计划两周内上线新版注册流程。请从依赖、资源、验收标准、测试覆盖、回滚方案、数据埋点、跨团队协作和时间假设等方面逐项质疑，并把每个潜在失败分支都展开说明。
对计划的系统性质疑清单、失败路径分析，以及需要补强的前置条件。
帮我深挖这个线上问题：用户反馈支付成功但订单状态未更新。请不要直接下结论，而是通过连续澄清问题梳理可能链路，挑战现有假设，区分已知、未知和待验证信息，并尽可能穷举关键分支。
一份面向排障的澄清框架，列出调查方向、关键分支与待验证假设。
Premature convergence is the root cause of underspecified features. When uncertainty is high, exhaustive exploration of the decision space produces better artifacts than bounded clarification rounds.
| Caller | Trigger |
|---|---|
devsquad.specify | Spec touches multiple bounded contexts, has high complexity rating, or user requests deep exploration |
devsquad.plan | High-impact design decisions with 2+ viable options and no clear winner |
devsquad.envision | Business context has competing objectives or unclear pain points |
debugging-recovery | Bug report is incomplete or ambiguous; need to build a complete reproduction |
| Any agent | User explicitly says "challenge this", "stress-test this", or "deep dive on requirements" |
Before asking the first question, map the branches:
For each decision point:
Before asking the user a question, check if the answer is already in the codebase:
Can the codebase answer this question?
YES → State the finding: "I found that [X]. Is this still current?"
NO → Ask the user
This reduces unnecessary questions and grounds the conversation in reality.
The clarification session ends when ANY of the following are true:
As decisions are made during the session, capture them immediately:
domain-glossary skill if available)Present a summary at the end using the reasoning skill format:
## Clarification Summary
### Decisions Made
| # | Decision | Justification | Confidence |
|---|----------|---------------|------------|
| 1 | [what was decided] | [why] | [High/Medium/Low] |
### Assumptions
- [assumption made during the session]
### Open Items
- [anything that could not be resolved and needs follow-up]
### Suggested Next Steps
- [ADR needed for X]
- [Spec update needed for Y]
Use these patterns to probe deeper:
| Technique | When to use | Example |
|---|---|---|
| Concrete scenario | Vague requirement | "Give me a specific example of when this would happen" |
| Edge case probe | Happy path only discussed | "What happens if [unusual input]? What about [concurrent access]?" |
| Contradiction surfacing | User states conflict with code/docs | "Your code does X, but you just said Y. Which is correct?" |
| Terminology sharpening | Overloaded or vague terms | "You said 'account'. Do you mean the billing entity or the login identity?" |
…
帮助你创建、切换并检查代码分支，确保实现前遵循正确分支策略。
沉淀并查询代码库经验教训，帮助开发、验证与评审减少重复踩坑。