$npx -y skills add stevesolun/ctx --skill writing-fragmentsGrilling session that mines the user for fragments — heterogeneous nuggets of writing (claims, vignettes, sharp sentences, half-thoughts) — and appends them to a single document as raw material for a future article. Use when the user wants to develop ideas before imposing structu
| 1 | <what-to-do> |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | If the user did not pass a path, ask once where to save the document, then remember it for the rest of the session. |
| 8 | |
| 9 | Capture fragments from the very first thing the user says, including the initial prompt. |
| 10 | |
| 11 | 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. |
| 12 | |
| 13 | </what-to-do> |
| 14 | |
| 15 | <supporting-info> |
| 16 | |
| 17 | ## What is a fragment |
| 18 | |
| 19 | 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?" |
| 20 | |
| 21 | Fragments are deliberately heterogeneous. Examples of what could be a fragment: |
| 22 | |
| 23 | - A sharp sentence you'd want to deploy somewhere but don't yet know where. |
| 24 | - A claim with a one-line justification. |
| 25 | - A vignette: a thing that happened, a code snippet, a scenario, an analogy. |
| 26 | - A half-thought: "something about how X feels like Y, work this out later." |
| 27 | - A quote, a piece of dialogue, an overheard line. |
| 28 | - A list of related observations that hang together by feel. |
| 29 | - A complaint, a confession, a punchline. |
| 30 | |
| 31 | The novelist's diary is the model: years of unstructured noticings that later get mined for raw material. Fragments are noticings. |
| 32 | |
| 33 | ## File format |
| 34 | |
| 35 | ```markdown |
| 36 | # Working title |
| 37 | |
| 38 | A first fragment lives here. |
| 39 | |
| 40 | It can be multiple paragraphs. It can include lists, code, quotes — whatever |
| 41 | shape the fragment naturally takes. |
| 42 | |
| 43 | --- |
| 44 | |
| 45 | A second fragment. |
| 46 | |
| 47 | --- |
| 48 | |
| 49 | > A quoted line that the user wants to keep around. |
| 50 | |
| 51 | A reaction to it. |
| 52 | |
| 53 | --- |
| 54 | |
| 55 | - A cluster of related observations |
| 56 | - That hang together by feel |
| 57 | - And want to be near each other |
| 58 | ``` |
| 59 | |
| 60 | Fragments are separated by a horizontal rule (`\n---\n`). No headings inside the body. No tags. No order beyond the order they were added. |
| 61 | |
| 62 | ## Writing rhythm |
| 63 | |
| 64 | 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. |
| 65 | |
| 66 | 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). |
| 67 | |
| 68 | The user can say "cut the last one", "rewrite that one sharper", "merge those two" at any time. Treat those as first-class instructions. |
| 69 | |
| 70 | </supporting-info> |