Git Repo to Book

Write a full-length technical book using multi-agent AI orchestration. Based on the
real workflow that produced The OpenClaw Paradigm
— 88,000+ words, 14 chapters, 42 diagrams in under 18 hours.

Scope & Boundaries

This skill handles:

• - Planning, researching, writing, reviewing, and publishing multi-chapter technical books
• Revising individual chapters of existing books (review → rewrite → re-integrate)
• Orchestrating parallel sub-agents for each phase
• Merging chapters into a polished manuscript with TOC, metadata, and HTML export
• Managing the WORKLOG protocol for agent coordination

This skill does NOT handle:

• - Cover design or artwork generation (use an illustration skill)
• Publishing to Amazon/Kindle/bookstores (output is Markdown + HTML)
• Fiction/creative writing (optimized for technical/non-fiction)
• Translation to other languages

Inputs

Input	Required	Description
Topic/subject	Yes	What the book is about
Source repo

No | GitHub URL to analyze as source material | | Chapter count | No | Auto-scaled from repo size (see below), or user override | | Target length | No | Auto-scaled from repo size (see below), or user override | | Budget limit | No | Max API cost in dollars. Default: $100. Agent pauses if exceeded | | Output formats | No | Markdown (always), HTML (optional), PDF (optional) | | Model preferences | No | Defaults in Agent Model Recommendations section |

Outputs

• - book/final-manuscript.md — polished, publication-ready manuscript
• INLINECODE1 — manuscript with scrapbook illustrations (if article-illustrator available)
• INLINECODE2 — title, author, word count, chapter count, date
• INLINECODE3 — HTML export (optional)
• Git repository with full project history

Auto-Scaling: Repo Size → Book Size

When a source repo is provided, automatically assess its scope before planning:

CODEBLOCK0

Repo Size	Source Files	Lines of Code	Recommended Chapters	Target Words	Estimated Cost
Small	<50 files	<5K lines	5-6 chapters	~30,000	$5-15
Medium

50-200 files | 5K-30K lines | 8-10 chapters | ~55,000 | $15-35 |
| Large | 200-500 files | 30K-100K lines | 12-14 chapters | ~80,000 | $30-60 |
| Very Large | >500 files | >100K lines | 14-18 chapters | ~100,000+ | $50-100 |

If no source repo is provided (topic-only book), default to Medium (10 chapters, ~55K words).

The user can always override these defaults.

Pre-Flight Cost Estimation

Before starting any work, present the user with a cost estimate and get confirmation:

CODEBLOCK1

Cost tracking during execution: After each phase, log cumulative spend in WORKLOG.md:

CODEBLOCK2

If projected total exceeds budget by >20%, pause and ask the user before continuing.

Architecture

Why an Orchestrator Subagent (not direct Director control)

The naive approach is: Director spawns research agents, waits for completion announce,
spawns writing agents, waits again, etc. This breaks in practice because:

1. 1. Announce-to-action gap: When a subagent finishes, OpenClaw sends a completion

message to the parent session. The parent gets a new turn, but it must choose to chain the next phase. If it treats the announce as informational (reports results to user and stops), the pipeline stalls. There is no guaranteed hook that forces the next action.

1. 2. Context loss between turns: Each turn the Director takes is a fresh LLM call.

Between subagent completion and the next turn, there's no persistent state machine tracking "we're in phase 3 of 7." The Director must re-derive pipeline state from WORKLOG.md every time, which is fragile.

1. 3. User messages interrupt: If the user sends a message between phases, the Director's

next turn handles that message instead of continuing the pipeline. The pipeline stalls until another trigger arrives.

Solution: Orchestrator subagent pattern. The Director spawns a single orchestrator
subagent (maxSpawnDepth: 2) that owns the entire pipeline lifecycle. The orchestrator
runs as a continuous session, spawning worker sub-sub-agents for each phase and
immediately chaining the next phase when workers complete. Because it's a single
continuous run, there's no announce-to-action gap — the orchestrator never yields
control between phases.

CODEBLOCK3

Depth Model

Depth	Role	Spawns children?	Has session tools?
0	Director (main agent)	Yes — spawns orchestrator	Full tools
1

Orchestrator | Yes — spawns workers | Gets sessions_spawn, subagents, sessions_list, sessions_history | | 2 | Workers (research, writing, review) | No | File I/O + exec only |

Requires: agents.defaults.subagents.maxSpawnDepth: 2 in OpenClaw config.

If maxSpawnDepth is 1 (default), the skill falls back to Director-controlled mode
(see Fallback section below).

Fallback: Director-Controlled Mode (maxSpawnDepth: 1)

If nested subagents are not available, the Director orchestrates directly:

• - Spawns each phase's workers as depth-1 subagents
• When completion announces arrive, must immediately chain the next phase
• Pipeline state tracked via WORKLOG.md
• Risk: announce-to-action gap if Director doesn't chain (see justification above)

To mitigate, set a cron safety net after spawning:
CODEBLOCK4

Agent Coordination

All agents coordinate via WORKLOG.md (append-only). The orchestrator (or Director
in fallback mode) reads WORKLOG to track progress. Workers append entries when starting
and finishing work.

End-to-End Example

User says: "Write a technical book about AI-native software development. Source: https://github.com/openclaw/openclaw"

Step 1 — Gather requirements:

• - Topic: AI-native software development
• Source repo: openclaw/openclaw
• Chapters: 12 (default)
• Target: ~80,000 words

Step 2 — Set up repo and spawn orchestrator:

mkdir -p book-project/{chapters,book,diagrams,research,reviews,scripts,project-notes}
cd book-project && git init

Copy templates, then spawn the orchestrator subagent (depth 1) which manages all
remaining phases. The orchestrator spawns worker sub-sub-agents (depth 2) in parallel.

Step 3 — Research phase (orchestrator spawns 3 parallel workers):
CODEBLOCK6

Step 4 — Outline phase (spawn 2 agents):

Agent 1: "Write detailed outlines for intro + chapters 1-6. Reference pattern-synthesis.md.
Output: chapters/chapter-NN-outline.md per chapter."

Agent 2: "Write detailed outlines for chapters 7-12."

Review and commit outlines.

Step 5 — Writing phase (spawn 4 parallel agents, 3 chapters each):

Agent 1: "Write intro + chapters 1-3. Read outlines and pattern-synthesis.md.
Target: 6,000-8,000 words per chapter. Update WORKLOG.md when each chapter is complete."

Agent 2: "Write chapters 4-6."
Agent 3: "Write chapters 7-9."
Agent 4: "Write chapters 10-12."

Model: INLINECODE12

Step 6 — Review phase (spawn 2 agents):

Agent A: "Review intro + chapters 1-6. Check: logical flow, unsupported claims,
contradictions, missing examples. Output: reviews/quality-review-01-06.md.
Mark issues CRITICAL or MINOR."

Fix CRITICAL issues before proceeding.

Step 7 — Integration:
CODEBLOCK10

Step 8 — Polish:
CODEBLOCK11

Step 9 — HTML export:
CODEBLOCK12

Step 10 — Commit and report:

git add -A && git commit -m "book: complete manuscript" && git push

Report: chapter count, word count, file locations, GitHub URL.

Chapter Revision Mode

Revise a single chapter of an existing book without regenerating the entire manuscript.

When to Use

• - A chapter is outdated (new features, changed APIs)
• Quality is below standard (reviewer scored it low)
• User wants a different angle or deeper coverage
• New information needs to be incorporated

Revision Inputs

Input	Required	Description
Book repo	Yes	Local path or GitHub URL of the existing book
Chapter number

Yes | Which chapter to revise (e.g., 3 or chapter-03) | | Revision instructions | No | Specific guidance: "add more examples", "update for v2 API", "make it more practical" | | Budget limit | No | Default: $5 per chapter revision |

Revision Workflow

Step R1 — Clone and Analyze

CODEBLOCK14

Read the target chapter + its outline + adjacent chapters (N-1 and N+1) for context continuity.

Step R2 — Review Current Chapter

Spawn a reviewer agent to score the existing chapter on the standard rubric:

• - Technical accuracy
• Completeness (are topics from the outline covered?)
• Code examples (working? up to date?)
• Flow and readability
• Consistency with adjacent chapters

The reviewer produces reviews/revision-review-chapter-NN.md with:

• - Score per dimension
• Specific issues found
• Recommended changes

Step R3 — Research Updates (if needed)

If the revision requires new information (updated APIs, new features, recent events):

Spawn a research agent to:

• - Query DeepWiki MCP (curl https://api.deepwiki.com/v1/chat) for current repo architecture and features
• Analyze the source repo (if provided) for changes since the chapter was written
• Web search for updated information and external context
• Produce INLINECODE17

DeepWiki is the preferred research source for GitHub repo-based books — it provides deep, structured answers about architecture, components, and patterns.

Skip if the revision is purely stylistic (rewrite for clarity, add examples from existing content).

Step R4 — Rewrite

Spawn a writer agent with:

• - The existing chapter text
• The review (from R2)
• Research updates (from R3, if any)
• The chapter outline
• Adjacent chapters (for tone/style consistency)
• User's revision instructions

The writer produces a new version: INLINECODE18

Key constraints for the writer:

• - Preserve the chapter's position in the book narrative (don't contradict adjacent chapters)
• Keep the same heading structure unless the outline changed
• Maintain consistent terminology with the rest of the book
• If the original had diagrams, preserve or update diagram references

Step R5 — Review (Mobile-Friendly)

Users often review from a phone (iPhone/Android via Discord, Signal, or Telegram). The review workflow adapts to the platform:

Path A — GitHub PR (preferred, best for diff review):

CODEBLOCK15

The user reviews the diff in GitHub mobile app (excellent diff viewer), then:

• - Comments "LGTM" or "approve" → agent merges PR and re-generates manuscript
• Comments with feedback → agent makes changes, pushes to same branch
• Closes PR → revision discarded

Path B — Obsidian sync (for offline reading):

If the user has Obsidian configured (e.g., via save-to-obsidian.sh):

# Send revised chapter + summary to Obsidian vault
save-to-obsidian.sh chapters/chapter-NN-revised.md
save-to-obsidian.sh reviews/revision-summary-chapter-NN.md

User reads the full chapter on Obsidian mobile, replies via chat.

Path C — Chat summary (quickest):

Post a concise summary (≤500 words) directly in chat:
CODEBLOCK17

Auto-detect by content type:

• - Text-only revision (no new diagrams/images): Default to Path A (PR) + Path C (chat summary). GitHub diff is ideal for text changes.
• Illustrated revision (new or updated diagrams/images): Default to Path B (Obsidian) + Path C (chat summary). Obsidian renders images inline — you see the chapter exactly as it appears in the book. GitHub PR diffs show images as "binary file changed" which is useless for review.
• User preference overrides — if they ask for a specific path, use it.

Recommendation: For chapters with diagrams (most technical books), Obsidian preview is the best experience on mobile. Use the PR for the final merge step after Obsidian review.

Step R6 — Integrate

On user approval (via PR merge, chat reply, or Obsidian feedback):

Best practice: Replace in-place, never create -new or -v2 suffixes.

• - chapters/chapter-NN.md ← always overwrite the current file
• INLINECODE23 ← always replace diagrams in the same directory
• No backups (-pre-revision, -old, -v2) — git history IS the backup
• No new directories (chapter-02-new/) — the PR diff shows what changed

This prevents suffix accumulation (-new, -new-new, -new-v3) across revisions.

CODEBLOCK18

Step R6.5 — Validate Links (automated)

After integration, run the link validator to catch broken references:

CODEBLOCK19

This checks:

• - All ![image](path) references point to existing files
• All [link](file.md) references resolve
• No orphaned diagram directories
• Suggests fixes for broken links (fuzzy match on filenames)

Must pass with 0 broken links before proceeding to R7 or committing.

Also verify metadata block exists:

grep -c "## Chapter Metadata" chapters/chapter-NN.md || echo "ERROR: Missing metadata block"

If missing, add it before committing.

If broken links are found:

1. 1. Fix image paths to match actual filenames in INLINECODE33
2. Re-run validator until clean
3. Also run on book/final-manuscript-with-diagrams.md if it exists (merged manuscript may have stale refs)

Step R7 — Re-illustrate (Optional)

If the chapter content changed significantly (>30% rewritten), regenerate diagrams:

• - With image API key: Re-run article-illustrator for the revised chapter
• Without image API key: Re-run skill-mermaid-diagrams for the revised chapter

Revision Cost Estimate

Component	Model	Est. Cost
Review	deepseek	$0.01-0.02
Research (if needed)

gemini-pro | $0.05-0.10 | | Rewrite | claude-sonnet | $0.10-0.30 | | Re-illustrate (if needed) | Z.AI | $0.03-0.06 | | Total per chapter | | $0.15-0.50 |

Example: Revise Chapter 3

CODEBLOCK21

Chapter Metadata Block (Required)

Every chapter must end with a metadata block providing provenance and reproducibility information. This is critical because source repos evolve fast — readers need to know which version the chapter describes.

Template (append to end of each chapter):

CODEBLOCK22

Why this matters:

• - Source repos change daily — without a commit pin, the chapter becomes unreproducible
• Model attribution helps readers understand potential biases
• Freshness warnings prevent readers from treating outdated info as current
• Skill version enables reproducing the exact pipeline

When revising: Update all metadata fields. The old commit → new commit change is the most important field to update.

Setup & Configuration

Step 0 — Environment Discovery (run before every book/revision)

Before starting any pipeline, discover available API keys and expose them as environment variables. The skill uses multiple external services — some required, some optional.

Run this discovery check:

CODEBLOCK23

Expose keys as env vars (so subagents/scripts can access them):

CODEBLOCK24

What Happens When Keys Are Missing

Missing Key	Impact	Fallback
All LLM providers	Fatal — cannot proceed	Ask user to configure at least one provider in INLINECODE35
All image keys (ZAI, GLM, OR)

No scrapbook illustrations | Mermaid diagrams via skill-mermaid-diagrams (free) | | mmdc CLI | No rendered diagram PNGs/SVGs | Raw mermaid code blocks in markdown (still renders in GitHub/Obsidian) | | DeepWiki | Weaker research for repo-based books | Direct repo analysis + web search | | gh CLI | No PR review workflow | Obsidian preview or chat summary only | | Obsidian sync | No mobile preview with images | GitHub PR + chat summary |

The skill always works — missing optional keys degrade gracefully to free alternatives. Only LLM provider keys are required.

Full Book Workflow (New Books)

Step 1 — Gather Requirements and Estimate Cost

Ask the user (or infer from context):

• - Topic/subject — what is the book about?
• Source repo (optional) — GitHub URL to analyze as source material
• Budget limit — how much are they willing to spend? (default: $100)
• Output formats — Markdown (always), HTML, PDF (optional)

If a source repo is provided, run the auto-scaling assessment (see above) to determine chapter count and target length. Then present the Pre-Flight Cost Estimation and wait for user confirmation before proceeding.

If the user sets a budget below the estimated cost, suggest reducing chapter count or using cheaper models (e.g., deepseek for writing instead of claude).

Step 2 — Set Up Repo and Spawn Orchestrator

CODEBLOCK25

Copy templates from <skill_dir>/templates/ into project-notes/ and edit for your project. Replace <skill_dir> with the directory containing this SKILL.md.

Then spawn the orchestrator subagent (preferred, requires maxSpawnDepth: 2):

CODEBLOCK26

The orchestrator handles Steps 3-10 autonomously. The Director only needs to relay
the final report to the user.

If maxSpawnDepth is 1 (fallback), the Director runs Steps 3-10 directly,
spawning workers as depth-1 subagents and chaining phases on each completion announce.

Step 3 — Research Phase

DeepWiki MCP (preferred for GitHub repos):

If the book's source material is a GitHub repo, use the deepwiki-mcp skill (clawhub install deepwiki-mcp) for deep research:

CODEBLOCK27

DeepWiki provides structured, authoritative answers about any public GitHub repo — its architecture, components, patterns, and implementation details. This is far more reliable than generic web search for repo-specific questions.

Research agent should query DeepWiki for each chapter's topics, then supplement with web_search for broader context (industry trends, comparisons, external references).

Fallback: If DeepWiki is unavailable, fall back to direct repo analysis (clone + read files) and web search.

Spawn 2-3 research agents in parallel:

CODEBLOCK28

Then spawn one synthesis agent:

CODEBLOCK29

Done when: research/pattern-synthesis.md exists and covers 6+ patterns.

Step 4 — Outline Phase

Spawn outline agents (batch 5-6 outlines per agent):

CODEBLOCK30

Review and commit outlines before writing.

Done when: All chapter-NN-outline.md files exist and reviewed.

Step 5 — Writing Phase

Assign 3 chapters per writing agent — this is where parallelism pays off:

CODEBLOCK31

Model: INLINECODE46

Done when: All chapter files exist and WORKLOG shows completion.

Step 6 — Review Phase

Spawn 1-2 review agents:

CODEBLOCK32

Fix CRITICAL issues. MINOR issues can be addressed in polish.

Done when: Reviews exist and no open CRITICAL issues.

Step 7 — Integration Phase

Run the merge script:

CODEBLOCK33

Or spawn an integration agent to merge manually and fix cross-references.

Done when: book/manuscript.md exists with all chapters in order.

Step 8 — Polish Phase

Run the polish script:

CODEBLOCK34

This adds title page, copyright, TOC with anchor links, and writes book/metadata.json.

Done when: book/final-manuscript.md and book/metadata.json exist.

Then validate links:

python3 <skill_dir>/scripts/validate_links.py --book-dir .

Must pass with 0 broken links before publishing.

Step 8.5 — Illustrate (Optional)

Add scrapbook-style illustrations to the manuscript using the article-illustrator skill.

Prerequisites: article-illustrator skill installed, at least one image API key set (ZAIAPIKEY, GLMAPIKEY, or OPENROUTERAPIKEY).

Process:

1. 1. Check for image API key — if none found, skip this step (book works fine without images).

1. 2. Split manuscript into chapters for illustration planning:

The orchestrator processes each chapter section from book/final-manuscript.md directly. No splitting needed — feed each chapters/chapter-NN.md file to the illustrator.

1. 3. Determine diagram count and placement (REQUIRED before generating):

Diagram count by chapter length:
| Chapter Length | Min Diagrams | Target |
|---------------|-------------|--------|
| < 3,000 words | 2 | 3 |
| 3,000–5,000 words | 3 | 4–5 |
| 5,000–8,000 words | 4 | 5–7 |
| > 8,000 words | 5 | 7–10 |

Placement rules:
- Overview diagram: Always first — within the first 200 words / before first H2. Type: concept-map, radial-concept, or architecture. Purpose: bird's-eye view of the whole chapter.
- Per-section diagrams: 1 per major H2 section, placed after the first paragraph of that section.
- Max gap: No stretch longer than 2,000 words without a diagram.

Diagram type by section content:
| Content Type | Z.AI (scrapbook) | Mermaid |
|-------------|-----------------|---------|
| System/architecture | abstract tech scrapbook | architecture |
| Process/workflow | steps/flow scrapbook | flowchart, sequence |
| Comparison/tradeoffs | balance/scale scrapbook | comparison-table |
| Data/trends/metrics | chart/graph scrapbook | timeline, gantt |
| Concepts/relationships | abstract concept scrapbook | concept-map, radial-concept |

1. 4. For each chapter, invoke the article-illustrator workflow:

- Read article-illustrator/references/scrapbook-prompt.md for the system prompt - Read the scrapbook system prompt from the article-illustrator skill:

     cat <article_illustrator_dir>/references/scrapbook-prompt.md
     

- Analyze the chapter text and generate a JSON illustration plan:

     {
       "project_title": "Chapter N — Scrapbook Style",
       "style": "Physical Mixed-Media Scrapbook",
       "total_images": 2,
       "images": [
         {
           "image_id": 1,
           "title": "Caption",
           "description": "300-500 char scrapbook visual description...",
           "insert_after": "Exact heading or sentence"
         }
       ]
     }
     

- Target: 1 image per 1,500-2,000 words (books are less dense than articles) - Generate all images in parallel using the article-illustrator script:

     cd <article_illustrator_dir>
     python3 scripts/generate.py "<description_1>" --language en --size 1088x1920 &
     python3 scripts/generate.py "<description_2>" --language en --size 1088x1920 &
     wait  # Both images generate concurrently (~20-40s each)
     

The script reads ZAIAPIKEY, GLMAPIKEY, or OPENROUTERAPIKEY automatically. - Insert images at designated anchor points

1. 4. Compose illustrated manuscript:

Insert each image after its designated insert_after anchor:

   ![Caption](diagrams/chapter-NN/image-01.png)
   

Save the illustrated chapter to chapters/chapter-NN.md (replace in-place). Then re-run merge to update the full manuscript: CODEBLOCK40

1. 6. Cost tracking: ~$0.015/image (Z.AI) × images. For a 10-chapter book with 1-2 images each: ~$0.15-0.30.

Image count guidelines by book size:

Book Size	Chapters	Images/Chapter	Total Images	Est. Cost (Z.AI)
Small (2-3)	2-3	1-2	2-6	$0.03-0.09
Medium (5-8)

5-8 | 1-2 | 5-16 | $0.08-0.24 |
| Large (10-15) | 10-15 | 1-2 | 10-30 | $0.15-0.45 |

Done when: book/illustrated-manuscript.md exists with images embedded.

Fallback — Mermaid diagrams via skill-mermaid-diagrams (no image API key needed):

If no image API key is available (ZAIAPIKEY, GLMAPIKEY, OPENROUTERAPIKEY all missing), use the skill-mermaid-diagrams skill (clawhub install skill-mermaid-diagrams) to generate professional, template-based diagrams:

1. 1. Install if needed:

CODEBLOCK41

1. 2. For each chapter, spawn a subagent:

CODEBLOCK42

1. 3. The subagent will:

- Read chapter content - Select from 12 available templates: architecture, flowchart, sequence, concept-map, radial-concept, timeline, comparison, comparison-table, gantt, mindmap, class-diagram, state-diagram - Generate content.json with placeholder values - Run node $SKILL_DIR/scripts/generate.mjs --content content.json --out diagrams/chapter-NN - Validate: node $SKILL_DIR/scripts/validate.mjs --dir diagrams/chapter-NN - Output: .mmd source + .svg vector + .png raster for each diagram

1. 4. Insert into manuscript: Reference generated images in markdown:

CODEBLOCK43

1. 5. Cost: ~$0.002/chapter (LLM tokens only) — rendering is free (local mmdc).

For a 10-chapter book: ~$0.02 total (vs $0.15-0.45 for AI images).

1. 6. Consistent styling: All diagrams share a unified color scheme across chapters.

Decision logic:
CODEBLOCK44

Skip entirely when: User specified --no-illustrations --no-diagrams.

Step 9 — HTML Export (Optional)

CODEBLOCK45

Requires either pandoc or pip install markdown2.

Step 10 — Commit and Report

CODEBLOCK46

Report to user: chapter count, word count, file locations, GitHub URL.

Agent Model Recommendations

Role	Model	Why
Director (you)	INLINECODE67	Planning, coordination
Research

openrouter/google/gemini-2.5-pro-preview | Large context, data synthesis | | Writing | anthropic/claude-sonnet-4-6 | Coherent long-form prose | | Review | openrouter/deepseek/deepseek-v3.2 | Cost-effective, thorough | | Integration/Polish | anthropic/claude-sonnet-4-6 | Consistent merging |

Cost Estimates

Book Size	Approx. API Cost	Time (parallel)
5 chapters, ~30K words	$5-15	2-4 hours
10 chapters, ~60K words

$15-35 | 4-8 hours | | 14 chapters, ~88K words | $30-60 | 6-12 hours |

Directory Structure

CODEBLOCK47

WORKLOG Protocol

Every agent must append to WORKLOG.md at start and finish:

CODEBLOCK48

Director reads this to know what's done without polling agents.

Error Handling

Problem	Detection	Action
Agent fails mid-chapter	WORKLOG shows no update for >2 hours	Respawn agent with same task
Chapter too short

<4,000 words | Respawn writing agent with explicit "expand" instruction | | Quality review fails | >3 CRITICAL issues per chapter | Respawn writing agent to rewrite section | | Merge script fails | Python error | Check chapter file naming (must be chapter-NN.md) | | Cost exceeds budget | Track cumulative spend | Pause and consult user | | Cross-reference broken | Review shows "Chapter N" pointing nowhere | Fix manually in integration phase |

Success Criteria

• - All chapters drafted (target: ~6,000-8,000 words each)
• Quality review: >85% of issues marked RESOLVED
• Final manuscript: single cohesive document with TOC
• HTML export renders correctly (if requested)
• Git committed and pushed
• Total word count within 20% of target

Configuration

No persistent configuration required. The skill uses:

Recommended config (enables orchestrator pattern):

CODEBLOCK49

Without maxSpawnDepth: 2, the skill falls back to Director-controlled mode (see
Architecture section for tradeoffs).

Required tools:

Tool	Purpose
INLINECODE75	Run Python scripts, git commands
INLINECODE76

Spawn orchestrator and/or worker sub-agents |
| read / write | Read/write chapter files |

Optional tools:

Tool	Purpose
INLINECODE79	Research phase (if no source repo provided)
INLINECODE80

Fetch source repo content |

System dependencies:

Dependency	Purpose
Python 3.8+	merge, polish, HTML conversion scripts
git

Version control |
| pandoc (optional) | Better HTML conversion |

Notes

• - Set cost_limit: $100 in SYSTEM.md as a safety guard
• The WORKLOG protocol is critical — agents that don't update WORKLOG create blind spots
• Commit to git after every phase, not just at the end
• For very long books (>100K words), increase chapter count rather than word-per-chapter target
• The reference implementation at openclaw-paradigm-book includes all project notes for study