Book-to-skill: compiling human knowledge into agent capability

Short answer

book-to-skill (github.com/virgiliojr94/book-to-skill) compiles a book into an agent skill. The pipeline: extract the source material, structure it into knowledge, compile a compact SKILL artifact, and keep supporting files lazy - loaded only when the skill needs them.

Ernesta Labs generalized the idea immediately: BOOK -> SKILL becomes SOURCE -> CANDIDATE CAPABILITY, where a source can be a book, a paper, a manual, a runbook, a playbook, API documentation, internal docs, or a verified trajectory. Human knowledge that already exists in your organization is a capability mine.

One hard rule governs everything we do with this: SOURCE KNOWLEDGE != VALIDATED BEHAVIOR. A compiled skill tells the agent what a book says. It does not prove the agent does what the book says, and it does not prove the book's advice works in your domain. Compilation is a capability candidate, not a capability.

The failure mode: agents that only know the internet

Every organization owns knowledge its agents cannot see: the sales playbook that actually closes deals, the runbook that got the team through the last outage, the API manual with the undocumented pagination quirk, the book a founder considers their operating system. Model weights know the internet's average. They do not know any of this.

The two common responses are both wrong. Response one: paste documents into context at runtime - expensive, unreliable retrieval, and the agent still reasons over noise rather than over a distilled procedure. Response two: fine-tune - expensive, slow, destroys itself at the next model upgrade, and turns knowledge into an unexplainable weight change.

The missing option is compilation: turn a human source into a small, structured, compact artifact the agent loads on demand - a skill. This is what software engineering did decades ago with source code and binaries, and what book-to-skill does for prose.

What the repository actually does

PRIMARY SOURCE RESULT: book-to-skill (github.com/virgiliojr94/book-to-skill) is an open-source project that converts a book into an agent skill. The pipeline runs in clear stages: source extraction (getting the book's content into machine-processable form), structured knowledge (organizing the extracted material into structured units), a compact SKILL artifact (a small skill file the agent actually loads), and lazy supporting files (the heavier, detailed material stays on disk and is loaded only when the skill's execution needs it).

PRIMARY SOURCE RESULT: The compact-versus-lazy split is the engineering core. The skill that enters the agent's context is deliberately small - a procedure, a trigger, an index. The bulk of the source material lives as supporting files the skill can pull in selectively. The agent pays context cost only for what the current task needs.

This is a small repository, not a paper and not a framework. It is closer to a well-executed script with a strong idea behind it. We treat it accordingly: the idea and the pipeline shape are the contribution; there are no benchmarks, no claims of evaluated agent improvement, and no maturity guarantees.

Why this pattern is bigger than books

LABS INTERPRETATION: The pipeline generalizes trivially, and that generality is why Ernesta Labs adopted the pattern rather than just bookmarking the repo. Replace 'book' with any human-authored source and the stages hold: a sales playbook compiles into a candidate outreach skill; an incident runbook compiles into a recovery skill; API documentation compiles into a tool-use skill with the sharp edges recorded; a verified trajectory (Article 25's output) compiles into a candidate procedure. BOOK -> SKILL becomes SOURCE -> CANDIDATE CAPABILITY.

The word CANDIDATE in that mapping is doing the load-bearing work. Everything this arc has argued applies here at full force: a compiled artifact is a change to your agent's capabilities, so it enters through the change loop from Article 26 - localized, versioned, validated, promoted, rollback-able. A compiled skill that skips the loop is just an in-place mutation with a nicer file format.

The economics deserve a sentence: most organizations already paid for this knowledge once, in salaries and mistakes. Compilation is amortization - the cheapest capability acquisition available, because the source already exists and is already trusted by humans.

Limitations, stated plainly

Repository-grade maturity, with everything that implies: a small codebase, a single author's judgment about extraction and structure quality, no evaluation of whether compiled skills actually improve agent outcomes. We reviewed the pipeline; we did not inherit its author's claims as evidence. Build the pipeline yourself against your own sources, and read the output before an agent does.

Extraction is lossy and loss is invisible. A book's value often lives in what it declines to say, in ordering, and in warnings - the parts easiest to drop in structuring. A compiled skill confidently omits them. And books are wrong: a source can be outdated, wrong for your domain, or subtly wrong everywhere. Compilation faithfully reproduces the source's errors with a new, more confident delivery mechanism.

The hardest limitation is behavioral, and it is the article's hard rule: SOURCE KNOWLEDGE != VALIDATED BEHAVIOR. A skill compiled from the best sales book ever written has demonstrated exactly one thing - that the agent can now recite the book's procedure. Whether following it produces outcomes is an open empirical question in your domain, with your customers, on your funnel.

Why builders should care

Because the highest-leverage, lowest-cost upgrade to most agents is not a better model. It is the knowledge the builder's organization already has, in a form the agent can execute. Your team's runbook is a document today; compiled, it is a recovery skill. Your playbook is a PDF; compiled, it is a candidate outreach skill. The difference between those two states is one pipeline, not one research program.

The compact-plus-lazy pattern also solves a real budget problem. Naive RAG pays retrieval cost on every query and dumps noisy excerpts into context. A compiled skill pays nothing until triggered, then loads exactly the supporting file that matters. For a long-horizon agent where context is the scarcest resource, that swap is the difference between a skill library that scales and one that drowns the agent.

And unlike fine-tuning, compiled skills survive model changes. Model swap, skills reload. That portability alone justifies the pattern for anyone not locked to a single provider.

What we would implement

LABS RECOMMENDATION: Implement SOURCE -> CANDIDATE CAPABILITY as a five-stage compile: (1) SOURCE - book, paper, manual, runbook, playbook, API docs, internal docs, or a verified trajectory; (2) EXTRACTION - pull content into processable form, with the source kept for provenance; (3) STRUCTURE - organize into units small enough to be procedures, warnings, and facts; (4) COMPILE - emit a compact skill artifact with a trigger, a procedure, and an index of supporting files; (5) LAZY SUPPORT - keep the detailed material on disk, loaded only on demand.

LABS RECOMMENDATION: Every compiled skill then enters the Article 26 change loop as a versioned candidate: validated against real tasks before promotion, promoted explicitly, rollback-able, with the source and compile provenance stored on the skill record. The candidate carries a marker that separates it from skills validated by outcomes: compiled-from-source is a provenance class, not a performance class.

We would add one stage the repository does not have: a source-freshness field. Books do not expire, but runbooks, API docs, and playbooks do. A skill compiled from a source that has since changed is a silent failure mode, so each skill records its source version and a review date.

What we would not implement

We would not promote a compiled skill to production authority without validation. A sales skill compiled from a book can inform NIKO's candidate behavior; it cannot override evidence about what actually works, and it does not get to act unsupervised just because the source is a good book.

We would not compile everything. Low-value sources produce skill sprawl - the failure mode from Article 26 - where a library of compiled book skills crowds context and none of them earns their keep. Compile sources your team already trusts enough to argue about.

And we would not use the compiled artifact as the system's source of truth for facts. The skill is an executable procedure with provenance; the truth lives in the source and in verified outcomes. When they disagree, the disagreement is a finding, not a tiebreak.

Practical test: compile one skill from something you already trust

Do this today with your own system. Pick one document your team treats as authoritative - a runbook, a playbook, a manual section, an onboarding doc. Run it through the stages by hand: extract the text, break it into 5-10 discrete procedures, and for each write a compact skill file: a one-line trigger (when this skill applies), a numbered procedure, the warnings the source contains, and an index of the detailed passages kept as separate lazy files on disk.

Then test the difference. Give your agent the same task twice: once with the original document dumped into context, once with only the compact skill plus lazy loading. Compare context tokens consumed, and whether the agent followed the procedure's steps and warnings in order. The token difference will be 5-20x. The procedure-following difference is usually larger - structure beats excerpt soup.

Last step, the one that matters: mark the compiled skill's source version and a review date, and log it as a candidate with provenance - not as validated behavior. If it later earns promotion through outcomes, you have the full chain this arc argues for: source, compile, candidate, validation, promotion. If it never earns promotion, you learned the source was wrong cheaply instead of expensively.

What remains unknown

• Whether skills compiled from human sources outperform runtime retrieval over the same sources - we observe token savings and cleaner procedure-following, but have no controlled comparison.
• How much extraction loss is acceptable: which source content (warnings, ordering, negations) must be preserved for a compiled skill to be safe, and how to detect what the compile dropped.
• How compiled skills age against their sources: the right review cadence for skills built on runbooks, API docs, and playbooks that change without notice.
• Whether outcome-gated promotion of compiled skills is even measurable in domains like sales, where feedback is delayed and confounded - or whether these skills must stay permanently marked unvalidated.

Primary sources

• virgiliojr94/book-to-skill (GitHub repository)