book-skills Turns Work Books Into Claude Skills

book-skills is Dami Martinez’s open-source collection of skills for Claude Code, Anthropic’s coding agent, where each skill represents a management or programming book. It deals with a familiar problem: teams remember frameworks like Build-Measure-Learn or task-relevant maturity, but forget to apply them when work is being shaped. The takeaway is small and useful: a Claude skill can encode a method without turning it into a static summary.

book-skills is a set of on-demand Claude skills that make book frameworks available when the user mentions their concepts, not only the book title. For Claude Code for teams, the interesting part is not installing every book skill; it is seeing how a shared method can become part of a real claude code workflow. As of August 3, 2026, the repository showed an MIT license, 2 GitHub stars, and a last push on August 2, 2026.

Watch the activation trick

The neat part of book-skills is the trigger. The README says the Lean Startup skill should activate when someone asks how to validate an idea before building it, even if they never type the book title.

A Claude skill is an on-demand package of instructions and supporting material that Claude can use when the task matches the skill. In this project, each package maps a book to a working method: The Lean Startup for MVPs and actionable metrics, High Output Management for one-on-ones and indicators, The Hard Thing About Hard Things for hard leadership calls, and The Pragmatic Programmer for engineering judgment.

That is more interesting than a folder of summaries. A summary helps after you ask for it. A skill tries to show up while the work is still soft enough to change.

The trap is vague activation text. A skill called lean-startup is not enough by itself. The description has to name the moments where it should appear: validation planning, MVP scope, riskiest assumption, pivot-or-persevere review, and metrics that would actually change the decision.

Notice what developers cared about

The Hacker News appeal is easy to understand. Many teams already have a private canon of books, blog posts, design docs, and operating principles, but that canon usually lives in memory, Slack archaeology, or a manager’s head.

book-skills asks a better question: can those methods become executable enough that Claude applies them during normal work? Not executable like a program. Executable like a checklist, critique, or decision frame that appears at the right time.

There is a fair objection, too. A book skill can flatten a real book into slogans if it only preserves the famous words. Build-Measure-Learn is useful; using it as a decorative heading over a normal feature plan is theater.

A good skill should force the uncomfortable move. For Lean Startup, that means naming the riskiest assumption before writing the implementation plan. For High Output Management, it means asking which activity changes output, not which activity feels responsible.

That same small-spec instinct shows up in Yamlet Makes Agent Specs Smaller: the win is not more context, it is sharper context at the moment the agent needs it.

Keep book methods separate from repo facts

A book skill should not become your repo memory. Keep durable project facts in the repo’s normal Claude Code context, and keep portable methods in skills.

For example, a payments repo might keep a concise rule that billing event names cannot change without a migration note. That belongs with the codebase. A Pragmatic Programmer-style prompt to look for reversible decisions and broken-window cleanup belongs in a skill, because it can travel to any repo.

A small skill outline might look like this:

---
name: lean-startup
description: Use when planning validation, MVP scope, actionable metrics, or pivot-versus-persevere decisions.
---

Start by identifying the riskiest assumption.
Propose the smallest experiment that can test it.
Separate vanity metrics from metrics that would change the decision.
End with a clear pivot, persevere, or learn-more recommendation.

That is enough to be useful, and short enough to review. The trap is importing a whole personal library into Claude Code and calling it team knowledge. If the skill cannot be explained in one screen, it probably needs pruning.

Try it when method matters more than facts

This is worth trying when your team repeatedly asks for the same kind of judgment. Product validation, incident review, API design, staff-engineer tradeoff memos, and manager one-on-one prep are good candidates.

It is overkill when the work is mostly factual lookup. A skill should not replace the book, your licensed notes, or a real domain expert. It should make a known method easier to apply in the flow of work.

For claude code for teams, start with one book-method that already has social permission. Do not start with the most controversial framework in the company. Pick the one people already use, then test whether the skill makes the output more specific.

Keep the permission boundary boring. A book skill should usually need no MCP access at all. If it touches GitHub, Jira, Slack, or a database through MCP, keep that access read-only unless the task has a separate review path.

Hooks can stay ordinary too. Let your normal format, test, and diff-review hooks catch code changes. The skill’s job is to improve the thinking before the edit, not to bypass the checks after it.

If you are collecting conventions for a Claude team, keep the broader operating notes in the related training topic and keep book-skills-style methods as separate, inspectable units.

Try it safely decision table

Use this as a light gate before copying a book method into a Claude skill.

The best first experiment is simple. Run one real planning prompt before the skill, run the same prompt after the skill, and compare whether the answer names the decision, the risk, and the next evidence-gathering step more clearly.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code teams. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “book-skills Turns Work Books Into Claude Skills.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• book-skills — source
• Claude Code — skills
• GitHub — anthropics/skills
• Claude Code docs: en getting started

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.