Craft Codex Prompts 是做什么的？
目标
将不完整的上下文转化为另一个 Codex 对话可以执行的任务包，且不会将衍生的解释当作事实。优化目标包括：源忠实度、权限边界、可测试的完成标准以及低提示开销。
选择操作
- 起草: 从文件、项目上下文或粗略请求中构建提示。
- 审查: 诊断现有提示的弱点，然后生成修订版本。
- 交接: 将之前的工作、结果和未解决问题转化为下一个可执行的提示。
- 知识循环: 生成知识库就绪的当前状态、决策、未解决问题和交接更新。
如果用户只要求一个提示，则仅返回该提示以及必要的假设。如果用户要求一个可重用工作流，则返回完整的任务包。
工作流
1. 建立来源与权限
在授权且有价值的前提下，在起草前以只读方式检查用户提供的文件和可访问的项目材料。仅在准备提示时，不要修改源项目。
对输入进行分类：
- 主要事实: 当前文件、仓库状态、用户明确声明、权威项目文档。
- 衍生上下文: 摘要、之前的助手结论、报告和复制的聊天记录。
- 未知项: 缺失的文件、未验证的运行时状态、未解决的抉择和外部依赖。
将衍生上下文视为线索，而非证据。明确声明执行对话必须对照主要来源进行验证。
不要假定一个对话中附带的文件在另一个对话中也可用。指明执行对话必须接收的每个文件或确切的工作空间。
2. 识别任务类型
选择最接近的任务类型：
- 回答或解释；
- 检查或审查；
- 诊断；
- 变更或构建；
- 研究或比较；
- 创建工件；
- 执行外部操作。
保持匹配的权限边界。分析或诊断的请求并不授权编辑。变更或构建的请求通常授权范围内的实施和验证，但不授权无关的重构、发布、消息通知、提交、推送或破坏性操作。
阅读 task-blueprints.md 以获取匹配的任务模式。
3. 分离固定规则与任务增量
将持久的项目规则放入项目契约中，例如 AGENTS.md、PROJECT_BRIEF.md 或 CODEX_TASK_CONTRACT.md。让当前提示专注于此次发生的变化。
仅在规则对安全至关重要或可能被遗漏时，才在任务提示中重复固定规则。
4. 适当地解决歧义
仅当答案会实质性地改变范围、来源选择、不可逆行为、外部影响或验收标准时，才提出澄清性问题。否则，选择最安全的合理假设并进行标注。
切勿将缺失的来源、不支持的能力或外部阻塞隐藏在自信的措辞中。
5. 组合任务包
在相关时，创建以下部分：
- 结果: 一个具体的最终状态。
- 事实来源: 确切的文件、路径、数据或用户决策。
- 当前状态: 仅为已验证或明确归因的事实。
- 范围: 允许的读取、编辑、系统和工件。
- 非目标: 可能但不被授权的扩展。
- 相邻检查: 可能暴露相同缺陷的下游表面。
- 执行指导: 影响正确性的约束，而非推测性的实现细节。
- 验收: 可观察的检查和预期的证据。
- 阻塞项与停止条件: 需要报告而非猜测的条件。
- 交付: 变更的文件、工件、证据、限制和下一次交接。
当涉及实施时，使用 L1-L4 验证阶梯：
- L1: 语法、导入、模式或静态验证；
- L2: 单元、服务或针对性回归测试；
- L3: 真实文件或端到端数据路径验证；
- L4: 实际 UI、打包的运行时、设备、类生产或人工验收。
不要将较低级别作为较高级别已完成的证据。
包含此源忠实度条款，并根据任务进行调整：
将此提示视为执行简报，而非仓库状态的证明。请对照当前工作区和主要文件验证其声明。若存在冲突，则保留源材料，报告冲突，并遵循原始来源，除非用户另有决定。
6. 保持提示的可执行性
- 以结果开头。
- 使用直接的指令和具体的名词。
- 优先使用文件名、路径、计数和预期的工件，而非形容词。
- 避免复制原始聊天记录，除非精确的措辞本身就是证据。
- 避免在检查之前规定架构，除非用户已固定该选择。
- 将禁止事项限制在现实的失败模式内。
- 说明 Codex 应仅报告、诊断、实施，还是实施并验证。
- 以紧凑的完成格式结尾。
7. 交付前审计
根据六项检查对提示进行内部评分：
- 准确度: 每个事实声明都能追溯到来源吗？
- 权限: 读取、编辑、外部操作和被禁止的操作是否明确无误？
- 完整性: 是否涵盖了可能的相邻消费者和失败路径？
- 可测试性: 完成情况是否可以通过可观察的证据来证明？
- 可行性: 是否暴露了不可用的工具、运行时限制和人工依赖？
- 简洁性: 每条指令是否改变了执行或验证方式？
返回一个状态：
READY: 在现有上下文下可执行；READY_WITH_ASSUMPTIONS: 列出有界假设后可执行；NEEDS_INPUT: 缺少一个或多个关键选择；BLOCKED_SOURCE_MISSING: 缺少必要的主要材料。
不要仅仅为了表面上提升严谨性而扩充提示。
8. 闭合知识循环
当用户在 Obsidian 或其他知识库中归档工作时，阅读 obsidian-loop.md。将不可变的原始聊天记录与当前项目真相分开。执行后，更新当前状态、决策、未解决问题和交接，而不是仅依赖对话记录。
默认输出
除非用户要求其他格式，否则返回：
## TASK_BRIEF
[已验证的事实、假设、未知项、来源]
## MAIN_PROMPT
[可复制执行的提示]
## PROMPT_STATUS
[READY, READY_WITH_ASSUMPTIONS, NEEDS_INPUT, 或 BLOCKED_SOURCE_MISSING]
[简短解释及任何需要附带的附件]
对于提示审查，在 MAIN_PROMPT 之前添加一个简短的 KEY_GAPS 部分。不要暴露私有的思考链条；提供简洁、与决策相关的理由。