其他
在不丢失规则含义的前提下改写政策、计划与模板
当用户要求简化政策或计划措辞、治理产物需要指定语气、缩短时必须保留每个条款，或包需要基线、账本、改写和证明时使用。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 35/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 38/100 ×0.15
适用场景
在不丢失规则含义的前提下改写政策、计划与特定
解决思路
- 在使用此处命名的包文件前，运行 `mise run validate`。
- 在同时更改技能包或依赖宿主写作政策的工作前，阅读 `references/dependency-reconciliation.md`。
- 将条款级含义和语气保留在本技能职责内；若安装了包简化同级工具，则由该同级工具负责包模式与解构。
- 如果不存在等价所有者，保持包边界不变。
- 不要编造缺失依赖，也不要为避免依赖而弱化某个分支。
- 在 Writing standard 中，使用此处命名的包文件前，运行 `mise run validate`。
- 以结果或规则开头。
- 使用常见词、主动语态和自然缩写。
- 尽可能每条项目只放一条规则。
- 写明负责人、文件、命令、数量或检查。
- 首次使用技术术语时定义它。
- 保留精确路径、命令、哈希、设置名、来源引用、备份和原始输出。
- 用 `must`、`must not`、`may` 或 `prefer` 明确保留需求强度。
- 让例外与其来源一样窄。
- 不要依赖先前对话上下文。
- 避免 em dash 和 en dash 字符、填充词、模糊措辞和润色式收尾。
- 在标题、段落和列表之间保留可读间距。
- 把始终需要的规则放在父文件；仅将分支细节移到适合所有者的链接文件，并添加反向链接。
- 让每个受管控的 Markdown 文件低于其宿主限制；绝不要仅为通过大小限制而移除可读间距。
- 在最终散文扫描前阅读 `references/voice-check.md`。
- 在步骤 1 中，使用此处命名的包文件前，运行 `mise run validate`。
- 阅读实际来源，而不是凭记忆重建。
- 记录每个现有来源的路径、哈希、字节数、行数、标题和模式。
- 将未来路径标记为不存在，而不是编造其哈希。
- 将每个现有目标复制到仅所有者可访问的备份，并证明字节一致。
- 当来源和仓库状态影响改写时，记录它们的状态。
- 遇到无法解释的来源漂移时停止。
- 使用 `references/baseline-and-ledger.md` 了解字段和检查。
- 为每个来源条款分配稳定 ID。
- 当段落包含多条规则时拆分它。
- 为每个条款记录来源、精确文本、含义、需求强度、目标位置、替换内容、操作和评审状态。
- 仅允许操作 `keep`、`split`、`move`、`clarify`；绝不使用 `drop`。
- 添加每条新语气规则，以及同一语气适用于每个计划产物的规则。
- 在生成的账本中保持 map 和 tuple 形状一致。
- 在步骤 3 中，使用此处命名的包文件前，运行 `mise run validate`。
- 当改写声称完整覆盖官方文档或基础原语时，在写作前盘点当前官方来源集。
- 不要信任过时快照，也不要编造页面。
- 遵循 `references/docs-inventory.md`。
- 保留每个已接受含义及其需求强度。
- 把始终需要的规则保留在父产物中。
- 仅将分支特定细节移到适合所有者的链接文件。
- 每个过程只保留一个规范所有者。
- 每次措辞或章节变更后更新账本目标。
- 将实际文件与备份做 diff，并把每个实质块关联到账本 ID。
- 在步骤 5 中，使用此处命名的包文件前，运行 `mise run validate`。
- 检查完整账本覆盖、唯一 ID、允许操作、已批准评审状态和精确目标存在性。
- 检查行数和字符限制、链接、上下文加载、哈希、模式和密钥安全。
- 只对散文检查语气；跳过必须保持精确的引用、备份、原始输出、行内代码和代码围栏。
- 完整回读并确保语法清楚。
- 确保人工报告和机器报告一致。
- 分离组件结果和整体变更状态。
- 绝不要在混合散文和代码中全局替换缩写或标点；只修补精确的散文出现处，然后重新检查附近代码和语法。
- 将临时验证器放在操作系统临时位置，并在使用后删除。
- 将聚焦探针标记为 ad hoc，而不是 suite green。
- 使用 `references/validation-contract.md` 处理评审包和收尾。
- 如果等待独立评审者会阻止已授权的主要工作，且没有外部规则要求独立评审，则在主 worker 中运行相同检查，并将结果标记为非独立。
- 仅当每个来源条款都有已批准映射且没有操作是 `drop` 时返回 `PASS`。
- 仅当每个替换保留来源含义、范围、例外和强度时返回 `PASS`。
- 仅当基线和备份哈希仍匹配时返回 `PASS`。
- 仅当每个链接目标存在且匹配账本时返回 `PASS`。
- 仅当语气、语法、安全和包检查通过时返回 `PASS`。
- 不要把组件结果呈现为整体变更证明。
- 确保临时验证文件已删除。
- 当有界组件证明通过但整体阈值未完成时，使用 `PARTIAL`。
- 当来源漂移、缺少权限、证据不可访问或依赖未解决导致无法安全改写时，使用 `BLOCKED`。
- 不要对尚不存在的路径做哈希。
- 不要遗漏来源项目或窄例外。
- 不要用模糊摘要替换精确规则。
- 措辞修复后不要留下过时账本文本。
- 不要把检查器数据或行内代码当作散文扫描。
- 不要通过整文件清理破坏代码示例。
- 不要把组件 `PASS` 报告为整体变更 `PASS`。
- 当主 worker 执行了评审时，不要声称独立评审。
- 不要留下临时构建器或过时评审包。
- 使用 `assets/meaning-ledger-template.json` 作为字段模板。
- 阅读 `examples/policy-rewrite.md`、`examples/blocked-drift.md` 或 `examples/package-reconciliation.md` 查看可见运行。
- 包维护者使用 `references/`、`mise run test` 和 `evals/`，然后运行 `mise run ci`；普通改写不加载这些路径。
- 按验收结果执行：用平实语言改写文本，同时保留每个已命名含义不变量，并记录语义损失检查；在改变当前含义不变量行为时，只改动其最小所有者。
- 用 `mise run ci` 冻结当前包并记录摘要。
- 运行 `mise run domain-research-policy`，然后判断当前含义不变量来源和反证。
- 为已命名含义不变量操作运行 `mise run agentic-request`；将语义选择留给模型。
- 运行 `mise run decision-policy`、`mise run ci` 和行为评估；返回到最低的失败所有者。
- 运行 `mise run invocation-policy -- <receipt>`，并说明每个任务或其领域特定未使用。
- 可选运行 `mise run improvement-policy`；仅在没有受保护维度回退时保留一个已更改维度。
- 仅在需要其契约时，通过 `mise run use-case-policy` 加载 `assets/use-case-contract.json`，并通过 `mise run evals` 加载 `evals/evals.json`。
- Mise 负责可重复机制、顺序、收据和检查；模型负责解释、因果判断、创造性工作以及代码无法提供的直接感知。
- 遇到缺少权限、过时证据或失败门时停止。
适用边界 · 注意事项
- 普通代码重构。
- 允许省略细节的例行摘要。
- 一次性创意文案。