writing-flow
Skill1 starsChanged 5 months agoMITView on GitHub
A 3-step writing flow inspired by Matt Pocock. Each step is its own slash command and is "extremely demanding for the user" — you get grilled three different ways. Use whenever the user wants to write something where voice and structure matter more than speed: essays, blog posts, newsletters, opinion pieces, talks, long-form documentation, marketing copy that needs to sound human, even fiction.
In this repository24 other files it gives its agents.
- api-designSkill
- brainstormingSkill
- councilSkill
- dispatching-parallel-agentsSkill
- document-toolkitSkill
- executing-plansSkill
- gui-input-automationSkill
- humanizeSkill
- hyprland-controlSkill
- incremental-implementationSkill
- issue-to-prSkill
- litreviewSkill
- mcp-builderSkill
- rust-reviewSkill
- screen-captureSkill
- session-handoffSkill
- shadcn-auditSkill
- spec-to-issuesSkill
- subagent-driven-developmentSkill
- teachSkill
- unslopSkill
- using-git-worktreesSkill
- visual-computer-use-loopSkill
- writing-plansSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 53
If you're not sure, ask one question: "Is voice or structure the thing that matters here?" If yes, this skill.
- Very specific: line 59
No fragments yet → /fragments.
- Distinctive: line 63
If the user is somewhere in the middle and unsure, ask: "Do you have raw fragments yet, a draft, or nothing?" — and route from there.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Writing-flow — a 3-step writing process
A workflow for AI-assisted writing that mimics how serious writers actually work: lots of disconnected raw material, then deliberate assembly, then ruthless editing. Novelists do it with diaries; essayists do it with notebook scraps; technical writers do it with bulleted brain-dumps. The shape is the same.
Why this exists
The smart zone for AI-assisted coding is roughly 100K tokens. The smart zone for AI-assisted writing is much smaller — quality starts dropping around 50K tokens. Models start making dumb voice and structural choices long before they run out of context.
The fix is not a longer context window. The fix is splitting the work into three short, fresh-context passes — each one demanding enough on the user that the output stays in their voice instead of regressing to AI mush.
The three steps
| # | Command | What it does | Output |
| 1 | /fragments | Grills the user until they produce voice-true fragments in their own words. AI may propose sharpened phrasings; only the user's pick is committed verbatim. | fragments.md |
| 2 | /walk | Walks a path through fragments.md beat-by-beat. Marks invented sentences with [+]. Grills the user before locking each beat. | draft.md |
| 3 | /polish | Runs four ordered passes (contradictions, repetition, structure, links) and grills on every issue. Subtractive only — never adds content. | final.md |
Hard rule between steps: clear context. Each command refuses to start unless the conversation is in a fresh window. Editorial judgment rots fast as context fills.
When to invoke this skill
Trigger when the user wants to write something and voice or structure matters. Strong signals:
- "Help me write [an essay / a post / a piece / a talk / a chapter]."
- "Let's start something" or "I want to draft X."
- "Get me grilled on this" or "fragments → walk → polish."
- The piece is more than a few paragraphs and the user cares how it sounds.
Skip for:
- One-off replies, comments, or short blurbs where speed beats voice.
- Pure reference docs (API references, config schemas) where there is no voice to preserve.
- Editing already-finished prose — use
humanizefor cleanup.
If you're not sure, ask one question: "Is voice or structure the thing that matters here?" If yes, this skill. If no, just write directly.
How to start
Route based on what already exists in the working directory:
- No fragments yet →
/fragments. fragments.mdexists, fresh context window →/walk.draft.mdexists, fresh context window →/polish.
If the user is somewhere in the middle and unsure, ask: "Do you have raw fragments yet, a draft, or nothing?" — and route from there.
What this skill will not do
- Will not run all three steps in one session. The context-clear is load-bearing.
- Will not commit fragments in the AI's own words. The AI may propose sharpened phrasings, but only what the user picks (or rewrites) is saved.
- Will not invent citations, links, or sources during polish.
- Will not promise this is faster than writing without AI. It probably isn't. The promise is higher quality and less frustration.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.