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.
Source: hashgraph-online/awesome-codex-plugins → plugins/LVTD-LLC/skills/skills/book-toc-lab/SKILL.md
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.4---5
6
7# Book TOC Lab
8
9Treat a useful nonfiction book as a problem-solving product for a specific
10reader. The table of contents is the product design, not a decorative outline.
11Build and test the promise, scope, recommendation loop, and TOC before drafting
12so the manuscript has a clear job and useful progression.
13
14Use this skill to produce or improve a book plan that answers:
15
16- 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 specific
21 situation?
22
23## Resource Routing
24
25Load only the files needed for the task:
26
27| 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` |
35
36## Fast Workflow
37
381. 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, and
41 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, missing
46 steps, boredom risk, confusion risk, skepticism, and recommendability.
477. Validate the TOC before drafting when practical.
48
49## Output Format
50
51When asked to create or improve a TOC, return:
52
531. 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, likely
58 boredom.
596. Validation plan: 3-7 concrete ways to test the TOC before drafting.
60
61## Quality Bar
62
63A good TOC should feel useful even before the book exists. A reader should be
64able to scan it and understand what the book helps them accomplish, whether it
65is for them, and why the chapter sequence makes sense.
66
67Do not optimize for literary cleverness before usefulness. Clever titles are
68acceptable only after the reader promise and chapter takeaways are obvious.
69
70---
71
72**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/LVTD-LLC/skills/skills/book-toc-lab/SKILL.md`
thedixitjain