<what-to-do>
This is pure **explore**: of what could be written without . Committing is _exploit_, a separate skill's job. Run a grilling session that produces fragments, about whatever they want to write about. Imposing phases, outlines, or article structure is out of scope here.
As fragments emerge , append them to a single markdown file.
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 , including the initial prompt.
On first write, put a single H1 at the top with (it can change later) and nothing else: no metadata, no TOC, no date.
</what-to-do>
<supporting-info>
## What is a fragment
A fragment is any piece of text that might . 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 . 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 .
- A complaint, a confession, a punchline.
- A **leading word**: a compact metaphor or coinage (one term that names the idea, the way _tracer bullets_ or _fog of war_ names a whole pattern).
Of these, the leading word is the most valuable fragment to land. It is : name the right one in explore and it shapes the structure, the transitions, and the title later, through the entire exploit phase. When the conversation circles a recurring idea, push to coin a word for it.
The novelist's diary is the model: years of unstructured noticings that later get mined for raw material. Fragments are noticings.
## File format
```markdown
# 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
- And want to be near each other
```
Fragments 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
. 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, so 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 .
</supporting-info>