Menu
写作的 exploit 阶段——把原始材料组织成由 beats 构成的旅程，并在后续 beat 使用某个术语前先完成 grounding。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | writing-beats |
| description | 写作的 exploit 阶段——把原始材料组织成由 beats 构成的旅程，并在后续 beat 使用某个术语前先完成 grounding。 |
| disable-model-invocation | true |
用户已经传入（或将要传入）一份包含原始材料的 Markdown 文件。当前处于 exploit：探索已经结束，材料堆已固定。选定一条贯穿材料的路径，并从材料堆中开采内容，填充每个 beat。
用户没有说明文章保存位置时，只询问一次，并在后续过程中记住该路径。
随后运行一段逐 beat 推进、类似 choose-your-own-adventure 的旅程：
每个 concept 都必须先完成 grounding，beat 才能依赖它：受众可能在进入文章前就已经了解，也可能在更早的 beat 中首次接触。Beat 如果直接使用尚未 grounded 的 concept，就会让读者失去方向；这是这段旅程唯一不能做的动作。判断单位是 concept，而非表示它的词：即使没有出现任何术语，beat 也可能依赖读者尚未掌握的想法。Concept 有名称，也就是一个 term 时，grounding 需要同时落定该想法和术语。
Concept 有两种 grounding 方式：
因此，每个 beat 同时承担两项工作：它要求某些已经 grounded 的 concepts，也会让新的 concepts 完成 grounding。持续维护当前已经 grounded 的清单，每个 beat 落定后都更新一次。
这套机制决定 choose-your-own-adventure 的形状。候选 beat 只有在它所要求的全部 concepts 都已经 grounded 时才可抵达；选择一个让 concept X 完成 grounding 的 beat，会解锁所有等待 X 的 beats。提供 next beats 时，所有候选都必须能够从当前 grounded set 抵达，并说明各自会 ground 什么，让用户看见它将开启哪些路径。
关键取舍在于：哪些 concepts 设为 prerequisite，哪些在文章内部 ground。开头要求太多，会把尚未掌握这些知识的读者挡在门外；文章内部 ground 太多，前几个 beats 会淹没在定义中。确定 prerequisites 时与用户共同决定。每当一个诱人的 beat 需要尚未 grounded 的 concept 时，重新审视这项决定：在它前面加入 grounding beat，或把该 concept 提升为 prerequisite。
Beat 是旅程中的一个动作。它只做一件事：建立场景、落定观点、提出问题、插入旁白、转动视角。随后结束，把读者留在一个后续 beat 可以转向的位置。
Beat 的长度取决于它所需的空间：
一个“beat”如果需要五个段落和三个子标题，它其实是两个粘在一起的 beats。把它拆开。
从原始材料堆中取出内容，填充每个 beat。可以改写、拆分、重新组合或引用。材料堆是一座 quarry。
旅程完成时文章就结束，无须等到材料堆被用空。大多数材料堆都会留下没有进入文章的 fragments。这很正常；准备多于所需的原始材料，本来就是它的意义。
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态，或提到“design it twice”的场景。
运行交互式 QA session：用户通过对话报告 bugs 或 issues，agent 随后创建 GitHub issues；同时在后台探索 codebase，获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues，或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan，并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC，或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary，标出歧义并提出规范术语，保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language，或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点（commit、branch、tag 或 merge-base）开始，从两个维度审查代码变更：Standards 检查代码是否遵守仓库记录的编码规范，Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成，再并列汇报。适用于用户希望审查分支、PR、开发中的改动，或要求“审查自 X 以来的变更”时。
