Book-to-Skill Converter

Turn written knowledge into an agent skill by extracting structure, not summaries.

A book is crystallized expertise: frameworks, principles, techniques that took years to develop. Read once, forgotten. The workarounds all fail — PDF search returns page numbers instead of answers, an agent handed the raw file hallucinates or drowns, reading notes rot. This skill compiles a source into a knowledge base the agent loads on demand: a small resident core, one chapter file at a time, and never the whole book again.

What it produces:

Beyond books: anything referenced often enough to be worth memorizing — internal documentation, brand systems, standards, specs, research clusters, a folder of RFCs.

Philosophy

Extract structure, not summaries. A skill is not a book report. It is a toolkit of named frameworks, actionable principles, step-by-step techniques, anti-patterns, and the author's voice.

Preserve the author's precision. Framework names are interfaces. "The 5 Whys" is not interchangeable with "ask why a few times" — the exact formulation is what makes lookup work.

Layer depth appropriately. A thin book gets a thin skill. A book with fifteen frameworks gets chapter files and a real topic index.

Never reproduce the source at length. These are structured notes. Synthesize, compress, name — do not copy passages. See references/rights_and_provenance.md.

Modes

Mode 5 is this repository's addition. Upstream stops at a bare folder in a personal skills home; Step 11 wraps that folder in a plugin package other skills and agents can route to.

Hard rules

1. Never convert a source the user cannot show you. No web-scraping a book, no reconstructing a title from memory. This tool converts files that are already on disk.
2. Pre-flight the cost before generating (Step 2.5). Generation is the expensive part; the user approves it with numbers in front of them.
3. Never dump a large source into context. Over ~50k tokens, probe with grep/sed and bounded reads (Step 2.6). Re-reading a 200-page book once per chapter costs more than everything else in this workflow combined.
4. Validate before anyone loads it (Step 9.5). A generated skill is untrusted text that an agent will later read as instructions.
5. Never widen the generated skill's authority. Generated frontmatter carries name and description only — no allowed-tools, no model-invocation flags.
6. Rights before redistribution. Compiled notes from a copyrighted work are personal study notes. Packaging one as a shareable plugin requires a stated basis (Step 11).
7. State what the skill does not cover. Every compiled skill's Scope section names its boundary, so the agent says "the source doesn't cover this" instead of improvising.

Pipeline

extract_document.py  →  analyze  →  chapter files  →  supporting files  →  SKILL.md
      (Step 2)          (Step 3)      (Step 7)          (Step 8)          (Step 9)
                                                                              ↓
                                       skill_plugin_emitter.py  ←  book_skill_validator.py
                                              (Step 11)                  (Step 9.5)

All four tools live in scripts/ and run on the standard library alone.

Run it

SKILL_ROOT=engineering/book-to-skill/skills/book-to-skill
SKILLS_HOME=~/.claude/skills        # Step 5 picks this; see the workflow reference
WORKDIR=$(mktemp -d)                # or omit --workdir and capture the path it prints
SLUG=<author-lastname>-<concept>

# 1. extract → $WORKDIR/full_text.txt + metadata.json
#    --mode technical when tables, code or formulas carry meaning
python3 "$SKILL_ROOT/scripts/extract_document.py" <paths> --mode text --workdir "$WORKDIR"

# 2. pre-flight: is this worth converting at all? Wait for approval before generating.
python3 "$SKILL_ROOT/scripts/token_budget_estimator.py" --full-text "$WORKDIR/full_text.txt"

# 3. generate — the agent's work: chapters/, glossary, patterns, cheatsheet, SKILL.md

# 4. gate — errors block. Fix and re-run; never rewrite around a finding.
python3 "$SKILL_ROOT/scripts/book_skill_validator.py" "$SKILLS_HOME/$SLUG"
python3 "$SKILL_ROOT/scripts/token_budget_estimator.py" --skill-dir "$SKILLS_HOME/$SLUG"

# 5. optional: wrap as a claude-skills plugin so the library can route to it
python3 "$SKILL_ROOT/scripts/skill_plugin_emitter.py" --skill-dir "$SKILLS_HOME/$SLUG" \
    --dest ./engineering --source-note "<Title> by <Author>" --dry-run

Every path above is a real variable, not a placeholder: run the block as written (with <paths> and $SLUG filled in) and it works end to end. Without --workdir the extractor creates a private temp directory and prints it — capture that instead.

extract_document.py --check reports which extractors are installed and prints the install command for what is missing. Every tool supports --help, --sample and --output json.

The full step-by-step procedure — what to ask at each step, the file templates, the per-chapter budget matrix, and the update/fold-in workflow — is in references/conversion_workflow.md. Read it before running a conversion. Summary of the eleven steps:

Validator findings worth knowing

Safety-family warnings are deliberately broad — a source about prompt injection legitimately trips them. Read each in context; do not auto-silence them.

Forcing-question library

Walk these one at a time, with a recommended answer, before running a conversion.

1. "Is this source worth converting, or should I just read it?" Recommended: convert when it is > 3× the compiled skill's size and you will return to it. One-shot reads are cheaper unconverted. (Step 2.5 verdict.)

2. "Reference or study?" Recommended: reference, unless you intend to internalize the author's reasoning. Study depth roughly doubles generation cost and is only worth it with real worked examples. (Step 4.)

3. "Technical or text?" Recommended: technical only when tables, code, or formulas carry meaning. Docling costs ~1.5s/page; picking it for a prose book buys nothing. (Step 1.5.)

4. "What will you actually ask this skill?" Recommended: name three real questions before generating. They tell you what belongs in Core Frameworks and what the topic index must resolve. A skill nobody queries is a summary nobody reads.

5. "Do you have the right to redistribute this?" Recommended: assume not. Keep it local unless the source is public-domain, openly licensed, your organisation's own documentation, or you have written permission. (Step 11 rights gate.)

6. "Does this belong beside an existing skill?" Recommended: check for an existing compiled skill on the same subject first — folding new sources into one skill (Mode 4) beats two skills that half-cover a topic and give the agent no way to choose. (Step 0.)

References

• references/conversion_workflow.md — the full procedure: Steps 0–11, the file templates, the per-chapter budget matrix, and the update/fold-in workflow
• references/knowledge_extraction_canon.md — why structure beats summary; the extraction taxonomy; what makes a framework survive compression
• references/progressive_disclosure_budgets.md — where the token budgets come from and what breaks when they are exceeded
• references/document_extraction_pipeline.md — per-format extractor chains, fallbacks, and the failure modes that produce silently bad text
• references/rights_and_provenance.md — copyright posture, the rights gate, and what provenance a compiled skill must carry

Related skills

• engineering/write-a-skill — authoring a skill from your own expertise. Use that when the knowledge is in your head; use this when it is in a document.
• engineering/skill-security-auditor — full security audit of a skill package. Step 9.5 is the converter's own gate; the auditor is the repo-wide one.
• engineering/llm-wiki — an incrementally-grown, interlinked vault across many sources. This skill compiles one bounded source set into one skill.

Adapted from virgiliojr94/book-to-skill (MIT). See ../../README.md for the full list of deviations.