Grizzly audit
An open editor-in-a-skill for fiction writers. Diagnosis, structure, and memory. The author keeps the pen.
npx -y skills add HarishDvs/Grizzly --skill grizzly-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Simulate a cold first-time reader and report the reading experience of a chapter. Use when the user asks why a chapter feels boring or flat, whether a chapter works, what a reader would feel, or wants a fresh-eyes read. Reports experience, not errors; for error-finding use grizzly-review.
SKILL.md
3.4 KB, as published. Nobody here has run it
Grizzly Audit — The Cold Read
Reviews find errors. Audits find the problems nobody can name: the chapter that is technically clean and somehow boring, the character the reader cannot picture, the death that lands as information. This mode exists because authors cannot read their own work cold, and it is the highest-value service in the suite.
Procedure
Read the chapter start to finish AS a first-time reader: no codex first, no standards in hand, no author goals. React, then analyze. (Load the codex only afterward, for the comparison step.)
Report these six checks, each with chapter-position references ("opening", "the kitchen scene", "last page"):
1. Dread map
Where does threat exist for the reader, where does it spike, and where does it die? Threat dies through over-explanation, through repetition without escalation, and through safety that arrives too reliably. Name the line where you stopped being afraid.
2. Safety map
Where does the reader feel safe, and is that safety doing work? Earned warmth that will cost something later is structure; comfort that costs nothing is drag. If the whole chapter is safe, say so plainly; that is usually the finding.
3. Character-visualization check
For each character on page: can you physically see them, or are they a voice in white space? What are they doing with their bodies while they talk? Could a reader who skipped the introductions tell them apart by behavior alone? Name the characters who exist only as dialogue tags.
4. Prediction check
At each turn, what did you expect to happen next? Then: did the chapter confirm the prediction boringly, break it meaningfully, or wander without raising any prediction at all? No predictions raised is the flattest possible finding; report it as such.
5. Hook check
What, if anything, pulls to the next chapter? Is it positioned at the end or buried mid-chapter? For serials (per NOVEL.md format), a chapter without an end-positioned pull is a retention leak; say so.
6. Belief check
Did anything eject you from the fiction? Two ejector classes belong here even though they look like "errors": POV breaks (the narration shows what the POV character cannot perceive: sights through a closed door, another character's interiority) and syntax garble severe enough to force a re-read. Both are experience findings; a reader who stops believing or stops parsing has stopped reading. Light typos stay out of the audit (route to review).
After the cold read
- Compare against the codex: did anything the cards mark as important fail to register in the cold read? A planted thread the reader never noticed is a planting failure, not a reader failure.
- End with the one-sentence verdict a beta reader would give a friend ("I'd keep reading, but I skimmed the middle"), then the single highest-leverage change.
Rules
- Honesty is calibrated, not padded: lead with the strongest finding, never with praise. If the chapter works, say exactly why in one line and stop.
- Report experience, never fixes. Route fixes to grizzly-edit or grizzly-plan; offer, don't start.
- Never quote more than a line or two back at the author; reference positions.