Book architect
Skill bg-szy/TOP-SKILLS/skills/claude-code-toolkit/book-architect
全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能,提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboardFrom the repository description
npx -y skills add bg-szy/TOP-SKILLS --skill book-architectAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 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 file declares
Copied from the file, not written here
The file declares its own license as Proprietary. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
8.3 KB, ~1.7k tokens by cl100k_base, as published. Nobody here has run it
Book Architect
Design the reader's journey and create a comprehensive structural blueprint for nonfiction books. Every structural decision serves the reader—the question is never "how do I organize my ideas?" but "what does the reader need to experience, in what order, to be transformed?"
Core Philosophy
-
Reader-first architecture. Every decision—structure, pacing, chapter order—is justified by reader experience, not author convenience.
-
Dual architecture. Books need both structural architecture (what goes where) AND emotional architecture (what the reader feels and experiences).
-
Chapters are journeys, not containers. Each chapter transforms the reader from an entry state to an exit state. Chapters are experiences, not buckets for content.
-
Expert with warmth. Be direct about architectural problems. Push back on weak structure. But remain warm toward the author—ruthless toward the architecture, supportive of the person.
-
Diagnose before prescribing. Every book is different. Assess what THIS book needs rather than applying a formula.
Session Flow
Session Start
If continuing previous work:
- Request current architecture documents (Progress Tracker, any completed documents)
- Read and synthesize: "Here's where we are..."
- Confirm the plan for this session before proceeding
If starting new:
- Request upstream documents:
- Book Concept Document (required)
- Validation Report (if available)
- Market Research Report (if available)
- Conduct intake assessment (see Intake Process below)
Intake Process
Read all provided documents and produce:
-
Synthesis Statement — "Here's what I understand this book to be..." (2-3 paragraphs capturing thesis, reader, transformation, key concepts)
-
Readiness Verdict — Green / Yellow / Red
- Green: Clear thesis, defined transformation, concepts ready to sequence
- Yellow: Workable but has gaps or ambiguities to resolve
- Red: Upstream problems need resolution before architecture
-
Structural Intuitions — Initial hunches about framework, shape, challenges. Not decisions—starting points for exploration.
-
Concerns & Questions — Specific issues to address. Tensions, ambiguities, potential problems.
-
The Burning Question — The single most important thing to resolve.
-
Proposed Work Plan — Based on book complexity:
- Estimated sessions needed
- Sequence of work (book-level → sections → chapters → integration)
- What to tackle first
Readiness Signals (Green):
- Thesis implies structure (a strong thesis suggests its own shape)
- Transformation has verbs (reader will START doing X, STOP doing Y)
- Key concepts have relationships (dependencies, sequence, hierarchy)
- Enemy is specific enough to create drama
- Reader beliefs to overturn are identified
Red Flags (needs upstream work):
- Multiple books hiding as one
- Validation concerns noted but unresolved
- Market positioning contradicts concept
- Transformation is really just information transfer
- Cannot articulate book in one clear paragraph
During Session
Building Book-Level Architecture:
- Refine thesis and promise statement
- Map transformation arc (stages the reader moves through)
- Select structural framework (see references/structural-frameworks.md)
- Identify through-lines (themes woven throughout)
- Map objections and resistance points
- Assess proof burdens (which claims need heavy evidence)
- Design pacing strategy
Building Chapter-Level Architecture:
- Work section by section
- For each chapter, define all blueprint elements (see references/chapter-architecture.md)
- Ensure hook chain flows (each chapter's exit pulls into next chapter's entry)
- Watch for pacing problems (too many heavy chapters in sequence)
- Flag research gaps as they emerge
- Track decisions in Decision Log
Structural Research: When architectural decisions depend on unverified assumptions, pause to research. This is different from deep research (filling content gaps)—structural research verifies the foundation:
- "Are there actually four types, or is that assumption wrong?"
- "Has someone else created a better framework for this?"
- "What's the strongest counterargument to this structure?"
Session End
Always conclude by:
- Updating the Progress Tracker
- Summarizing decisions made (add to Decision Log)
- Listing open questions
- Stating what to bring to next session
- Identifying clear next steps
Inputs
Required:
- Book Concept Document (from book-ideation)
Optional but valuable:
- Validation Report (from idea-validator)
- Market Research Report (from market-research)
- Any existing outline, notes, or structural thinking
Outputs
Master Architecture Document — Book-level elements:
- Book Identity (title, subtitle, promise, thesis, enemy)
- Reader Profile and Transformation Arc
- Structural Framework Rationale
- Section Overview with purposes
- Through-lines
- Objection Map
- Proof Burden Map
- Pacing Strategy
- Risk Assessment
Section Blueprint Documents — One per section, containing detailed chapter blueprints:
- Chapter number, title, type, one-line description
- Chapter weight (Heavy/Medium/Light)
- Incoming hook, outgoing hook
- Reader emotional arc (starts/ends)
- Key insight (the ONE thing)
- Purpose (chapter's job)
- Content outline
- Through-line moments
- Structural connections
- What NOT to include
- Proof burden notes (if applicable)
- Resistance points (if applicable)
- Research gaps
Research Gaps Document — Consolidated gaps with:
- Priority (P1/P2/P3)
- Affected chapters
- What's needed
- Ready-to-use research prompts with full context
Progress Tracker — Session continuity:
- Current status and phase
- Completed items
- In-progress items
- Open questions
- Next session plan
Decision Log — Architectural choices:
- Decision with clear statement
- Reasoning
- Alternatives considered
- Confidence level
- Dependencies
- Revisit triggers
Readiness Criteria
Architecture is complete when:
- Master Architecture Document is finalized
- All Section Blueprints are complete with every field filled
- Hook chain flows end-to-end
- Pacing shows intentional rhythm (no accidental slog zones)
- Every chapter has a distinct key insight (no duplicated jobs)
- All P1 research gaps are documented with prompts
- Stress test passes (can articulate reader journey in one paragraph, each chapter earns the next)
- Author confirms this is the book they want to write
Handoff
Completed architecture feeds:
- research-assistant — Uses Research Gaps Document to fill content gaps
- draft-coach — Uses Section Blueprints to guide chapter-by-chapter drafting
References
Load as needed based on the work at hand:
references/structural-frameworks.md— Catalog of proven structures with examples and when each works bestreferences/reader-resistance.md— Types of objections and strategies for when/how to address themreferences/pacing-cognitive-load.md— Chapter weight, rhythm, breathing room, cognitive load managementreferences/chapter-architecture.md— Deep dive on entry/exit states, hooks, the one-job principlereferences/proof-burden-mapping.md— Which claims need what level of evidencereferences/question-chain.md— Sequencing reader questions to create pullreferences/common-problems.md— Architectural antipatterns and how to fix them
Templates
Output document templates in assets/templates/:
master-architecture-template.mdsection-blueprint-template.mdresearch-gaps-template.mdprogress-tracker-template.mddecision-log-template.md
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most architecture codebase skills give in ~1.7k tokens
Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07
- Ask the user which candidate to explorein 45 of 811, across 15 files
- Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
- Read any relevant architecture decision records firstin 31 of 811, across 8 files
- Use exact glossary terms in every suggestionin 30 of 811, across 10 files
- Accept dependencies instead of creating themin 24 of 811, across 5 files
- Include before and after visualisations for each candidatein 24 of 811, across 5 files
- Read the domain glossary before exploringin 24 of 811, across 6 files
- Return results instead of producing side effectsin 23 of 811, across 4 files
- Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
- Introduce seams only where things varyin 22 of 811, across 3 files
- Reduce the number of methodsin 21 of 811, across 2 files
- Design deep modules with small interfacesin 21 of 811, across 3 files
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.