skills/novel-style-extract/SKILL.md
从参考小说提取抽象化创作风格规则,生成知识库文件。触发:用户要求提取风格、参考某小说构建风格、冷启动时引导调用、需要补充分片。核心能力:将隐性风格转化为显性规则,且必须是抽象的技法而非原书设定。与novel-setup(维护知识库)、novel-lite(使用风格)、novel-review(审查风格)配套。
npx skillsauth add anian0/pick-skills novel-style-extractInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
四件套分工(详见novel-setup):
核心能力:将参考小说的隐性风格转化为显性、可执行的知识库文件,且必须抽象化——提取的是"技法规则"而非"原书设定"。
很多风格提取会直接"复制原书写法",导致新书不可用。例如:
必须提取的是技法规则,而非具体设定:
| 类型 | 定义 | 可提取? | 示例 | |------|------|---------|------| | 通用技法 | 任何题材都能用的写作规则 | ✅ 必须提取 | "战斗要有代价交代"、"主角要有失误" | | 题材技法 | 特定题材适用的规则 | ⚠️ 标注提取 | "武侠:招式名称要挂钩效果"、"科幻:技术名词要铺垫解释" | | 原书设定 | 原书的具体世界观/情节/人物 | ❌ 禁止提取 | "打坐修炼的描写方式"、"某技能的名称和效果" |
题材技法提取时必须标注:⚠️ [题材绑定:武侠/科幻/悬疑/...]
原书片段 → 分析写法 → 抽象为技法规则 → 判断适用范围
↓
通用技法 → 直接写入
题材技法 → 标注后写入
原书设定 → 跳过不提取
示例:
原书片段:"林轲运起玄天剑法,剑光如虹,一剑斩断了敌人的手臂。"
分析:这句话展示了"招式名称 + 视觉效果 + 具体结果"的写法
抽象:
- 通用技法:能力使用后要有具体的、可视化的结果(✅提取)
- 武侠技法:招式名称后紧跟视觉效果描写(⚠️标注"题材绑定:武侠")
- 原书设定:玄天剑法的名称和效果(❌不提取)
| 文档 | 何时加载 |
|------|---------|
| references/reference-提取工作流程.md | 执行提取任务时 |
| references/reference-知识库模板.md | 生成知识库文件内容时 |
.txt、.md每次提取开始前确认: | 确认项 | 说明 | |--------|------| | 参考作品名称 | 用于标注知识库中的来源 | | 提取范围 | 全量(总纲+场景分片+自检清单)/ 增量(指定1-3个场景分片) | | 目标场景类型 | 战斗/对话/环境/心理/动作/情绪/信息释放/过渡 | | 参考小说题材 | 武侠/科幻/都市/悬疑...(用于判断题材技法适用性) | | 本项目题材 | 与参考小说是否同题材?(不同题材时题材技法需标注) | | 是否覆盖已有 | 增量提取时,覆盖还是追加? |
详细流程见 references/reference-提取工作流程.md。
从参考小说整体语感提炼:
⚠️ 注意:总纲铁律必须是通用技法,不能有原书设定痕迹。
针对每种场景类型:
[抽象化提取自参考小说] 或 [本项目已定稿]基于已提取的规则生成可量化自检项:
原书片段:
林轲握紧长剑,心跳加速——对方是筑基期高手,自己只是练气三层。
但他没有退路。剑光一闪,他冲了上去。
对方冷笑,单手挥出,林轲被震退三步,手臂一阵剧痛。
"就这?"对方嘲讽。
林轲咬牙,剑再起——他知道这招的代价,但此刻只能赌。
抽象化分析:
| 原书写法 | 抽象技法 | 适用范围 | |---------|---------|---------| | "握紧长剑,心跳加速" | 战斗起手交代主角状态(武器+心理) | ✅通用 | | "对方是筑基期,自己只是练气三层" | 战斗开始交代双方力量对比 | ✅通用 | | "被震退三步,手臂剧痛" | 主角首次攻击失败,有具体代价 | ✅通用 | | "他知道这招的代价" | 施展能力前提示代价风险 | ✅通用 | | "筑基期"、"练气三层"、"长剑" | 原书等级体系和武器设定 | ❌不提取 |
提取结果:
## 必做
- [ ] 战斗起手交代主角状态(至少2项:武器/心理/伤情/认知盲点)
- [ ] 战斗开始交代双方力量对比(暗示差距,不一定是数值)
- [ ] 主角首次攻击有反制,且代价具体化(剧痛/后退/消耗)
- [ ] 施展关键能力前提示代价/风险
## 量化指标
| 项目 | 不合格 | 合格 | 优秀 |
|------|--------|------|------|
| 主角失误次数 | 0 | 1 | ≥2 |
| 代价具体度 | 抽象"受伤" | 1处具体 | 多处可视化 |
原书片段:
"你为什么要帮我?"林轲问。
"因为你还有用。"那人冷冷道。
"有用?"林轲盯着他,"什么意思?"
"到了你就知道了。"那人转身离去。
抽象化分析:
| 原书写法 | 抽象技法 | 适用范围 | |---------|---------|---------| | 单次对白≤20字 | 对话用短句推进,节奏快 | ✅通用 | | 对白间有动作描写("盯着他") | 对白穿插肢体动作,避免纯对话 | ✅通用 | | 用提问推进("什么意思?") | 信息释放用追问吊胃口 | ✅通用 | | 结尾转身离去,悬念钩子 | 对话结尾留悬念或钩子 | ✅通用 | | 具体对话内容 | 原书情节内容 | ❌不提取 |
提取结果:
## 必做
- [ ] 单次对白控制在30字内(避免说教式长对白)
- [ ] 对白间穿插肢体动作/表情描写
- [ ] 用追问推进信息释放(不一口气说完)
- [ ] 对话结尾留悬念或钩子
## 量化指标
| 项目 | 不合格 | 合格 | 优秀 |
|------|--------|------|------|
| 单次对白最长 | >50字 | 30-50字 | <30字 |
| 信息追问次数 | 0 | 1 | ≥2 |
development
编排无人值守项目开发闭环,从需求澄清、技术方案、实施计划、代码执行、阶段审查、疑问回退到端到端测试验收。用户要求“无人值守开发”“端到端交付”“自动推进研发流程”“严格审查并回退重做”“从需求到测试全流程执行”时使用;本 skill 负责总控,不替代 requirements-workshop-v2、tech-design-v2、implementation-planning-v2、plan-execution-v2、project-development-review-v2 或 test-suite-maintainer 的阶段规则。
development
基于已确认的需求简报创建简洁的实现契约。当需求已确认,用户要求技术方案、实现方案、API 或数据设计、代码变更契约时使用。本 skill 只设计方案,不写生产代码。
content-media
将项目想法或功能请求澄清为简洁、聚焦决策的需求简报。当用户想讨论需求、确定范围、把想法整理成开发前输入,或为 tech-design-v2 准备需求材料时使用。本 skill 只产出需求,不做技术方案或代码实现。
development
项目开发 v2 skill 套件的共享政策和交付契约。当维护、审查、分享或挂载 requirements-workshop-v2、tech-design-v2、implementation-planning-v2、plan-execution-v2 使用的公共文档时使用;当任务涉及 v2 提问策略、交付契约或禁止模拟完成策略时也使用。