chapter-review
Skill0 starsChanged 7 months agoMITView on GitHub
Review a drafted chapter for narrative, stylistic, and structural problems once a chapter exists and the project has enough persisted context to judge it against the intended outline, voice, and character logic.
In this repository27 other files it gives its agents.
- beta-reader-passSkill
- build-distributionSkill
- continuity-checkSkill
- create-character-bibleSkill
- define-style-bibleSkill
- draft-chapterSkill
- generate-high-level-outlineSkill
- if-design-dialogueSkill
- if-design-mapSkill
- if-design-progressionSkill
- if-design-structureSkill
- if-draft-inkSkill
- if-init-projectSkill
- if-load-contextSkill
- if-plan-ink-sliceSkill
- if-playtest-reviewSkill
- if-sync-stateSkill
- ink-docSkill
- init-story-projectSkill
- load-story-contextSkill
- manuscript-reviewSkill
- plan-chapterSkill
- prepare-exportSkill
- rewrite-chapterSkill
- sync-story-bibleSkill
- update-character-stateSkill
- update-timelineSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 17 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈17
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
Use this skill to perform an editorial review of a drafted chapter and leave actionable feedback in the project files.
- Distinctive: line 14
Use this skill when:
- Distinctive: line 22
Do not use this skill to write the chapter itself.
- Distinctive: line 35
Ask questions only when the target chapter or desired review focus is genuinely unclear.
- Distinctive: line 44
Read these when present and relevant:
- Distinctive: line 64
If the project already uses a slightly different filename pattern for chapter reviews, follow the existing convention rather than forcing a …
- Very specific: line 70
Read story.language before writing the review file.
- Distinctive: line 71
Keep file and folder names in English.
- Distinctive: line 72
Write the review content in the selected story language.
- Distinctive: line 73
Use correct orthography, accents, and normal Unicode for that language.
- Very specific: line 74
If story.language is missing, gather it before writing.
- Very specific: line 75
If the review file uses a different language than story.language, flag the mismatch and resolve it deliberately.
- Distinctive: line 79
Read the draft chapter completely before judging details.
- Distinctive: line 80
Read the minimum relevant project context so the review reflects intended style, structure, and character logic.
- Distinctive: line 93
Write recommendations that are concrete, prioritized, and non-contradictory.
- Distinctive: line 121
After running the skill, provide:
- Distinctive: line 140
Do not limit the review to generic praise.
- Distinctive: line 141
Do not propose mutually contradictory fixes.
- Distinctive: line 142
Do not rewrite the whole chapter unless explicitly asked.
- Distinctive: line 143
Do not ignore the project's style and outline when evaluating the draft.
≈ “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
Chapter Review
Overview
Use this skill to perform an editorial review of a drafted chapter and leave actionable feedback in the project files. The review should distinguish major problems from minor adjustments and make it clear what to fix next instead of offering vague aesthetic commentary.
When To Use
Use this skill when:
- a chapter draft already exists;
- the user wants feedback before moving to the next chapter;
- the draft needs evaluation for clarity, tension, pacing, voice, dialogue, or structure;
- the agent needs a written review artifact rather than informal chat feedback;
- the project is iterating chapter by chapter with review checkpoints.
Do not use this skill to write the chapter itself. Its job is evaluation and prioritization.
Required Inputs
Gather or infer these inputs:
story.yamlmetadata;- the target chapter draft;
- relevant style files;
- chapter plan or outline context;
- nearby chapter context when transitions matter;
- character files when voice or behavior need verification.
Ask questions only when the target chapter or desired review focus is genuinely unclear.
Files To Read
Always read:
story.yaml05_draft/chapter_XX.md
Read these when present and relevant:
01_style/voice.md01_style/prose_rules.md01_style/pov.md01_style/taboo_list.md01_style/lexical_notes.md02_story/chapter_list.md04_outline/chapter_XX.plan.md04_outline/*- adjacent chapters in
05_draft/ 03_characters/*02_story/open_loops.md
Files To Write
Write or update:
06_review/chapter_XX.review.md
If the project already uses a slightly different filename pattern for chapter reviews, follow the existing convention rather than forcing a new one.
Language Rules
This skill depends on story.yaml as the source of truth for project metadata.
- Read
story.languagebefore writing the review file. - Keep file and folder names in English.
- Write the review content in the selected story language.
- Use correct orthography, accents, and normal Unicode for that language.
- If
story.languageis missing, gather it before writing. - If the review file uses a different language than
story.language, flag the mismatch and resolve it deliberately.
Procedure
- Read the draft chapter completely before judging details.
- Read the minimum relevant project context so the review reflects intended style, structure, and character logic.
- Evaluate the chapter across the dimensions that matter most:
- clarity;
- tension and momentum;
- plot progression;
- character coherence;
- voice and prose control;
- dialogue effectiveness;
- exposition load;
- ending impact;
- alignment with outline and plan.
- Separate major narrative or structural issues from smaller polish issues.
- Identify continuity risks when they surface, but keep the chapter review focused on editorial usefulness.
- Write recommendations that are concrete, prioritized, and non-contradictory.
Output Requirements
The review should include these sections:
- brief chapter summary;
- what works;
- major problems;
- secondary problems;
- detected continuity risks;
- prioritized recommendations;
- recommended next action.
The review must make clear which issues are blocking and which are optional improvements.
Quality Bar
The resulting review should allow another agent or author to answer:
- what is already working in this chapter;
- what the biggest problems are;
- why those problems matter;
- what changes should happen first;
- whether the chapter is ready to continue, revise, or re-plan.
Output
After running the skill, provide:
- a short summary of the review created;
- the top one to three issues found;
- whether the chapter should be revised, re-planned, or can proceed with minor fixes;
- the recommended next step, usually
continuity-checkor a targeted rewrite.
Definition Of Done
This skill is done when:
06_review/chapter_XX.review.mdexists and is usable;- the review clearly prioritizes major versus minor issues;
- recommendations are concrete enough to act on;
- the review respects
story.language; - the chapter's status is clearer than before the review.
Restrictions
- Do not limit the review to generic praise.
- Do not propose mutually contradictory fixes.
- Do not rewrite the whole chapter unless explicitly asked.
- Do not ignore the project's style and outline when evaluating the draft.
Example Invocation
Use $chapter-review to review chapter 7 with focus on tension, clarity, POV control, and the effectiveness of its closing beat.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.

