Book TOC Lab
Treat a useful nonfiction book as a problem-solving product for a specific
reader. The table of contents is the product design, not a decorative outline.
Build and test the promise, scope, recommendation loop, and TOC before drafting
so the manuscript has a clear job and useful progression.
Use this skill to produce or improve a book plan that answers:
- Who is this book for?
- What painful or valuable problem does it help them solve?
- What should be different for the reader after each chapter?
- What does the book deliberately leave out?
- Why would a satisfied reader recommend it to a specific person in a specific
situation?
Resource Routing
Load only the files needed for the task:
| Need |
Read |
| Core model, DEEP, promise, scope, recommendation loop |
references/core/knowledge.md |
| Concrete planning and validation rules |
references/core/rules.md |
| Before/after examples for scope and TOC titles |
references/core/examples.md |
| Quick planning and review checklist |
references/core/checklist.md |
| Step-by-step TOC design before drafting |
workflows/design-toc.md |
| Step-by-step TOC validation with readers |
workflows/validate-toc.md |
Fast Workflow
- Lock the reader promise before outlining.
- Define in-scope, out-of-scope, prerequisites, and depth lines.
- Write the recommendation story: trigger, recommender, recommended reader, and
why this book is the obvious fit.
- Draft chapters as reader takeaways, not author topic buckets.
- Order chapters by reader progress: orientation, foundation, action, judgment,
and integration.
- Pressure-test every chapter against the promise, reader outcome, missing
steps, boredom risk, confusion risk, skepticism, and recommendability.
- Validate the TOC before drafting when practical.
Output Format
When asked to create or improve a TOC, return:
- Book brief: reader, problem, promise, scope, out-of-scope.
- Recommendation story: trigger, recommender, recommended reader, why this book.
- Recommended TOC with chapter-level reader problems and takeaways.
- Reader journey notes explaining the order.
- Risk list: missing prerequisites, vague chapters, likely confusion, likely
boredom.
- Validation plan: 3-7 concrete ways to test the TOC before drafting.
Quality Bar
A good TOC should feel useful even before the book exists. A reader should be
able to scan it and understand what the book helps them accomplish, whether it
is for them, and why the chapter sequence makes sense.
Do not optimize for literary cleverness before usefulness. Clever titles are
acceptable only after the reader promise and chapter takeaways are obvious.
1---2name: book-toc-lab3description: Design and pressure-test useful nonfiction book promises, scopes, recommendation loops, and takeaway-first tables of contents before drafting. Use when planning, outlining, scoping, restructuring, validating, or testing a practical book, guide, manual, course-like book, or other reader-outcome-focused long-form nonfiction.4license: MIT5---67# Book TOC Lab89Treat a useful nonfiction book as a problem-solving product for a specific10reader. The table of contents is the product design, not a decorative outline.11Build and test the promise, scope, recommendation loop, and TOC before drafting12so the manuscript has a clear job and useful progression.1314Use this skill to produce or improve a book plan that answers:1516- Who is this book for?17- What painful or valuable problem does it help them solve?18- What should be different for the reader after each chapter?19- What does the book deliberately leave out?20- Why would a satisfied reader recommend it to a specific person in a specific21 situation?2223## Resource Routing2425Load only the files needed for the task:2627| Need | Read |28| --- | --- |29| Core model, DEEP, promise, scope, recommendation loop | `references/core/knowledge.md` |30| Concrete planning and validation rules | `references/core/rules.md` |31| Before/after examples for scope and TOC titles | `references/core/examples.md` |32| Quick planning and review checklist | `references/core/checklist.md` |33| Step-by-step TOC design before drafting | `workflows/design-toc.md` |34| Step-by-step TOC validation with readers | `workflows/validate-toc.md` |3536## Fast Workflow37381. Lock the reader promise before outlining.392. Define in-scope, out-of-scope, prerequisites, and depth lines.403. Write the recommendation story: trigger, recommender, recommended reader, and41 why this book is the obvious fit.424. Draft chapters as reader takeaways, not author topic buckets.435. Order chapters by reader progress: orientation, foundation, action, judgment,44 and integration.456. Pressure-test every chapter against the promise, reader outcome, missing46 steps, boredom risk, confusion risk, skepticism, and recommendability.477. Validate the TOC before drafting when practical.4849## Output Format5051When asked to create or improve a TOC, return:52531. Book brief: reader, problem, promise, scope, out-of-scope.542. Recommendation story: trigger, recommender, recommended reader, why this book.553. Recommended TOC with chapter-level reader problems and takeaways.564. Reader journey notes explaining the order.575. Risk list: missing prerequisites, vague chapters, likely confusion, likely58 boredom.596. Validation plan: 3-7 concrete ways to test the TOC before drafting.6061## Quality Bar6263A good TOC should feel useful even before the book exists. A reader should be64able to scan it and understand what the book helps them accomplish, whether it65is for them, and why the chapter sequence makes sense.6667Do not optimize for literary cleverness before usefulness. Clever titles are68acceptable only after the reader promise and chapter takeaways are obvious.
LVTD-LLC