benjaminstelzer/scoville-plan

Scoville Plan

将项目方向保持在可审查的仓库文件中，无需规划CLI、MCP服务器、数据库、日志或隐藏状态。此技能拥有规划纪律以及原生的计划和决策维护。它记录人类已经做出的选择，并在请求生命周期决策之前，将未解决的重大选择作为提案保留。它不赋予推断选择以权威，也不证明所报告的工作已完成。

保持完整的受支持 format_version: 1 功能面：只读恢复、设置、计划、工作项、决策、提案、生命周期、障碍、证据和有限修复。使用直接的原生编辑，不移除或重新解释项目知识功能。

在明确选择退出时，不读取引用、创建或更改规划文件，也不做出基于技能的声明。如果更高优先级的项目指令要求此计划系统，请报告该确切冲突。同级Scoville的退出仅排除该同级。

遵循现有所有者

按以下顺序解决规划要求：

1. 当前请求的系统、安全和显式指令；
2. 仓库指令及其现有的规范规划机制；
3. 现有的受支持原生配置文件；以及
4. 此技能对未指定项的默认设置。

切勿在项目拥有的计划旁边创建第二个计划。如果另一个持久的计划系统已经拥有状态，请使用它，并仅在此技能兼容的情况下应用其规划质量护栏。运行时计划是可丢弃的镜像，而不是第二个规范所有者。

此技能没有必需的执行依赖项，并且从不调用规划CLI。其捆绑的 Python 验证器是可选的严格只读结构检查，绝不是写入路径。不要声称锁定、原子多文件发布、类型化突变安全性或语义证明。使用普通的作用域文件工具，并仅报告实际执行的检查。

此技能独立工作。永远不需要、安装或模拟 Code、UI 或 Scribe。当同级技能独立适用时，仅组合其拥有的实现、接口或措辞关注点；其缺失不会削弱计划结构、生命周期、权威或证据规则。

决定是否需要持久规划

在以下情况下使用仓库计划：多个依赖结果、实质性排序、必须经受中断或交接的工作，或绑定项目工作流。对于单个小的可逆更改，除非项目已要求跟踪工作项，否则直接实施和验证。

在加载详细信息前对操作进行分类：

操作	加载
读取当前方向或列出记录而不写入	read-only.md
初始化完全不存在的配置文件	planning-granularity.md、native-plan-format.md、native-project-lifecycle.md 和 native-editing.md
创建或重组计划	planning-granularity.md、native-plan-format.md、native-project-lifecycle.md 和 native-editing.md
插入、细化、移动、选择、阻塞、推进或移除工作项	native-plan-format.md、native-work-items.md 和 native-editing.md
记录显式的人类选择或重要的可能决策	native-decision-format.md、native-plan-format.md 和 native-editing.md
应用显式授权的决策转换	native-decision-format.md、native-plan-format.md 和 native-editing.md
应用显式授权的接受或拒绝批次	native-decision-format.md、native-decision-batches.md、native-plan-format.md 和 native-editing.md
激活、完成或取消计划	native-plan-format.md、native-project-lifecycle.md、当前工作更改时使用 native-work-items.md 和 native-editing.md
审计原生计划结构或生命周期	native-plan-format.md；仅在判断分解时添加 planning-granularity.md
审计原生决策结构或生命周期	native-decision-format.md
原生写入后验证或诊断完整的受支持配置文件	通过 profile-validation.md 运行捆绑检查，然后仅为报告的诊断或纠正加载必要的原生引用

不要为只读状态答案预加载格式详细信息。

当配置文件是否存在未知时，先在读取任何规范路径前列出项目根目录。如果 PROJECT_INDEX.md 不存在，不要尝试读取它。对于明确请求的新持久计划，将当前工作空间视为设置根目录，对完整配置文件进行分类，并仅在所有三个规范路径完全不存在时初始化。如果未请求创建，则报告不存在配置文件，而不是隐式初始化一个。保留并停止在部分、外部、不受支持或意图无效的配置上。

维护权威和证据

• 永远不要发明目标、非目标、验收结果、障碍、依赖、证据或已接受的生命周期选择。将实现、普通文档、源代码、静默和当前行为视为证据，而非人类授权。
• 在激活、取消、范围变更、弱化验收、不明确的后续任务或采用仅可能的重要选择之前进行询问。
• 当用户明确选择方向、要求将其保存在项目规则中，或适用的项目指令明确声明了人类选择的方向时，创建并接受相应的决策，无需再次询问。链接每个受影响的可变工作项。
• 当分析仅揭示关于范围、架构、公共行为、存储数据、安全性、依赖、可逆性、验收、迁移或推出的可能重要决策时，将其创建为 proposed，链接每个受影响的可变工作项，报告其建议、替代方案、权衡和实际影响，然后要求用户接受、拒绝或修改它。在此回答之前不要接受它。
• 请求起草提案会创建 proposed。记录所述方向的明确选择授权其接受。在没有该明确生命周期选择的情况下，永远不要拒绝、弃用或取代决策。
• 在项目工作开始时，盘点决策前言，阅读每个提案，报告其 ID、标题、建议选择及实际影响，并要求用户接受、拒绝或修改它。在交接时重复未解决的提案。只有依赖工作会停止。
• 仅在观察到其验收结果并添加简洁证据后，将工作项标记为 done。文件形状检查仅证明结构。
• 将失败或部分工作保持为 in_progress、paused 或显式阻塞。

保持行为完整的工作项

• 最多保持一个工作项为 in_progress，等于 current_item。这限制了并发执行；并不限制计划的总工作项数量。
• 将具有不同验收边界、依赖、所有者或推出时机的独立可恢复结果拆分为单独的工作项。
• 在可选的步骤内部保留实现顺序。测试、审查、文档和发布检查属于验收或证据，除非独立请求的可交付成果需要其自身的可恢复结果。
• 仅在项目为 todo 时更改创作的内容或排序。项目开始后，保留其起始方法并仅更新活动状态。
• 保持 Next action 等于尚未执行的第一个具体操作。一旦存在实现，将其推进到下一个未观察的测试、构建、浏览器检查、审查或评估者拥有的验证。
• 仅在其依赖项完成且后续项明确时选择新的当前工作。仅当完成和确切替换开始都有效作为一个准备好的结果时，才使用 complete_and_advance。
• 当最终实际工作完成时，完成其工作项和计划，并将项目索引设置为空闲。永远不要仅仅为了保持活跃而发明后续项。

原生且狭窄地工作

在写入之前，确认项目根目录、受支持格式、活动计划、当前工作项、影响的字节、可观察结果和验收证据。使用上下文相关的补丁并保留不相关的工作。在应用任何成员之前准备完整的多文件更改，同时承认直接编辑不是原子的。

写入后：

1. 重新读取每个更改的规范文件；
2. 检查完整的作用域差异；
3. 检查索引所有权、活动计划计数、当前项状态、工作项键顺序、依赖顺序和循环、决策和计划引用、障碍、生命周期字段、证据和 Next action；
4. 当其脚本和 Python 已可用时，通过 profile-validation.md 运行捆绑的可选验证器，否则执行并报告作用域手动检查；以及
5. 仅记录观察到的验收证据。

在遇到不受支持格式、并发更改、不明确的生命周期权威、修复会改变意图的无效状态，或部分的多文件转换时停止。不要将问题覆盖成表面上的有效性。

报告持久状态

以当前计划成果开头。点名已更改的规范文件、活动和阻塞的工作、观察到的检查、记录的证据、未解决的重要选择以及下一个具体操作。区分原生结构检查和行为验证。不要叙述常规的文件操作。