discover

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Discover

Meta — Conversational. Transform vague ideas into shared clarity through adaptive conversation.

Core Philosophy: "Just talk with your agent."

The gap between stated requirements and true needs is where most failed projects begin. This skill closes that gap through conversation — not documents, not formal phases, not plan mode.

Core Question: "What would we silently get wrong if we just started building?"

元能力 —— 对话式。通过自适应对话将模糊想法转化为共识性明确需求。

核心理念：「直接与你的Agent对话即可。」

已陈述需求与真实需求之间的差距，是大多数项目失败的根源。本技能通过对话而非文档、正式阶段或规划模式来弥合这一差距。

核心问题：「如果我们直接启动开发，会在哪些方面不知不觉地出错？」

How It Works

工作流程

You describe what you want
The agent scans context and assesses complexity (silently)
Questions begin — adaptive to what's needed
Conversation continues until mutual clarity
Build directly, or save a spec/contract if needed

No plan mode. No pipeline stages. No mandatory artifacts. The conversation IS the alignment.

你描述需求
Agent扫描上下文并评估复杂度（静默执行）
开始提问 —— 根据需求自适应调整
持续对话直至双方达成共识
直接启动开发，或按需保存规格文档/合约

无需规划模式，无需流水线阶段，无需强制产出物。对话本身就是对齐过程。

Adaptive Depth

自适应深度

The skill auto-calibrates based on signals it reads from the request:

Signal	Depth	Behavior
Clear task, existing codebase, well-defined scope	Light (3-5 questions)	Surface assumptions, lock scope, go
Feature with some ambiguity, multiple approaches	Medium (5-10 questions)	Explore key decisions, probe edge cases
Vague idea, greenfield, "I want to build X"	Deep (multi-round)	Challenge premise, interview across zones, iterate

You don't choose the depth. The agent reads the situation. If you want to skip ahead — "that's enough, let's build" — the agent respects it and notes current clarity level.

Override: "quick scope", "deep interview", "just ask 3 questions" — overrides the auto-calibration.

本技能会根据从请求中读取的信号自动调整深度：

信号	深度	行为
任务清晰、已有代码库、范围明确	轻量（3-5个问题）	梳理隐含假设、锁定范围、启动开发
功能存在一定歧义、有多种实现方案	中等（5-10个问题）	探索关键决策、排查边缘场景
想法模糊、全新项目、「我想做X」	深度（多轮对话）	挑战前提、全方位访谈、迭代细化

无需你手动选择深度，Agent会自动判断场景。如果你想跳过后续步骤 ——「足够了，开始开发吧」—— Agent会尊重你的选择，并记录当前的共识程度。

强制覆盖： 使用「quick scope」「deep interview」「just ask 3 questions」可覆盖自动校准逻辑。

Execution

执行步骤

Step 1: Context Gathering (silent, before asking anything)

步骤1：上下文收集（静默执行，在提问前完成）

Scan for answers that already exist. Don't spend more than a few minutes here — this narrows questions, not a research step.

Codebase:
```
package.json
```
, schemas, entry points, existing implementations relevant to the request (use Glob, Grep, Read — not a separate agent)
Artifacts: Check
```
.agents/
```
for existing specs, architecture docs, product context
Experience docs: Check
```
.agents/experience/{domain}.md
```
for answers from prior sessions
Learned rules: Read
```
.agents/meta/learned-rules.md
```
for behavior corrections
Out-of-scope decisions: Check
```
.agents/meta/out-of-scope/
```
for features or approaches already rejected in prior sessions — don't re-ask about these unless the user brings them up
Project conventions: Skim
```
CLAUDE.md
```
for patterns

Anything found here is a question you don't need to ask.

扫描已存在的答案。此步骤耗时不超过几分钟 —— 目的是缩小提问范围，而非深入研究。

代码库：
```
package.json
```
、 schema、入口文件、与请求相关的现有实现（使用Glob、Grep、Read —— 无需调用其他Agent）
产出物：检查
```
.agents/
```
目录下的现有规格文档、架构文档、产品上下文
经验文档：检查
```
.agents/experience/{domain}.md
```
获取往期会话的答案
已学习规则：读取
```
.agents/meta/learned-rules.md
```
获取行为修正规则
已排除范围的决策：检查
```
.agents/meta/out-of-scope/
```
获取往期已否决的功能或方案 —— 除非用户主动提及，否则不要重复询问
项目约定：浏览
```
CLAUDE.md
```
了解模式规范

在此步骤中找到的信息，无需再提问确认。

Step 2: Premise Check (for non-trivial work)

步骤2：前提校验（针对非 trivial 任务）

Before diving into details, challenge the premise with 3 quick questions:

Right problem? Restate the actual outcome in one sentence. Is the proposed approach the most direct path? Watch for solution-framing vs problem-framing: "We need notifications" (solution) vs "Users miss time-sensitive events" (problem).
What if we did nothing? Is there real, measurable pain today? If nobody is complaining, probe why this surfaced now.
What already exists? Map the request against existing code and tooling. If 60% of the solution exists, the scope is 40% of what was described.

If the premise is weak, say so. Suggest reframing if applicable. But don't block — advise and let the user decide.

Framing checkpoint — after receiving the user's first substantive answer, pause and verify before continuing:

Language precision: Are key terms defined concretely, or hiding behind buzzwords ("AI-powered", "seamless", "platform")?
Real vs hypothetical: Is the user describing what IS happening or what MIGHT happen? Past behavior beats future predictions.
Hidden assumptions: What is the user taking for granted that could be wrong? State it back to them.

If framing is vague, fix it before proceeding. An entire session built on imprecise framing produces precise-looking nonsense.

Skip the premise check when: the task is clearly scoped ("add a dark mode toggle"), the user is continuing from a previous decision, or context makes it obvious the premise is sound.

在深入细节前，用3个快速问题挑战需求前提：

问题是否正确？ 用一句话重述实际目标。当前提出的方案是否是最直接的路径？注意区分解决方案导向和问题导向：「我们需要通知功能」（解决方案） vs 「用户会错过时间敏感事件」（问题）。
如果不做会怎样？ 当前是否存在真实、可衡量的痛点？如果没有人抱怨，探究为什么现在要解决这个问题。
已有哪些相关资源？ 将请求与现有代码和工具进行匹配。如果60%的解决方案已存在，那么实际范围仅为描述内容的40%。

如果前提站不住脚，直接指出。如有必要，建议重新梳理需求框架。但不要阻碍流程 —— 仅提供建议，最终由用户决定。

框架校验点 —— 在收到用户的第一个实质性回答后，暂停并验证：

语言精准度：关键术语是否有具体定义，还是被流行词掩盖（如「AI-powered」「seamless」「platform」）？
真实 vs 假设：用户描述的是当前已发生的情况，还是未来可能发生的情况？过往行为比未来预测更可靠。
隐含假设：用户默认认为正确但实际可能错误的内容是什么？向用户重述这些假设。

如果框架模糊，先修正再继续。基于模糊框架的会话，只会产出看似精准的无意义内容。

跳过前提校验的场景：任务范围明确（如「添加深色模式切换按钮」）、用户延续之前的决策、上下文已明确证明前提合理。

Step 3: Adaptive Coverage Zones

步骤3：自适应覆盖领域

Instead of 5 fixed dimensions, identify 3-5 coverage zones that matter for THIS specific problem.

For a product feature:

Problem validation → Solution clarity → Technical risks → Success criteria

For a business strategy:

Problem clarity → Options landscape → Tradeoffs → Validation path

For a marketing initiative:

Audience fit → Channel strategy → Messaging → Measurement

For infrastructure/devops:

Requirements → Constraints → Failure modes → Rollout plan

For a design task:

User needs → Information architecture → Interaction patterns → Edge states

State the zones at the start: "Here's what I think we need clarity on: [zones]. Anything you'd add or remove?" The user can adjust.

Zones are a compass, not a checklist. Some problems only need 2 zones explored deeply. Others need 5 touched lightly. Let the conversation guide it.

无需固定的5个维度，针对当前特定问题确定3-5个需要明确的核心领域。

针对产品功能：

问题验证 → 方案清晰度 → 技术风险 → 成功标准

针对业务策略：

问题清晰度 → 可选方案全景 → 权衡取舍 → 验证路径

针对营销活动：

受众适配 → 渠道策略 → 信息传递 → 效果衡量

针对基础设施/DevOps：

需求 → 约束条件 → 故障模式 → 上线计划

针对设计任务：

用户需求 → 信息架构 → 交互模式 → 边缘状态

在会话开始时说明核心领域：「我认为我们需要明确以下几个方面：[领域列表]。你有补充或删减的吗？」用户可进行调整。

核心领域是指引方向的罗盘，而非必须完成的清单。有些问题只需深入探索2个领域，有些则需浅触5个领域。让对话自然引导流程。

Communication Discipline

沟通准则

During diagnostic questioning:

No affirmation before probing — never say "Great!", "That makes sense!", "Solid approach" before asking the next question
State disagreements directly: "That approach has a problem: [X]" not "That's interesting, though..."
When the user's answer reveals a weak premise, say so before moving on
Praise only completed outcomes, never stated intentions
If you agree, just proceed — agreement doesn't need to be performed

Pushback patterns — when you hear these, push back with the rigorous version:

Vague market:

BAD: "That's a big market! Let's explore what kind of tool."
GOOD: "There are thousands of tools in that space. What specific task does a specific person waste 2+ hours on per week that yours eliminates? Name the person."

Social proof as substitute for evidence:

BAD: "That's great validation! Let's build on that momentum."
GOOD: "Likes and signups are interest, not demand. How many people have paid you money or done real work to solve this problem without your product?"

Platform vision before wedge:

BAD: "That's ambitious! Let's map out the phases."
GOOD: "Platforms are built from wedges, not designed top-down. What is the single smallest thing you could ship that one specific person would pay for today?"

Undefined terms:

BAD: "AI-powered is definitely trending. Let's think about the AI features."
GOOD: "What specifically does 'AI-powered' mean in your product? What input goes in, what output comes out, and why can't the user do it themselves in 5 minutes?"

Growth stats without unit economics:

BAD: "200% growth is impressive! How do you plan to scale?"
GOOD: "200% growth of what base? What does each user cost to acquire, and what do they pay you? Growth without unit economics is just spending."

The best reward for a good answer is a harder follow-up, not praise.

在诊断性提问过程中：

在深入提问前不要肯定 —— 不要在问下一个问题前说「很棒！」「有道理！」「方案很扎实」
直接表达不同意见：「这个方案存在问题：[X]」而非「这很有意思，不过...」
当用户的回答显示前提薄弱时，在继续前直接指出
仅对已完成的结果给予赞扬，而非陈述的意图
如果同意，直接继续 —— 无需刻意表达认同

反驳模式 —— 当听到以下表述时，用更严谨的方式反驳：

模糊的市场描述：

错误：「这是个大市场！我们来探索做什么工具。」
正确：「该领域已有数千款工具。具体哪类人群每周会在某项任务上浪费2小时以上，而你的工具能解决这个问题？请明确人群。」

用社交证明替代证据：

错误：「这是很好的验证！我们借此势头推进。」
正确：「点赞和注册只是兴趣，并非需求。有多少人已经为解决这个问题付费，或在没有你的产品时付出了实际努力？」

先谈平台愿景再谈切入点：

错误：「这很有野心！我们来规划阶段。」
正确：「平台是从切入点逐步构建的，而非自上而下设计的。你现在能交付的最小功能是什么，能让特定人群愿意付费？」

未定义的术语：

错误：「AI-powered确实是趋势。我们来思考AI功能。」
正确：「在你的产品中，'AI-powered'具体指什么？输入是什么，输出是什么，为什么用户自己无法在5分钟内完成？」

无单位经济的增长数据：

错误：「200%的增长令人印象深刻！你计划如何规模化？」
正确：「200%增长的基数是什么？获取每个用户的成本是多少，他们向你支付多少？没有单位经济的增长只是烧钱。」

对好答案的最佳奖励是更深入的后续问题，而非赞扬。

Step 4: Conversation

步骤4：对话环节

Use proven interview techniques naturally. Don't announce the technique — just ask.

Why Chains — "Why this approach specifically?" → drill past surface answers. "We need real-time updates." → "Why real-time?" → "Users check every few minutes." → "So 30s polling works?" → "Actually, yes."

Past Behavior Probes — "What are you/users doing today to solve this?" Past behavior reveals actual needs; future descriptions reveal aspirations.

Daily Use Visualization — "Walk me through a typical day where you'd use this. What triggers you to open it?"

Forced Tradeoffs — "If you could only keep 2 of these 4 features, which 2?" Forced choices reveal true priorities.

Failed Attempt Archaeology — "Have you tried this before? Used a tool for this? What was wrong with it?"

Success Criteria Grounding — "If this ships and works perfectly, what's the first thing you'd notice is different?"

Should-Want Detection — Watch for:

Overly formal or buzzword-heavy language
Features described from elsewhere without connecting to specific pain
Quick, confident answers to complex questions (real complexity produces hesitation)
Answers that don't connect to any user story or past experience

When detected, switch to probing actual needs before continuing.

Question Delivery:

You have two tools for asking questions — use whichever fits the moment:

AskUserQuestion
tool — presents clickable options with descriptions. Best when you can offer 2-4 concrete choices with real tradeoffs. Reduces friction: the user clicks instead of typing. Mark your recommended option clearly (e.g., "(Recommended)" suffix). Use

preview

for comparing code or architecture. Use

multiSelect: true

for non-exclusive choices. The user always has "Other" for free-text input.

Chat questions — plain conversational questions. Best when the answer space is wide open or you're following a thread deeper (why chains, past behavior, premise challenges).

Most sessions will mix both naturally. A scoping question with known options → AskUserQuestion. A follow-up probing why they chose that → chat. Don't overthink the choice — if you can offer concrete options, use the tool; if you're exploring, just ask.

Pacing:

2-4 questions per round
Each question targets 2-4 decision points with real tradeoffs
State which choice you recommend and why
Group related questions together — batch up to 4 into a single AskUserQuestion call when they're independent
After each round, briefly acknowledge answers and track clarity internally

Question formats (use whichever fits the question):

Assumption-surfacing format (best for scoping — makes silent assumptions visible):

Q1 (highest impact): Should this be a REST API or GraphQL?
My default assumption: REST, since the existing codebase uses Express.
Why it matters: GraphQL would require adding apollo-server and
restructuring the resolver layer — completely different implementation path.

This maps naturally to AskUserQuestion with 2 options: "REST (Recommended)" and the alternative, with the rationale in descriptions. But chat works fine too — use your judgment.

Options format (best for design decisions with clear tradeoffs):

Question: "When a background sync fails, how should we handle it?"
Options:
1. Silent retry (3x with backoff) — User unaware, but may see stale data
2. Toast notification — User informed but may be annoyed
3. Badge indicator — Subtle, user can investigate when ready
Recommended: Option 1 — most sync failures are transient

This is a natural fit for AskUserQuestion — the options become clickable choices with tradeoff descriptions.

At light depth (scoping), prefer the assumption-surfacing format — it's the key innovation that prevents silent assumption failures. At deeper depths, mix both formats based on what the question needs.

自然运用成熟的访谈技巧。无需宣布使用的技巧 —— 直接提问即可。

追问链 ——「为什么选择这个方案？」→ 挖掘表面答案背后的原因。「我们需要实时更新。」→「为什么需要实时？」→「用户每隔几分钟就会查看。」→「那30秒轮询就足够了？」→「实际上，是的。」

过往行为探查 ——「你/用户现在是如何解决这个问题的？」过往行为反映真实需求；未来描述反映期望。

日常使用场景可视化 ——「带我走一遍使用这个功能的典型一天。什么触发你打开它？」

强制权衡 ——「如果只能保留这4个功能中的2个，你会选哪2个？」强制选择能揭示真正的优先级。

失败尝试溯源 ——「你之前试过这个吗？用过相关工具吗？问题出在哪里？」

成功标准落地 ——「如果这个功能上线并完美运行，你首先会注意到什么变化？」

应需 vs 实需检测 —— 留意以下情况：

过于正式或充满流行词的表述
描述的功能来自其他场景，未与具体痛点关联
对复杂问题给出快速、自信的答案（真正的复杂性会带来犹豫）
回答未关联任何用户故事或过往经验

当检测到上述情况时，先探查真实需求再继续。

提问方式：

你有两种提问工具 —— 根据场景选择：

AskUserQuestion
工具 —— 展示带描述的可点击选项。适用于可提供2-4个带真实权衡的具体选项的场景。减少用户操作成本：用户只需点击而非输入。明确标记推荐选项（如添加「(Recommended)」后缀）。使用

preview

对比代码或架构。使用

multiSelect: true

支持非排他选择。用户始终可选择「Other」进行自由文本输入。

聊天式提问 —— 普通对话式问题。适用于答案范围开放或需要深入挖掘的场景（追问链、过往行为探查、前提挑战）。

大多数会话会自然混合使用两种方式。范围界定问题且有明确选项 → 使用AskUserQuestion。后续探查用户选择原因 → 聊天式提问。无需过度纠结选择 —— 如果能提供具体选项，就用工具；如果是探索性问题，直接提问即可。

节奏控制：

每轮2-4个问题
每个问题针对2-4个带真实权衡的决策点
说明你推荐的选项及原因
将相关问题分组 —— 当问题相互独立时，可在一次AskUserQuestion调用中批量提出最多4个问题
每轮后简要确认答案，并在内部跟踪共识程度

提问格式（根据问题选择合适的格式）：

假设梳理格式（最适合范围界定 —— 让隐含假设显性化）：

Q1（最高影响）：应该用REST API还是GraphQL？
我的默认假设：REST，因为现有代码库使用Express。
重要性：GraphQL需要添加apollo-server并重构解析器层 —— 实现路径完全不同。

这种格式自然适配AskUserQuestion，提供2个选项：「REST (Recommended)」和另一种方案，并在描述中说明理由。当然用聊天式提问也可以 —— 自行判断。

选项格式（最适合有明确权衡的设计决策）：

问题：「后台同步失败时，我们应该如何处理？」
选项：
1. 静默重试（退避重试3次）—— 用户不知情，但可能看到过时数据
2. 弹窗通知 —— 用户知晓，但可能被打扰
3. 徽章提示 —— 低调，用户可随时查看
推荐：选项1 —— 大多数同步失败是暂时的

这种格式非常适合AskUserQuestion —— 选项会变成带权衡描述的可点击选择。

在轻量深度（范围界定）场景下，优先使用假设梳理格式 —— 这是避免隐含假设失误的关键创新。在深度场景下，根据问题需求混合使用两种格式。

Step 5: Complex Decision Points → Agent Room

步骤5：复杂决策点 → Agent Room

When you hit a genuinely complex decision where your single perspective isn't enough — architecture choice, strategic direction, design tradeoff with no clear winner — invoke the

agent-room

skill as a sub-routine.

When to invoke:

Two+ viable approaches with non-obvious tradeoffs
The decision will be expensive to reverse
You feel uncertain and want to pressure-test your thinking

How to invoke: Frame the specific decision for the agent-room: "Should we use WebSocket push or polling for this use case?" Include the context gathered so far. The agent-room debates, returns a recommendation, and you continue the conversation.

When NOT to invoke:

The decision has a clear best answer from the context
The user has already expressed a strong preference
The choice is easily reversible

当遇到真正复杂的决策，单视角不足以判断时 —— 架构选择、战略方向、无明确最优解的设计权衡 —— 调用

agent-room

技能作为子流程。

调用时机：

有两种及以上可行方案，且权衡不明显
决策失误的成本很高
你感到不确定，想测试自己的思路

调用方式： 为agent-room明确决策点：「我们应该用WebSocket推送还是轮询来处理这个场景？」并附上已收集的上下文。agent-room会进行辩论，返回推荐方案，你再继续对话。

不调用的场景：

根据上下文有明确的最优答案
用户已明确表达偏好
选择可轻松逆转

Step 6: Clarity Check

步骤6：共识校验

When the conversation has reached enough clarity to build:

Summarize key decisions made
Note any remaining open questions and their impact
Ask: "Ready to build, or want to go deeper on anything?"

If the user says go, go. Don't pad with more questions.

当对话达到足够共识可启动开发时：

总结已做出的关键决策
记录任何未解决的问题及其影响
询问：「准备好启动开发，还是需要进一步深入探讨？」

如果用户同意启动，直接开始。不要额外增加问题。

Step 7: Output

步骤7：输出

Default: conversation context. Decisions live in the conversation. The next skill (system-architecture, task-breakdown, or direct implementation) can read everything that was discussed.

Optional save points — produce these when:

The user explicitly asks ("save this to a spec")
The session is ending and decisions would be lost
The output is needed by someone outside this conversation
A natural milestone is reached and the user confirms saving

Save point formats:

Spec (for complex features, handoff to others):

markdown

---
skill: discover
version: 1
date: {{today}}
status: draft
---

默认：对话上下文。 决策存储在对话中。后续技能（system-architecture、task-breakdown或直接实现）可读取所有讨论内容。

可选保存节点 —— 在以下场景产出：

用户明确要求（如「保存为规格文档」）
会话结束，决策可能丢失
输出需要分享给对话外的人员
达到自然里程碑且用户确认保存

保存节点格式：

规格文档（针对复杂功能、移交他人）：

markdown

---
skill: discover
version: 1
date: {{today}}
status: draft
---

[Feature Name] Specification

[功能名称] 规格文档

Problem Statement

问题陈述

[What we're solving and why]

[我们要解决的问题及原因]

Decided Approach

确定的方案

[High-level approach with key decisions]

[包含关键决策的高层方案]

Key Decisions

关键决策

Decision	Choice	Rationale
[Topic]	[What]	[Why]

决策主题	选择	理由
[主题]	[选择]	[理由]

Edge Cases

边缘场景

[Scenario]: [How we handle it]

[场景]: [处理方式]

Failure Conditions

失败条件

Any of these = not done:

[Specific condition that would make this feature "technically working" but wrong]
[Edge case that must be handled — not a nice-to-have]
[Quality bar that must be met — e.g., "latency under 200ms", "works offline"]

满足以下任一条件视为未完成：

[具体条件，即使技术上可行但功能不符合要求]
[必须处理的边缘场景 —— 非锦上添花]
[必须达到的质量标准 —— 如「延迟低于200ms」「离线可用」]

Out of Scope

排除范围

[Explicitly NOT doing]

[明确不做的内容]

Open Questions

未解决问题

[Unresolved items]

[未解决项]

Implementation Notes

实现说明

[Technical details, gotchas, dependencies]


**Contract** (for scope-locking before building):
```markdown

[技术细节、注意事项、依赖项]


**合约**（针对开发前锁定范围）：
```markdown

Contract

合约

GOAL: [What does success look like? Include a measurable metric.]

CONSTRAINTS:

[Hard limit 1 — not negotiable]
[Hard limit 2]

FORMAT:

[Exact output shape — files, structure]

FAILURE (any of these = not done):

[Specific failure condition 1]
[Edge case that must be handled]
[Quality bar that must be met]

NOT IN SCOPE:

[Explicitly excluded — with rationale]


**Writing good contract clauses:**

*GOAL* — include a number: "handles 50K req/sec" not "handles high traffic". Define the user-visible outcome: "user can filter by date, status, and assignee" not "add filtering".

*CONSTRAINTS* — only hard limits that are NOT negotiable. Technology: "must use existing ORM". Scope: "under 200 lines, single file". Compatibility: "backwards compatible with v2 API".

*FORMAT* — exact file structure: "single file: `rate_limiter.py`" not "a Python file". What to include: "type hints on all public methods, 5+ tests". What to exclude: "no comments explaining obvious code".

*FAILURE* — the key innovation. Think about how the task could "technically work" but actually be wrong:
- Missing edge case: "no test for empty input"
- Performance miss: "latency exceeds 1ms on synthetic load"
- Silent failure: "swallows errors without logging"
- Incomplete: "doesn't handle concurrent access"
- Over-engineered: "adds abstraction layers not required by GOAL"

**Verification template** (include when handing off to an implementing agent):
```markdown

目标: [成功的标准是什么？包含可衡量的指标。]

约束条件:

[硬限制1 —— 不可协商]
[硬限制2]

输出格式:

[精确的输出形态 —— 文件、结构]

失败条件（满足任一视为未完成）:

[具体失败条件1]
[必须处理的边缘场景]
[必须达到的质量标准]

排除范围:

[明确排除的内容 —— 附理由]


**编写优质合约条款：**

*目标* —— 包含数字：「支持5万次/秒请求」而非「支持高流量」。定义用户可见的结果：「用户可按日期、状态、经办人筛选」而非「添加筛选功能」。

*约束条件* —— 仅包含不可协商的硬限制。技术层面：「必须使用现有ORM」。范围层面：「不超过200行代码，单个文件」。兼容性：「向后兼容v2 API」。

*输出格式* —— 精确的文件结构：「单个文件: `rate_limiter.py`」而非「一个Python文件」。需包含的内容：「所有公共方法添加类型提示，至少5个测试用例」。需排除的内容：「无需为明显代码添加注释」。

*失败条件* —— 核心创新点。思考任务如何「技术上可行但实际不符合要求」：
- 遗漏边缘场景：「未针对空输入编写测试」
- 性能不达标：「在模拟负载下延迟超过1ms」
- 静默失败：「吞掉错误且不记录日志」
- 功能不完整：「不支持并发访问」
- 过度设计：「添加目标不需要的抽象层」

**验证模板**（移交实现Agent时包含）：
```markdown

Contract Verification

合约验证

FAILURE 1: {condition} → VERIFIED: {how you confirmed it passes}
FAILURE 2: {condition} → VERIFIED: {how you confirmed it passes}
GOAL metric met: {evidence}
All CONSTRAINTS respected: {confirmation}
FORMAT matches spec: {confirmation}


**Out-of-scope persistence** (for institutional memory):
When features are explicitly scoped out during conversation, write to `.agents/meta/out-of-scope/[kebab-case-name].md`:
```markdown

失败条件1: {条件} → 已验证: {确认方式}
失败条件2: {条件} → 已验证: {确认方式}
目标指标达成: {证据}
所有约束条件已遵守: {确认内容}
输出格式符合规格: {确认内容}


**排除范围持久化**（用于机构记忆）：
当会话中明确排除某些功能时，写入`.agents/meta/out-of-scope/[kebab-case-name].md`：
```markdown

[Feature/Approach Name]

[功能/方案名称]

Decided: [date] Context: [what was being discussed when this was scoped out] Decision: Not pursuing because [reason from conversation] Revisit if: [condition that would change the decision]

Create the directory if it doesn't exist. This prevents future sessions from re-asking about decisions already made.

**Experience doc** (for the learning flywheel):
Append Q&A to `.agents/experience/{domain}.md` after each session:
```markdown

决策日期: [日期] 上下文: [讨论此内容时的场景] 决策: 不推进，原因是[对话中的理由] 可重新考虑的条件: [改变决策的触发条件]

如果目录不存在则创建。这可避免未来会话重复询问已做出的决策。

**经验文档**（用于学习飞轮）：
每次会话后将问答内容追加到`.agents/experience/{domain}.md`：
```markdown

{Task Name} — Decisions ({date})

{任务名称} —— 决策记录({日期})

Q: {question} A: {user's answer} Rationale: {why this matters for future tasks}


The flywheel effect: each session adds context → future sessions need fewer questions → output quality improves immediately.

---

问: {问题} 答: {用户的回答} 理由: {对未来任务的重要性}


飞轮效应：每次会话添加上下文 → 未来会话需要更少的问题 → 输出质量立即提升。

---

Context Resolution Order

上下文解析顺序

When the discover skill (or any downstream skill) needs context about prior decisions:

Conversation context — same session, decisions are in the chat
Artifact on disk — previous session saved a spec or contract
Discovery — ask the user or scan the codebase

This means downstream skills don't REQUIRE artifacts to exist as files. They need the decisions to be known, from whatever source.

当discover技能（或任何下游技能）需要获取过往决策的上下文时：

对话上下文 —— 同一会话中，决策记录在聊天内容里
本地产出物 —— 往期会话保存的规格文档或合约
重新探索 —— 询问用户或扫描代码库

这意味着下游技能不依赖本地文件形式的产出物。只需知晓决策内容，无论来源如何。

Anti-Patterns

反模式

Anti-Pattern	Problem	Instead
Leading questions	"Don't you think we should use WebSockets?" pushes toward a predetermined answer	Ask open-ended: "What are your latency requirements?"
Accepting the first answer	Surface-level answers miss hidden constraints	Probe deeper: "Why that approach?" and "What would change your mind?"
Asking questions the codebase answers	"What framework?" when package.json is right there	Context scan first; skip answered questions
Options instead of decisions	"We could use X or Y" doesn't resolve anything	Push for concrete choices; undecided items go to Open Questions
Accepting should-want at face value	User says what sounds "correct" rather than actual need	Use intent alignment techniques to probe real needs
Skipping edge cases	Happy-path specs produce code that breaks in production	Explore failure modes, concurrent access, empty states
Scope creep during interview	Each new question expands feature surface	Periodically re-anchor: "Is this still in scope?"
Announcing techniques	"I'm now using the Why Chain technique" breaks conversational flow	Just ask the question naturally
Giant plans nobody reads	Producing a 500-line spec that gets rubber-stamped	Conversation-first; artifacts only when genuinely needed
Fixed dimensions for every problem	Security & Privacy for a CSS refactor wastes time	Adaptive zones based on what matters for THIS problem

反模式	问题	正确做法
诱导性问题	「你不觉得我们应该用WebSocket吗？」引导用户走向预设答案	开放式提问：「你的延迟要求是什么？」
接受第一个答案	表面答案遗漏隐藏约束	深入探查：「为什么选这个方案？」以及「什么会让你改变主意？」
询问代码库已给出答案的问题	「用的什么框架？」而package.json就在眼前	先扫描上下文；跳过已有答案的问题
只给选项不做决策	「我们可以用X或Y」无法解决问题	推动做出具体选择；未决定项归入未解决问题
表面接受应需表述	用户说的是「听起来正确」的内容而非真实需求	使用意图对齐技术探查真实需求
忽略边缘场景	仅覆盖正常流程的规格文档会导致代码在生产环境崩溃	探索故障模式、并发访问、空状态
访谈过程中范围蔓延	每个新问题都扩大功能范围	定期重新锚定：「这仍在范围内吗？」
宣布使用的技巧	「我现在要用追问链技巧」打破对话流畅性	直接自然地提问
没人读的庞大计划	产出500行的规格文档只是走个过场	优先对话；仅在真正需要时产出文档
对所有问题使用固定维度	为CSS重构询问安全与隐私问题纯属浪费时间	根据当前问题的核心需求确定自适应领域

Configuration

配置参数

Parameter	Default	Override example
depth	auto	"quick scope" / "deep interview" / "ask 3 questions"
output	conversation	"save to spec" / "write a contract" / "save answers"
zones	auto (3-5 based on problem)	"focus on technical risks and UX"

参数	默认值	覆盖示例
depth	auto	"quick scope" / "deep interview" / "ask 3 questions"
output	conversation	"save to spec" / "write a contract" / "save answers"
zones	auto（根据问题确定3-5个）	"focus on technical risks and UX"

Edge Cases

边缘场景处理

"Just do it": List assumptions inline and start building. Skip questions. If critical assumptions exist, mention them briefly.
"Skip questions": Use context scan only, summarize what you know, proceed.
"Save this": Write to
```
.agents/spec.md
```
or emit contract format inline.
All questions answered by context: Skip to clarity check. Note that context was sufficient.
User answers are contradictory: Flag the contradiction. Ask one follow-up to resolve.
Task changes mid-conversation: Re-assess whether prior answers still apply. Ask 1-2 new questions if scope shifted. Don't restart from scratch.
Experience doc has answers: Read
```
.agents/experience/{domain}.md
```
first. Only ask questions NOT already answered.
Task is trivial: Say so. Suggest skipping discovery entirely.
User says "that's enough": Respect it. Note current clarity level and any unexplored zones.

「直接做」：列出隐含假设并启动开发。跳过提问。如果存在关键假设，简要提及。
「跳过提问」：仅使用上下文扫描，总结已知信息，继续推进。
「保存这个」：写入
```
.agents/spec.md
```
或直接输出合约格式。
所有问题都可通过上下文找到答案：直接进入共识校验。说明上下文已足够。
用户答案自相矛盾：指出矛盾点。提出一个后续问题解决矛盾。
会话中途任务变更：重新评估过往答案是否仍适用。如果范围变更，提出1-2个新问题。无需从头开始。
经验文档已有答案：先读取
```
.agents/experience/{domain}.md
```
。仅询问未被回答的问题。
任务非常简单：直接说明。建议跳过需求探索环节。
用户说「足够了」：尊重用户选择。记录当前共识程度及未探索的领域。

Skill Deference

技能分工

Have a FEATURE or TASK to clarify? → Use this skill.
Have a declining METRIC to diagnose? → Use
```
problem-analysis
```
instead.
Need multi-perspective debate on a specific decision? → Use
```
agent-room
```
.
Know what to build and need technical design? → Use
```
system-architecture
```
.
Need to decompose into tasks? → Use
```
task-breakdown
```
.

需要明确功能或任务？ → 使用本技能。
需要诊断下降的指标？ → 使用
```
problem-analysis
```
。
需要针对特定决策进行多视角辩论？ → 使用
```
agent-room
```
。
明确要做什么，需要技术设计？ → 使用
```
system-architecture
```
。
需要拆解任务？ → 使用
```
task-breakdown
```
。

Chain Position

技能链位置

Previous: none (or any skill that surfaces a need for clarification) Next:

system-architecture

task-breakdown

, or direct implementation

Re-run triggers: When requirements change significantly, when new constraints emerge, or when implementation reveals the spec was wrong.

前置：无（或任何提出澄清需求的技能）后置：

system-architecture

、

task-breakdown

或直接实现

重新触发条件： 需求显著变更、出现新约束条件、实现过程中发现规格文档错误。

Next Step

下一步

Run

task-breakdown

to decompose the scoped work into buildable tasks. Run

system-architecture

if technical design is needed. Run

icp-research

if audience needs further definition.

运行

task-breakdown

将已界定范围的工作拆解为可开发的任务。如果需要技术设计，运行

system-architecture

。如果需要进一步定义受众，运行

icp-research

。

References

参考资料

references/question-bank.md
— Extended probing questions by domain (data/state, errors, UX, security, performance, integration, business logic, intent alignment)

references/question-bank.md
—— 按领域划分的扩展探查问题（数据/状态、错误、UX、安全、性能、集成、业务逻辑、意图对齐）