culture

/culture

两种模式；由调用上下文而非用户标记选择模式：

1. 内部模式（默认）。 其他工作流技能——以及 /cheese 本身——会在思考阶段静默调用 /culture：重述问题、列出假设、指出候选选项、快速检查问题结构，然后选定下一步行动。对话不会呈现给用户；只有最终决策（连同其记录台账）以及调用技能所做的任何代码编辑会被呈现。最常见的调用方包括：
   • /cheese 第 1 步——在宣布之前进行静默分类推理。
   • /cheese 二级升级（参见 skills/cheese/SKILL.md § Escalation）——当原始输入未通过快速烹制路径的清晰度检查时，补充缺失的上下文；综合结果会写入迷你规格的 ## Provenance 部分。
   • 其他工作流技能自己的分发前推理阶段（mold、cook taste-test 等）。
2. 面向用户的模式。 用户想要思考，而不是构建：不写生产代码、不写规格，也不提交 PR。这是 culture 持续进行领域建模的模式——根据问题所需深入调查，让问题在多轮对话和多个会话中保持开放，而不是强行收敛；随着想法、决策和信息逐渐明晰，将其记录下来（## Record ledger）；最后写入一份持久的 /wheypoint，以便之后继续建模。当用户表示“不要写入”/“陪我理清思路”/“只是聊聊”，要求一起思考问题（“这些 bug 感觉彼此有关”“我想先弄明白再修复”），或将思考与建模任务转交到此处时，进入此模式。

当用户想要书面规格（/mold）、实现（/cook）、bug 诊断或修复（/pasteurize）、审查（/age）或外部证据收集（/briesearch）时，不要使用面向用户的模式——这些目标应调用内部模式，由调用技能执行相应工作。

对话导航（原型）

在面向用户的会话中，用户通过普通对话切换问题层级；这是导航，不是单独的入口路径。 层级导航可补充下方的流程。 当证据表明存在某种模式，或行为与目标之间存在差距时，建议切换到合适的问题层级。 说明你的理解，并遵守约定的证据范围。 提出建议并不等于授权进行全面审查或进入后续阶段。 在切换层级、检验共同原因或梳理关联时，请阅读 问题层级。 保持静默内部推理不变：不加载参考资料，也不启动用户访谈。 Culture 仍负责维护记录台账并在会话结束时交接。 评估行为时，请使用压力场景。

不变量

/culture 不编写生产代码或规格，不提交更改、不创建 PR，也不修改项目状态。它写下的是知识。在面向用户的模式中，它通过 ## Record ledger 记录想法、决策和信息，并在每次会话结束时写入一份持久的交接文档，由 /wheypoint 负责（参见 ## Handoff slug）；该 wheypoint 只会在会话结束时写入，绝不会在对话过程中写入。由用户宣布会话结束——Agent 绝不会擅自替用户宣布问题已收敛；它可以询问讨论是否已告一段落，否则就会继续跟进。如果面向用户的对话表明需要构建某些东西，请在写入 wheypoint 后转交给 /mold 或 /cook。在内部模式中，则只需返回决策，让调用技能采取行动。

流程

两种模式共用这一推理循环；每一步的区别在于：一种在内部返回决策，另一种面向用户呈现对话。

1. 用一句话重述问题或分歧。如果问题建立在错误前提或带有倾向性的假设之上，指出这一点。
2. 明确假设、约束和决策标准。
3. 探讨权衡及可能的影响范围。当权衡取决于“会影响什么”时，对候选边界进行只读范围检查——搜索语义调用方，并从所选后端获取依赖关系和影响范围背景；为每个选项标注 [low | medium | high blast radius]。具体流程参照 ../mold/references/shape-check.md；culture 止步于判定，绝不起草签名。在做出建议前，先以最有力的方式论证被否决的选项。
4. 根据问题所需的深度收集证据。先进行轻量 wiki 探查——这件事是否已经有定论或已有答案？——遵循 ../cheese/references/optional-plugins.md 中的检测并降级约定：内部模式至多调用一次 ground，面向用户的模式则可酌情增加调用次数；当 hallouminate 不可用时，跳过、只说明一次其不可用，并在设计依据至关重要时将置信度上限设为 speculating。在内部模式中，其余步骤保持轻量——快速进行范围检查，不做深入研究——以确保调用该技能的流程保持快速。在面向用户的模式中，可按需深入调查：派遣只读 explorer Agent 进行代码验证并取回其摘要，而不是把原始读取结果直接倾倒到对话中；如果该 Agent 不可用，则直接调用所选源代码后端。
5. 决定下一步行动。在内部模式中，只返回一条建议，然后停止。在面向用户的模式中，不必强求达成一致：呈现精简摘要、Ideas / Decisions / Info 台账，以及带置信度标签的待解决问题（certain | speculating | don't know），然后建议使用后续技能，或暂缓决定并继续跟进。当用户表示讨论结束后，刷新台账，然后通过写入 wheypoint（## Handoff slug）结束会话，其中的 next: 记录建模结论。

征询用户的意见正是重点：每个会产生重大影响的分歧都应由用户决定，并以选项的形式呈现，而不是替他们定夺。根据 ../age/references/voice.md 中的杠杆线判断分歧是否会产生重大影响；其余内容均标记为 [AGENT-DECIDED]，并提供可否决的替代方案。你提供的细节深度——完整签名、明确的边缘情况、文件:行号证据——有助于用户逐项作出决定，却绝不能取代征询用户意见。在面向用户的模式中，应在对话中以自然方式提出分歧；结构化提问工具仅用于会话结束时的交接关卡。绝不要在同一个提示中捆绑多个会产生重大影响的分歧。

记录账本

思考值得留存。每轮面向用户的对话都会在待解决问题旁打印一份 Ideas / Decisions / Info 账本，每条记录都会进入持久知识区，绝不写入代码：

类型	判定标准	使用 hallouminate 时的目标位置	无法使用时的回退位置
Decision	用户在有实际备选方案的分歧点上作出了决定	repo:<repo>:wiki 中 adr/ 下的一份 ADR，格式和决议遵循 ../mold/references/adr.md	docs/adr/<slug>-NNN.md
Idea	值得日后重新考虑，但无人承诺采纳的方向	Wiki 中的 ideas/<slug>.md	docs/culture/<slug>.md § Ideas
Info	对话过程中了解到的事实、约束或注意事项	并入其扩展的 Wiki 页面（ground → read_markdown → add_markdown { overwrite: true }）；仅在没有合适页面时新建页面	docs/culture/<slug>.md § Info

按照 adr_target() 的方式确定目标：根据当前仓库的 repo:<repo>:wiki 语料进行结构匹配，绝不使用字面名称；若无法使用 hallouminate，则写入受版本控制的回退位置，并用一行醒目的文字说明。用户说出 record that、note that 或 remember that 时，立即写入相应记录；用户结束对话后，在生成 wheypoint 之前写入其余记录，随后 wheypoint 会在其 artifacts 下链接每条记录。绝不记录用户未作决定、也未要求留存的随口想法——这些内容留在 wheypoint 中。内部模式不写入任何内容：它会将账本纳入自己的决策中返回，由调用方技能负责持久化（Mold 的 Curdle 会将决策转化为 ADR；mini-spec 会在 ## Provenance 下引用这些记录）。

首选工具与回退方案

根据 code-intelligence-routing.md，直接调用源代码搜索和读取后端。分析影响范围时，使用语义调用方搜索，并在后端提供只读依赖关系／结构检查时一并使用。

除源代码路由外，还有一些特定于文化工作的工具：

需求	首选	回退方案
可视化差异或示例	delta	纯 git diff
外部核验	/briesearch	明确标记为假设
Wiki 依据（证据步骤；内部模式中最多调用 1 次 ground）	在 repo:<repo>:wiki 上使用 mcp__hallouminate__list_corpora + mcp__hallouminate__ground——参见 ../cheese/references/optional-plugins.md	跳过；仅说明一次工具不可用；当设计依据是核心内容时，推断程度最高限于 speculating

缺少可选工具不应中断对话。内部模式下应少用工具；这是快速思考环节。面向用户的模式下，工具使用量应根据问题调整——若建模需要依据，应通过 explorer Agent 展开调查；若该 Agent 不可用，则直接调用源代码后端。

输出

参见 Flow 第 5 步。

交接 slug

每次面向用户的会话结束时，都要编写一份持久的 wheypoint，以便后续恢复建模。调用 /wheypoint <focus>，由它负责压缩内容、隐去机密、按状态映射建议技能部分，并生成可恢复的 slug。Culture 不维护自己的 schema；slug 约定（status / next / mode / artifact 和 ## Document 正文）定义在 skills/wheypoint/SKILL.md 中，那里是唯一事实来源。

与 Culture 相关的 next: 值：culture 或 hold 表示稍后在新会话中恢复建模（暂缓收敛）；mold 表示想法尚不明确，转入规范编写；cook 表示需求明确，转入实施；用户认为对话确实已结束时使用 done。如果下一步受限于一项需要人工决定的事项，应设置 status: gated:，而不是设置 next: 值。

移交

流程： [培养] → 塑形 → 烹制（⇄ 压制）→ 熟成 → 腌制 → 摆盘

会话结束时，先写入持久化的 wheypoint（调用 /wheypoint），然后——当对话中出现了实际工作时——通过 ../cheese/references/handoff-gate.md 中的共享移交关卡询问。任何到达此关卡的结构化确认都必须符合 ../cheese/references/ask-user-question.md 中的新鲜度规则——只有本次会话中已经通过对话讨论过的分支，才能在此提出结构化问题。每个选项都以动词开头（说明用户接下来想做什么）；技能命令是辅助细节。提问前，先生成一份精简的上下文包，方便下游技能继续处理而不丢失讨论内容：

handoff_context:
  source_skill: /culture
  summary: <one factual sentence>
  open_questions: [<only blockers, if any>]
  artifact: .cheese/notes/<slug>.md  # the session wheypoint, always written
  records: [<wiki page or fallback path per written ledger entry>]

默认选项（从中最多选三项，另加停止选项）：

• 将想法整理成书面规范（推荐用于想法仍较模糊的情况）——使用上下文包运行 /mold，或在已有笔记 slug 时运行 /mold .cheese/notes/<slug>.md。
• 直接实现（推荐用于需求清晰明确的情况）——使用上下文包作为已确认的约定运行 /cook。
• 实现并自动审查——运行 /cook --auto 并附上上下文包，执行 Cook 的 Press 循环，然后自主串联 /age → /cure，最多进行两轮 cure，修复所有中等及以上问题，以及低优先级但修复成本低（修复范围明确）的问题。流程在最后一轮 cure 后停止；打开或更新 PR 仍需手动操作。当对话已经达成明确无歧义的约定时，预先选中此项；如果用户希望逐步审批，则提供非自动的 /cook 作为替代选项。
• 先进一步研究（适用于对话中出现了外部文档可以解答的事实缺口）——运行 /briesearch。
• 暂停／稍后恢复——不派发任何技能；会话 wheypoint 已记录当前状态，可随时通过 /cheese --continue <slug> 恢复。

选择非停止选项后，立即使用上下文包运行所选的下游技能。从 culture 开始时，下一步绝不能是 /age——审查需要有 diff 可供检查。

规则

• 只写入知识——包括 ## Record ledger 条目和会话结束时的 wheypoint——绝不写入代码、规范、提交或 PR；参见 ## Invariant。
• 向用户询问会影响工作方向的决策——探索过程中一次只问一个重要分支——不要擅自替用户决定。其余事项自行决定并记录。
• 该同意时就表示同意；不要为了显得平衡而刻意提出反对观点。
• 当外部证据引出替代方案（“X 使用 Y 或 Z”）时，应在对话中将其说明为权衡，并列为候选选项；绝不要默默建议“两个都加上”或“暴露一个可调参数”。重要设计选择需要用户明确裁定，不能根据引用内容由 Agent 推断；影响较小的事项则自行选择一项，并记录替代方案。
• 遵循共享语气内核（位于 ../age/references/voice.md）：先给出答案，标注置信度为 certain | speculating | don't know，充分论证对方观点，并跟踪不同轮次之间的矛盾。