writing-beats
写作的 exploit 阶段——把原始材料组织成由 beats 构成的旅程,并在后续 beat 使用某个术语前先完成 grounding。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
写作的 exploit 阶段——把原始材料组织成由 beats 构成的旅程,并在后续 beat 使用某个术语前先完成 grounding。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
使用并行 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 以来的变更”时。
| 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。这很正常;准备多于所需的原始材料,本来就是它的意义。