idea-genie

Idea Genie

构思工作的唯一规范入口：征集以证据为依据的备选方案组合，或通过封存的独立视角挑战一个影响重大的构想。两种模式都会探索并提供建议；都不会筛选、排期、跟踪、实施或验证工作。

模式

触发短语	模式	输出约定
"idea genie", "what should we build next", "brainstorm options", "supported opportunities"	征集	idea-portfolio.v1
"challenge this idea", "compare independent proposals", "stress-test a one-way door"	对决	idea-challenge.v1

征集是入口模式。对于影响重大的选择，可选择升级到对决模式，通常会使用 idea-portfolio.v1 或一个明确界定的问题。由多个成员为彼此的构想打分的计分式多成员对决，属于 Council 的对决模式；计划的失败模式则属于 Premortem。

两种验证器都位于此技能的 scripts/ 目录中，并且需要 jq。如果没有 jq，请根据结构手动检查各字段，并说明验证器未运行。

Elicit 模式

这些规则具有以下效力：

1. **观察结果要注明来源：**文件及行号、问题、文档或测量数据。 未注明来源的内容都是假设，应单独列出，且绝不能作为依据。
2. **每个候选方案都要注明其背后的观察结果。**没有引用依据，就没有候选方案；缺乏依据的想法可以继续列为假设。绝不要为了凑数而扩充列表。
3. **声称具有新颖性前先检查重叠。**将每个候选方案与产品已有的功能，以及仍然适用的先前决策（ADR、已关闭的问题或记录的经验教训）进行比较。已有功能已能满足的请求不算新内容：将其记录在能进一步完善该功能的候选方案的 overlaps 中，或将其省略。只有在有新证据回应了原先的否决理由时，才保留被决策否决的想法，并在 overlaps 中引用该决策。
4. **每个候选方案只能有一条 Given/When/Then，**描述一个常规或边缘情况，其中 Then 应体现所引用的问题有所缓解；如果即使问题依然存在，Then 也可能成立，那它针对的就是代理指标。目标或症状还不是问题：要引用其成因，或将成因列为假设，并让 Then 体现所引用的症状有所缓解。
5. **不要排序、挑选、安排时间或启动工作。**由调用方或 Plan 来选择。
6. **达到饱和时停止。**合并等效项，只有在下一轮能增加一个有实质性新证据支持的候选方案时才继续。候选方案数量为零也有效。
7. **先生成，再评判。**将主题拆分为证据所表明的各个部分，并使用主题本身的措辞来命名，而不是列出目录；先围绕每个部分起草候选方案，再进行筛选。然后调整那些可预见的首批想法：删除或反转某个步骤，打破被视为固定条件的假设，将约束推向极端，借鉴其他领域解决同类问题的做法，或寻找能降低后续行动成本的举措。任何项目都能原封不动列出的候选方案，都必须补充具体观察结果，否则就应舍弃。每个被舍弃想法都要在 dropped 中留下一行理由，避免后续轮次重新生成；没有任何有依据的候选方案的部分也要列在其中。
8. 行为比明确表达的兴趣更重要。“用户提出过这个需求”的分量，不及他们目前的实际行为：已经采用的变通方法、这种方法给他们造成的成本，以及类似做法的实际采用情况。明确每个候选方案必须超越的现状；如果目前没有人针对该问题采取变通措施，也要说明。

首先说明问题、约束、非目标和来源；只加载该问题所需的来源并加以引用，不要创建合并的上下文存储。 在一个已命名的部分（流程、命令、页面或阶段）内，尽可能深入分析，但不得超出证据支持的范围：改变整个产品形态的候选方案属于范围越界；将主题替换为其他领域的候选方案则属于主题替换。如无引用的观察结果表明该部分不改变就无法解决问题，应说明原因并舍弃这两类方案。如果没有指定主题，则抽查每个顶级区域和近期提交记录，而不是猜测重点；让每个候选方案的证据说明其主题为何值得关注。 按以下格式返回方案集：

{
  "schema_version": "idea-portfolio.v1",
  "status": "candidates",
  "observations": [{"claim": "<what is true>", "evidence": "<cited source>"}],
  "assumptions": ["<belief no cited source supports>"],
  "candidates": [{
    "id": "I1",
    "evidence": ["<cited sources behind this candidate>"],
    "overlaps": ["<existing capability it extends or repeats>"],
    "scenario": {"given": "<state>", "when": "<event>", "then": "<observable result>"}
  }],
  "dropped": [{"idea": "<short name>", "reason": "<overlap, no evidence, or why it lost>"}],
  "termination": {"reason": "novelty-saturated", "novel_candidates_last_pass": 0}
}

overlaps 可以为空；dropped 为可选字段。当所有想法都与现有内容重叠或缺乏支持时，将 status 设为 no-new-work，让 candidates 为空，并将 termination.reason 设为 all-overlap-or-unsupported。面向个人时，将相同字段呈现为简短列表，每个候选方案单独成块。如果需要写入文件，请写入 .agents/scratch/ideas/<run-id>/idea-portfolio.json，并在交付给调用方或 Plan 前对其运行 scripts/validate-output.sh。只有 Plan 可以将选定方案纳入现有 bead 或调用方的意图中。

对决模式

为一项影响重大的选择提出相互独立的挑战。结果是供 Plan 参考的建议性证据。它不会判断计划是否已就绪，也不会把之后可选的 Premortem 挑战变成审批关卡。

门的类型。 询问选择生效后要撤销它会付出什么代价。单向门需要迁移、会破坏已发布的契约或调用方、会丢失数据，或会产生无法撤回的外部影响。低成本的双向门可通过回滚或功能标志撤销。

约束

• 封存生成过程：在所有观点都完成之前，任何观点都看不到其他观点，因此后续方案无法受先前观点影响。
• 保留异议、未成功的反驳和少数意见的推理；Plan 必须看到综合归纳原本会抹去的备选方案。
• 双向门要保持轻量：不要设置面板管理器、消息服务、评议会或模型家族规则。
• 不得输出就绪状态、审批、法定人数、重试、预算、助手、交付或跟踪器状态：此策略提供证据，而非生命周期权限。共识、传输可用性或自评分数都不能成为就绪状态。

工作流

1. 固定问题、约束、证据路径和比较标准。未知项保持开放。仅某种方案需要的假设应归属于该方案；若将其列入共同约束，就会在未察觉的情况下排除其他方案。
2. 对于单向门，至少启动两个全新上下文：使用没有共享记录的独立子 Agent 或会话，每个上下文只发送一条提示词，其中包含已固定的问题和证据路径，并要求按封存观点格式返回。将每个原生上下文 ID 记录为 context_id，并在揭示任何观点之前收集所有观点。当调用方将观点固定到模型配置时，记录每个 model_identity（参见 agent-native 模型分发方案）；说明无法使用的配置，并继续采用单模型。
3. 揭示封存的观点，并根据证据、可逆性、系统适配性、故障模式和成本逐一交叉审查。按机制而非名称比较观点：依赖同一机制的两个观点算作一个备选方案；少于两个不同机制的比较是不完整的比较，而非胜出者；收敛中有一次有界恢复。违反已固定约束的观点应排除，无论它有其他哪些优点。由多个观点的部分内容组合而成的方案是一个新的候选方案，不继承任何支持：在列出之前，用一个具体示例逐一检验组合设计所需的每项保证；否则将其列为未经核验，以免 Plan 因盲目信任而将其组合。
4. 尝试具体反驳。若每个观点都建立在已固定问题的某个前提上，那么它们的一致意见并不能为该前提提供支持：请在其来源处核查。用状态跟踪反驳有状态机制，而不是写一段文字。明确保留分歧、未成功的反驳和少数意见的推理。
5. 编写 idea-challenge.v1，验证后将其作为与研究和操作者意图并列的一项可选输入传递给 Plan。

对于低成本的双向门，在一次全新挑战后直接输出轻量数据包。不要刻意制造评审流程。

输出规范

• 制品目录： .agents/scratch/ideas/<run-id>/
• 文件名： idea-challenge.json
• 格式： idea-challenge.v1 JSON，采用以下两种结构之一；其中不包含就绪状态字段或决策
• 验证命令： scripts/validate-challenge.sh <idea-challenge.json>
• 下游交接： handoff.owner 必须恰为 plan；Plan 可接受、拒绝或合并这些参考性证据

单向数据包：

{
  "schema_version": "idea-challenge.v1",
  "door_class": "one-way",
  "sealed_generation": true,
  "perspectives": [
    {"id": "P1", "context_id": "<native context id>", "proposal": "<mechanism, evidence, tradeoff>"},
    {"id": "P2", "context_id": "<a different context id>", "proposal": "<mechanism, evidence, tradeoff>"}
  ],
  "cross_reviews": [{
    "reviewer": "P1",
    "subject": "P2",
    "dimensions": {"evidence": "<finding>", "reversibility": "<finding>", "system_fit": "<finding>", "failure_modes": "<finding>", "cost": "<finding>"}
  }],
  "disagreements": ["<where the perspectives still differ>"],
  "refutations": [{"claim": "<what was attacked>", "attempt": "<the concrete test>", "result": "<what the attempt showed>"}],
  "handoff": {"owner": "plan", "artifact_dir": ".agents/scratch/ideas/<run-id>/"}
}

至少需要两个视角，每个视角都具有自己的 id 和不同的 context_id；视角还可以包含 model_identity 及其提案。cross_reviews、disagreements 和 refutations 均至少需要一条记录。每条交叉评审都必须命名两个不同的视角 ID，并至少包含一个维度；它列出的每个维度都必须有非空文本评估；每条分歧都必须是非空字符串；每条反驳都必须填写 claim、attempt 和 result。 单向数据包中不要包含 requires_ntm。

双向数据包将 sealed_generation 设为 false，并将四个列表全部留空；添加 "requires_ntm": false，以记录未使用窗格管理器；并命名其路由：

{
  "schema_version": "idea-challenge.v1",
  "door_class": "two-way",
  "sealed_generation": false,
  "perspectives": [],
  "cross_reviews": [],
  "disagreements": [],
  "refutations": [],
  "requires_ntm": false,
  "handoff": {"owner": "plan", "artifact_dir": ".agents/scratch/ideas/<run-id>/", "route": "single-fresh-context"}
}

双向数据包记录的是路由，而非挑战，因此请将新挑战的发现与其一并传递给 Plan。验证器会拒绝任何其他顶层字段，而 handoff 仅接受 owner、artifact_dir 和 route。

参考资料

• Idea Genie 行为
• Idea challenge 行为
• Sealed perspectives