Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mattpocock/writing-beats
Writing, exploit; assemble raw material into a journey of beats, grounding each term before a beat leans on it.
Passed 7 of 15 test cases with the skill, and 3 of 15 without it.
and 6 more in the full report
6 fixed5 passed either way12 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
I want to include a beat on mapped types in `articles/type_level_ts.md` from `notes/ts.md`, but mapped types haven't been grounded yet. What are the two valid ways to handle this ungrounded requirement?
| Checked | Without skill | With skill |
|---|---|---|
| States that adding a grounding beat prior to the desired beat is a valid resolution. | Passed | Passed |
| States that promoting the concept to a prerequisite audience concept is a valid resolution. | Missed | Passed |
The instructions your model reads when the skill loads.
The user has passed (or will pass) a markdown file of raw material. This is exploit: the exploring is done, the pile is fixed. Commit to a path through it and mine the pile to fill each beat.
If the user did not say where to save the article, ask once and remember the path.
Then run a beat-by-beat journey, choose-your-own-adventure style:
Every concept has to be grounded before a beat can lean on it: the audience either walked in knowing it or met it in an earlier beat. A beat that reaches for an ungrounded concept loses the reader; that is the one move the journey can't make. The unit is the concept, not the word for it: a beat can lean on an idea the reader lacks even with no jargon in sight. Where a concept has a name (a term), grounding it means landing the idea and the term together.
A concept gets grounded one of two ways:
So each beat does two jobs: it requires concepts that are already grounded, and it grounds new ones. Keep a running list of what's grounded so far, and update it each time a beat lands.
This is what shapes the choose-your-own-adventure. A candidate beat is only reachable if everything it requires is already grounded; picking a beat that grounds concept X unlocks every beat that was waiting on X. When you offer next beats, they must all be reachable from the current grounded set, and say what each one grounds, so the user can see which paths it opens.
The big lever is what you make a prerequisite versus what you ground inside the piece. Demand too much up front and you shut out readers who don't have it; ground too much inside and the early beats drown in definitions. Settle this with the user when you establish prerequisites, and revisit it whenever a tempting beat turns out to require a concept nothing has grounded yet: the fix is either a grounding beat before it, or promoting the concept to a prerequisite.
A beat is one move in the journey. It does one thing: sets a scene, lands a point, asks a question, drops an aside, twists the angle. Then it stops, leaving the reader at a place where the next beat can pivot.
A beat is sized by what it needs:
test cases passed, vs 3 / 15 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.