From ljg-skills
拆一本书,只抓读者真正能带走的东西:作者针对什么问题,提出了什么新见解(概念、方法、框架或一句话),以后遇到这个问题该怎么用它。Use when user says 拆书, 分析这本书, 这本书在讲什么, 压缩一本书, book, or gives a book title for structural analysis. NOT FOR chapter summaries, papers, single-idea deep dives, or field ranking.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ljg-skills:ljg-bookThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
输入一本书,输出一个能带走的东西。
输入一本书,输出一个能带走的东西。
不要写读后感。不要写章节摘要。不要写审稿报告。
这份 skill 只问四件事:
宁可少,但要能吸收。别为了全面,把主线写散。
读者半年后只需要记住三句话:
如果这三句话写不出来,说明还没拆到位。
只给书名时,先查:
给了 PDF、正文或样章时,先读原文。除非用户禁止联网,仍要轻查一下基线,别只信作者自己树的靶子。
材料不够就降级:
材料等级不要放在开头抢戏。放到末尾「资料校准」里。
文件头之后、第一个标题之前,先放三行:
- *问题*:作者在答什么问题
- *新见解*:概念 / 方法 / 框架 / 一句话,四选一
- *用法*:以后遇到这个问题,我该怎么用它
正文 3 到 5 节。标题从这本书里长出来,不用固定模板。推荐顺序:
图、参考系、流派地图都不是必选。只有它能让「问题 -> 新见解 -> 用法」更清楚时才画。画了也要短。
问题不是话题。
「科技与未来」是话题。「科技演化有没有自己的方向」才是问题。
找问题时问:
写法要具体。拿去描述同领域另一本书也成立,就太泛。
新见解只挑一个主件,不要堆。
它可以是:
用书里的词。必须出现 1-3 个这本书自己的术语、清单或区分。没有这些词,你拆的是领域,不是这本书。
不要急着判作者是不是原创。更要紧的是:这个东西让我以后怎么看、怎么做。
可以顺手写一句来源:
但来源判断只是一句,不要变成主菜。
这是最重要的一节。
把新见解翻成一个可执行动作:
写成这样的句子:
「以后遇到 X,不要先 Y;先用作者的 Z,看 A,再决定 B。」
用法必须能离开这本书。不能只说「我们要更有耐心」「要系统思考」这种软话。
每个好见解都有代价。边界写短,但不能省。
问:
边界不是挑刺。边界是防止把一本书当万能钥匙。
末尾放短短一节即可。3 到 6 条。
每条说明材料类型和链接:
资料校准服务主线,不要压过正文。
写入:
~/Documents/notes/{时间戳}--拆书-{书名}__book.org
时间戳:
date +%Y%m%dT%H%M%Sdate "+%Y-%m-%d %a %H:%M"文件头:
#+TITLE: 拆书:《{书名}》
#+SUBTITLE: {作者} | {一句话核心观点}
#+DATE: [{YYYY-MM-DD Day HH:MM}]
#+FILETAGS: :book:{领域}:
#+IDENTIFIER: {YYYYMMDDTHHMMSS}
正文控制在能读完、能带走的长度。默认 3 到 5 节。用户没要求深拆时,不要写百科。
简洁,直白,像人说话。
不要夸作者。不要贬作者。不要替作者辩护。
少用:
多写:
禁用这些旧口头禅:
每段读一遍。卡住就整句重写。不要靠形容词制造力量。
交付前只查这八条:
最后问自己一句:读者读完能不能把一个东西吸收进来?
npx claudepluginhub vegayan2024/ljg-skillsCreates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.