writing-fragments
- 信任分
- 88/100
- 兼容 Agent
- 1
- 领域
- AI 智能
- 兼容 Agent
- Claude Code
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @mattpocock · 未声明 license
- 安装命令数
- 1 条
需要注意： 未限定 allowed-tools，默认拥有全部工具权限。
想读作者英文原文？ ↓ 滚到正文区切换 · 在 GitHub 查看 ↗
writing-fragments 是写作的「前 0 阶段」：跑一场无情的 grilling session，把对话两边浮现的 fragment 一条接一条 append 到一份 markdown 文件——不立大纲、不分阶段、不强求结构，那些都明确是 out of scope。
设计思路
作者借用小说家日记的模型：多年无组织的 noticings，将来被矿掘出来当原料。fragments 就是 noticings——是作者读得懂的小段，但不要求对冷读者自洽，标准是「这是不是一段好写作？」而非「这是不是一个完整论点？」。
什么是 fragment
- 一个尖锐的句子，你想用但还不知道用在哪
- 一条 claim 配一行佐证
- 一个 vignette：发生了什么、一段代码、一个场景、一个类比
- 一个半成想法：「something about how X feels like Y, work this out later.」
- 一句引文 / 一段对白 / 偶然听到的话
- 一组靠"感觉"挂在一起的相关观察
- 一句牢骚 / 一句自白 / 一个 punchline
文件格式
头部一个 H1 working title（可改），其下 fragment 用 --- 分隔，body 里不放 heading、不打 tag、不强制顺序——只按写下来的顺序排。
工作流
① 没传 path 就问一次记下；② 第一次写时只放 H1 working title；③ 从用户第一句话起就开始捕捉 fragment（包括最初的 prompt 本身也算）；④ session 中默默 append——不每次问要不要 append；用户在编辑这份文件，你写之前必须 re-read保留他改过的部分。
关键纪律
- 不要造结构——不立大纲、不写过渡、不挑顺序
- 不要解释——fragment 是 noticing，不是 essay
- 不要替用户想该说什么——逼他说出更具体的，而不是替他平滑
- 同一句话两个版本同样有价值：保留两条，让用户选时再合
适合的场景
- 一个 idea 还在脑子里转、没想清楚要写成什么文章时
- 长 session 里随手攒线索，将来
writing-shape或writing-beats用作原料 - 与 grilling 类技能（
grill-with-docs/grill-with-architecture）配合做 deep dive
何时不要用
- 已知要写一篇结构化文章：直接进
writing-shape或writing-beats - 你需要的是规约 / spec / PRD：fragment 不会给你那种自洽
配套
writing-shape / writing-beats（fragment 之后两条不同长成方式）、writing-skills（写作语调）、grill-with-docs（grilling 的另一种走法）、ubiquitous-language（fragment 里术语锚定）。
Run a grilling session that produces fragments. Interview the user relentlessly about whatever they want to write about. Do not impose phases, outlines, or structure — that is explicitly out of scope.
As fragments emerge from either side of the conversation, append them to a single markdown file. The user will be editing this file during the session; always re-read it before writing so their edits are preserved.
If the user did not pass a path, ask once where to save the document, then remember it for the rest of the session.
Capture fragments from the very first thing the user says, including the initial prompt.
On first write, put a single H1 at the top with a working title (it can change later) and nothing else — no metadata, no TOC, no date.
What is a fragment
A fragment is any piece of text that might survive into the final article. It must be readable by the author — the author can tell what it means — but it does not need to define its terms or be comprehensible to a cold reader. The bar is "is this a piece of good writing?", not "is this a self-contained argument?"
Fragments are deliberately heterogeneous. Examples of what could be a fragment:
- A sharp sentence you'd want to deploy somewhere but don't yet know where.
- A claim with a one-line justification.
- A vignette: a thing that happened, a code snippet, a scenario, an analogy.
- A half-thought: "something about how X feels like Y, work this out later."
- A quote, a piece of dialogue, an overheard line.
- A list of related observations that hang together by feel.
- A complaint, a confession, a punchline.
The novelist's diary is the model: years of unstructured noticings that later get mined for raw material. Fragments are noticings.
File format
# Working title
A first fragment lives here.
It can be multiple paragraphs. It can include lists, code, quotes — whatever
shape the fragment naturally takes.
---
A second fragment.
---
> A quoted line that the user wants to keep around.
A reaction to it.
---
- A cluster of related observations
- That hang together by feel
- And want to be near each otherFragments are separated by a horizontal rule (\n---\n). No headings inside the body. No tags. No order beyond the order they were added.
Writing rhythm
Append silently. Don't ask permission for each fragment. Mention what you added in passing ("adding that"), but don't interrupt the conversation with save dialogs.
Before every write: re-read the file from disk. The user may have edited, reordered, or deleted fragments between turns — preserve their changes. Never overwrite the file; only append (or, if the user asks, edit a specific fragment in place).
The user can say "cut the last one", "rewrite that one sharper", "merge those two" at any time. Treat those as first-class instructions.