建议在 Default mode 中支持 request_user_input，以便采访式 skill 可边问边改文档
背景
目前 request_user_input 问问题工具只能在 Plan mode 中使用。这个限制会影响一些需要“采访式推进”的 skill，例如 grill-with-docs。
grill-with-docs 的典型工作流是：
- 一次只问一个问题；
- 等用户回答后继续追问；
- 如果问题可以通过代码库验证，就先检查代码；
- 当术语、边界或设计决策被澄清后，立即更新
CONTEXT.md；
- 必要时再创建 ADR，而不是提前批量整理。
这个工作流天然需要两个能力同时存在：
- 采访式 UI：用
request_user_input 一次问一个结构化问题；
- 文件修改能力：在用户回答后即时修改
CONTEXT.md 或相关文档。
但当前两个能力被拆在不同模式里，导致工作流割裂。
复现步骤
- 在 Default mode 下启动一个需要文档拷问的任务，例如：
- “使用
grill-with-docs 帮我梳理这个项目的领域模型”
- “文档拷问一下这个方案，并把结论同步到
CONTEXT.md”
- skill 需要一次问一个问题，并希望使用
request_user_input 提供结构化选项。
- 尝试调用
request_user_input。
- 发现该工具仅在 Plan mode 可用。
- 切换到 Plan mode 后，虽然可以使用采访 UI 问问题，但又不能即时修改项目文件，例如
CONTEXT.md。
- 回到 Default mode 后，可以改文件，但不能使用采访 UI。
实际行为
当前行为是：
- Plan mode 能使用
request_user_input 问问题；
- Plan mode 不能修改文件；
- Default mode 能修改文件；
- Default mode 不能使用
request_user_input 采访 UI。
因此，grill-with-docs 这类 skill 无法在一个连续模式中完成“提问 -> 用户回答 -> 立即更新文档 -> 继续追问”的闭环。
实际结果是：
- 要么在 Plan mode 中问完一批问题，再切换回 Default mode 批量修改文档；
- 要么在 Default mode 中用普通聊天文本问问题，失去
request_user_input 的结构化交互体验；
- 要么频繁在模式之间切换，打断用户思路，也增加 agent 执行复杂度。
期望行为
希望 request_user_input 可以在 Default mode 中使用，至少对明确需要交互式澄清的 skill 开放。
理想行为是：
- 在 Default mode 下，agent 可以调用
request_user_input 一次问一个问题；
- 用户回答后，agent 可以继续读取代码、修改
CONTEXT.md、创建 ADR 或更新其他文档；
- 整个
grill-with-docs 工作流可以在同一模式中完成；
- Plan mode 仍然保留其规划用途，但不再成为采访 UI 的唯一入口。
影响范围
受影响的不只是 grill-with-docs，还包括一类需要“边问边执行”的 skill 或工作流，例如：
- 领域建模访谈；
- 需求澄清；
- 架构决策记录；
- PRD/ADR/CONTEXT 文档共创；
- 代码库迁移前的逐项确认；
- 需要用户在多个互斥选项中逐步决策的工程任务。
这些任务的共同点是：
- 问题必须逐个提出；
- 用户回答会立即改变后续问题；
- 结论需要及时落到文件中；
- 批量问答或纯计划模式都不适合。
建议方案
建议考虑以下方案之一：
-
在 Default mode 中开放 request_user_input
允许 Default mode 调用 request_user_input，使 agent 可以在具备文件修改能力的同时使用结构化采访 UI。
-
增加一个可写的交互模式
提供类似 “Interactive Default mode” 的能力：既允许工具化提问，也允许文件读写、运行命令和提交修改。
-
按工具权限细分，而不是按模式硬切
将 request_user_input 视为低风险交互工具，而不是仅属于 Plan mode 的规划工具。是否允许文件修改可以继续由执行模式或权限控制，但提问 UI 本身不应强绑定 Plan mode。
-
允许 skill 声明需要的交互能力
例如 skill metadata 可以声明：
requires:
- structured_user_input
- file_editing
当 skill 同时需要结构化提问和文件修改时，Codex 可以自动选择支持两者的运行方式，或提示用户切换到合适模式。
总结
当前限制的核心问题是：
- Plan mode 能问，但不能改文件；
- Default mode 能改文件，但不能用采访 UI。
这使得 grill-with-docs 这类本应“边问边沉淀文档”的 skill 被迫拆成两段，降低了交互质量和执行连贯性。
建议让 request_user_input 在 Default mode 中可用，或提供一个同时支持结构化提问与文件修改的模式，以支持采访式、文档共创式、决策沉淀式的 agent 工作流。
建议在 Default mode 中支持
request_user_input，以便采访式 skill 可边问边改文档背景
目前
request_user_input问问题工具只能在 Plan mode 中使用。这个限制会影响一些需要“采访式推进”的 skill，例如grill-with-docs。grill-with-docs的典型工作流是：CONTEXT.md；这个工作流天然需要两个能力同时存在：
request_user_input一次问一个结构化问题；CONTEXT.md或相关文档。但当前两个能力被拆在不同模式里，导致工作流割裂。
复现步骤
grill-with-docs帮我梳理这个项目的领域模型”CONTEXT.md”request_user_input提供结构化选项。request_user_input。CONTEXT.md。实际行为
当前行为是：
request_user_input问问题；request_user_input采访 UI。因此，
grill-with-docs这类 skill 无法在一个连续模式中完成“提问 -> 用户回答 -> 立即更新文档 -> 继续追问”的闭环。实际结果是：
request_user_input的结构化交互体验；期望行为
希望
request_user_input可以在 Default mode 中使用，至少对明确需要交互式澄清的 skill 开放。理想行为是：
request_user_input一次问一个问题；CONTEXT.md、创建 ADR 或更新其他文档；grill-with-docs工作流可以在同一模式中完成；影响范围
受影响的不只是
grill-with-docs，还包括一类需要“边问边执行”的 skill 或工作流，例如：这些任务的共同点是：
建议方案
建议考虑以下方案之一：
在 Default mode 中开放
request_user_input允许 Default mode 调用
request_user_input，使 agent 可以在具备文件修改能力的同时使用结构化采访 UI。增加一个可写的交互模式
提供类似 “Interactive Default mode” 的能力：既允许工具化提问，也允许文件读写、运行命令和提交修改。
按工具权限细分，而不是按模式硬切
将
request_user_input视为低风险交互工具，而不是仅属于 Plan mode 的规划工具。是否允许文件修改可以继续由执行模式或权限控制，但提问 UI 本身不应强绑定 Plan mode。允许 skill 声明需要的交互能力
例如 skill metadata 可以声明：
当 skill 同时需要结构化提问和文件修改时，Codex 可以自动选择支持两者的运行方式，或提示用户切换到合适模式。
总结
当前限制的核心问题是：
这使得
grill-with-docs这类本应“边问边沉淀文档”的 skill 被迫拆成两段，降低了交互质量和执行连贯性。建议让
request_user_input在 Default mode 中可用，或提供一个同时支持结构化提问与文件修改的模式，以支持采访式、文档共创式、决策沉淀式的 agent 工作流。