paper-writing-discipline

Name: paper-writing-discipline
Author: Lambenthan

19stars0forks

How to install paper-writing-discipline?

lambenthan/paper-discipline-skills/paper-writing-discipline

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-writing-discipline

Installs into the current project.

Summary

当用户在科研写作过程中踩到一个本系列 paper-* skill 没覆盖的新坑、并表示"以后...我都要这样做"、"下次记得..."、"这种情况要先..."、"加一条新规则"时，帮用户把这条新规则按 4 个判断题筛过，合格则按本 skill 提供的模板提炼成一个新的 paper-* skill 落盘。 Use when 用户说"以后...都要..."、"下次记得..."、"这种情况要先..."、 "帮我把这个习惯固化下来"、"加一条新规则"。

Files · 1

View on GitHub

SKILL.md

1	# paper-writing-discipline：怎么把新坑变成新 skill
2
3	## 核心理念
4
5	skill 不是知识，是踩过坑后才悟出来的纪律。
6	每次踩新坑，都是写一个新 skill 的机会——别让同一个坑再踩第二次。
7
8	> 知识可以查，纪律必须前置。
9
10	---
11
12	## 触发条件
13
14	用户出现以下任一信号 → 触发：
15
16	- 「以后...我都要...」
17	- 「下次记得...」
18	- 「这种情况要先...」
19	- 「这个教训我得记下来」
20	- 「帮我把这个习惯固化下来」
21	- 「再加一条新规则到 skill 里」
22	- 你识别到用户刚踩了一个坑、且这个坑可被规则化避免
23
24	---
25
26	## 4 个判断题（不全过 ≠ 写 skill）
27
28	判断这条新规则是否值得做成 skill：
29
30	```
31	Q1：不用会翻车？
32	├─ 不用没事 → 不是纪律，是偏好 → 不要 skill，写进 CLAUDE.md
33	└─ 不用会翻车 → 进入 Q2
34
35	Q2：是反直觉的？
36	├─ "本来就该这么做"的常识 → 不要 skill（太弱）
37	└─ 必须经历过才懂 → 进入 Q3
38
39	Q3：能在动手前就触发？
40	├─ 只能事后补救 → 不是 skill，是 hook
41	└─ 能在用户提需求时就触发 → 进入 Q4
42
43	Q4：是 HOW 不是 WHAT？
44	├─ 是某个工具的用法 → 写文档 / 教程
45	└─ 是"做事的方式" → 做 skill ✅
46	```
47
48	4 个全过 → 写 skill。任何一个 No → 改用其他形式（CLAUDE.md / hook / 教程）。
49
50	---
51
52	## SKILL.md 模板（直接复制改填）
53
54	```markdown
55	---
56	name: paper-<动词>-<对象>
57	description: \|
58	[一段中文，说清这个 skill 防什么灾]
59	Use when [中文触发条件，列具体场景]。
60	---
61
62	# paper-<名字>：[一句话标题]
63
64	## 核心理念
65	[1-2 句，说清这条纪律的根本原因]
66	> [一句金句，让用户读到就记住]
67
68	## 触发条件
69	满足任一条 → 触发：
70	- [...]
71	- [...]
72
73	## 强制流程
74	\`\`\`
75	[简单流程图]
76	\`\`\`
77
78	## 标准回复模板
79	> [让 AI 能直接套用的话术]
80
81	## ❌ 反例（书 §X.X）
82	[具体翻车故事]
83
84	## Rationalization Table
85	\| 念头 \| 现实 \|
86	\|---\|---\|
87	\| [...] \| [...] \|
88
89	## Red Flags
90	- [...]
91
92	## 来源
93	《Claude Code 科研手记》§X.X
94	```
95
96	---
97
98	## 命名规范
99
100	- 前缀统一 `paper-`（让所有 skill 在 `~/.claude/skills/` 里聚成一组）
101	- 动词开头：`paper-confirm-before-doing`、`paper-backup-before-word`
102	- 描述触发场景，不是描述功能
103	- 只用小写字母 + 数字 + 连字符（YAML 强制）
104
105	\| ✅ 好名字 \| ❌ 坏名字 \|
106	\|---\|---\|
107	\| paper-backup-before-word \| word-backup-system \|
108	\| paper-pilot-before-batch \| batch-task-helper \|
109	\| paper-confirm-before-doing \| task-confirmation \|
110
111	---
112
113	## description 写法
114
115	核心原则：description 写"什么时候触发"，不要写"做什么"。
116
117	\| ✅ 好 \| ❌ 坏 \|
118	\|---\|---\|
119	\| Use when 用户编辑 .docx 文件之前 \| 这是一个 Word 备份工具 \|
120	\| Use when 用户给出模糊润色任务 \| 用来润色论文段落 \|
121	\| Use when 拿到导师录音 / 便条 \| 处理导师反馈的 skill \|
122
123	为什么：description 进入 Claude 的 system prompt，决定它"要不要打开这个 skill"。
124	描述功能 → Claude 不知道何时调用 → 永远不会被触发。
125
126	---
127
128	## 必备 6 个栏目（缺一不可）
129
130	每个 paper-* skill 必须有：
131
132	1. 核心理念（1-2 句 + 一句金句）
133	2. 触发条件（list，要具体）
134	3. 强制流程（流程图 / 步骤）
135	4. 标准回复模板（能直接套）
136	5. Rationalization Table（封掉合理化借口）
137	6. Red Flags（自检停止信号）
138
139	可选：❌ 反例、例外情况、配套 skill、来源。
140
141	---
142
143	## 写完之后的检查清单
144
145	- [ ] 文件名为 `paper-<动词>-<对象>/SKILL.md`
146	- [ ] frontmatter 只有 `name` 和 `description`
147	- [ ] description 以 "Use when" 段为主
148	- [ ] 6 个必备栏目齐了
149	- [ ] Rationalization Table ≥ 4 条（少了不够辛辣）
150	- [ ] 有 1 个具体反例（来自书或用户经历）
151	- [ ] Red Flags 都是"念头/动作"级别，不是"情况"级别
152	- [ ] 用 Read 重新打开自检一遍是否能让一个不知情的 AI 看懂
153
154	---
155
156	## 落盘位置
157
158	写完后放到：
159
160	```
161	~/.claude/skills/paper-<新 skill 名>/SKILL.md
162	```
163
164	之后用户开新会话，这个 skill 就自动出现在系统提示的 skill 列表里。
165	本系列 skill 也可以集中放在 `~/.claude/skills/paper-pack/` 子目录里统一管理。
166
167	---
168
169	## ❌ 反例
170
171	用户："以后我让你改 .tex 文件时，你要先确认编译能过。"
172
173	错误做法：直接写一个 paper-check-latex-compile skill。
174	正确做法：先用 4 个判断题筛——
175
176	- Q1（不用会翻车）：✅
177	- Q2（反直觉）：⚠️ 偏弱，"改完编译"算半个常识
178	- Q3（动手前触发）：✅
179	- Q4（HOW 不是 WHAT）：✅
180
181	→ Q2 偏弱，建议先写进 CLAUDE.md 的"工作纪律"部分。如果用户后续两次都没这么做、又踩了坑，再升级为 skill。
182
183	---
184
185	## Rationalization Table
186
187	\| 念头 \| 现实 \|
188	\|---\|---\|
189	\| "用户的需求很具体，直接照做就好" \| 直接照做产出的是脚本，不是 skill \|
190	\| "4 个判断题太麻烦" \| 不过这 4 题，写出来的是噪音，反而稀释整个体系 \|
191	\| "先写出来，不好用再删" \| 删一个 skill 比加一个 skill 难——它已经污染了 system prompt \|
192	\| "用户说要的，肯定值得做" \| 用户说要 ≠ 是 skill。可能是 CLAUDE.md，可能是 hook \|
193	\| "skill 越多越显得体系完整" \| skill 多到一定程度互相冲突，反而每个都触发不准 \|
194
195	---
196
197	## Red Flags
198
199	- 你跳过 4 个判断题就开始写 → 停
200	- 你写了一个不带 Rationalization Table 的 skill → 不合格，回去补
201	- 你的 description 写的是"做什么"不是"什么时候用" → 不会触发
202	- 你写了第 N 个 paper-* skill 但还没用过 → 先用一周再加新的
203
204	---
205
206	## 来源
207
208	参考 superpowers:writing-skills（适配中文科研写作场景）。

People who liked this also viewed

6 picks

Type

paper-writing-discipline

19stars0forks

View on GitHub

How to install paper-writing-discipline?

lambenthan/paper-discipline-skills/paper-writing-discipline

$npx -y skills add Lambenthan/paper-discipline-skills --skill paper-writing-discipline

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# paper-writing-discipline：怎么把新坑变成新 skill
2
3	## 核心理念
4
5	skill 不是知识，是踩过坑后才悟出来的纪律。
6	每次踩新坑，都是写一个新 skill 的机会——别让同一个坑再踩第二次。
7
8	> 知识可以查，纪律必须前置。
9
10	---
11
12	## 触发条件
13
14	用户出现以下任一信号 → 触发：
15
16	- 「以后...我都要...」
17	- 「下次记得...」
18	- 「这种情况要先...」
19	- 「这个教训我得记下来」
20	- 「帮我把这个习惯固化下来」
21	- 「再加一条新规则到 skill 里」
22	- 你识别到用户刚踩了一个坑、且这个坑可被规则化避免
23
24	---
25
26	## 4 个判断题（不全过 ≠ 写 skill）
27
28	判断这条新规则是否值得做成 skill：
29
30	```
31	Q1：不用会翻车？
32	├─ 不用没事 → 不是纪律，是偏好 → 不要 skill，写进 CLAUDE.md
33	└─ 不用会翻车 → 进入 Q2
34
35	Q2：是反直觉的？
36	├─ "本来就该这么做"的常识 → 不要 skill（太弱）
37	└─ 必须经历过才懂 → 进入 Q3
38
39	Q3：能在动手前就触发？
40	├─ 只能事后补救 → 不是 skill，是 hook
41	└─ 能在用户提需求时就触发 → 进入 Q4
42
43	Q4：是 HOW 不是 WHAT？
44	├─ 是某个工具的用法 → 写文档 / 教程
45	└─ 是"做事的方式" → 做 skill ✅
46	```
47
48	4 个全过 → 写 skill。任何一个 No → 改用其他形式（CLAUDE.md / hook / 教程）。
49
50	---
51
52	## SKILL.md 模板（直接复制改填）
53
54	```markdown
55	---
56	name: paper-<动词>-<对象>
57	description: \|
58	[一段中文，说清这个 skill 防什么灾]
59	Use when [中文触发条件，列具体场景]。
60	---
61
62	# paper-<名字>：[一句话标题]
63
64	## 核心理念
65	[1-2 句，说清这条纪律的根本原因]
66	> [一句金句，让用户读到就记住]
67
68	## 触发条件
69	满足任一条 → 触发：
70	- [...]
71	- [...]
72
73	## 强制流程
74	\`\`\`
75	[简单流程图]
76	\`\`\`
77
78	## 标准回复模板
79	> [让 AI 能直接套用的话术]
80
81	## ❌ 反例（书 §X.X）
82	[具体翻车故事]
83
84	## Rationalization Table
85	\| 念头 \| 现实 \|
86	\|---\|---\|
87	\| [...] \| [...] \|
88
89	## Red Flags
90	- [...]
91
92	## 来源
93	《Claude Code 科研手记》§X.X
94	```
95
96	---
97
98	## 命名规范
99
100	- 前缀统一 `paper-`（让所有 skill 在 `~/.claude/skills/` 里聚成一组）
101	- 动词开头：`paper-confirm-before-doing`、`paper-backup-before-word`
102	- 描述触发场景，不是描述功能
103	- 只用小写字母 + 数字 + 连字符（YAML 强制）
104
105	\| ✅ 好名字 \| ❌ 坏名字 \|
106	\|---\|---\|
107	\| paper-backup-before-word \| word-backup-system \|
108	\| paper-pilot-before-batch \| batch-task-helper \|
109	\| paper-confirm-before-doing \| task-confirmation \|
110
111	---
112
113	## description 写法
114
115	核心原则：description 写"什么时候触发"，不要写"做什么"。
116
117	\| ✅ 好 \| ❌ 坏 \|
118	\|---\|---\|
119	\| Use when 用户编辑 .docx 文件之前 \| 这是一个 Word 备份工具 \|
120	\| Use when 用户给出模糊润色任务 \| 用来润色论文段落 \|
121	\| Use when 拿到导师录音 / 便条 \| 处理导师反馈的 skill \|
122
123	为什么：description 进入 Claude 的 system prompt，决定它"要不要打开这个 skill"。
124	描述功能 → Claude 不知道何时调用 → 永远不会被触发。
125
126	---
127
128	## 必备 6 个栏目（缺一不可）
129
130	每个 paper-* skill 必须有：
131
132	1. 核心理念（1-2 句 + 一句金句）
133	2. 触发条件（list，要具体）
134	3. 强制流程（流程图 / 步骤）
135	4. 标准回复模板（能直接套）
136	5. Rationalization Table（封掉合理化借口）
137	6. Red Flags（自检停止信号）
138
139	可选：❌ 反例、例外情况、配套 skill、来源。
140
141	---
142
143	## 写完之后的检查清单
144
145	- [ ] 文件名为 `paper-<动词>-<对象>/SKILL.md`
146	- [ ] frontmatter 只有 `name` 和 `description`
147	- [ ] description 以 "Use when" 段为主
148	- [ ] 6 个必备栏目齐了
149	- [ ] Rationalization Table ≥ 4 条（少了不够辛辣）
150	- [ ] 有 1 个具体反例（来自书或用户经历）
151	- [ ] Red Flags 都是"念头/动作"级别，不是"情况"级别
152	- [ ] 用 Read 重新打开自检一遍是否能让一个不知情的 AI 看懂
153
154	---
155
156	## 落盘位置
157
158	写完后放到：
159
160	```
161	~/.claude/skills/paper-<新 skill 名>/SKILL.md
162	```
163
164	之后用户开新会话，这个 skill 就自动出现在系统提示的 skill 列表里。
165	本系列 skill 也可以集中放在 `~/.claude/skills/paper-pack/` 子目录里统一管理。
166
167	---
168
169	## ❌ 反例
170
171	用户："以后我让你改 .tex 文件时，你要先确认编译能过。"
172
173	错误做法：直接写一个 paper-check-latex-compile skill。
174	正确做法：先用 4 个判断题筛——
175
176	- Q1（不用会翻车）：✅
177	- Q2（反直觉）：⚠️ 偏弱，"改完编译"算半个常识
178	- Q3（动手前触发）：✅
179	- Q4（HOW 不是 WHAT）：✅
180
181	→ Q2 偏弱，建议先写进 CLAUDE.md 的"工作纪律"部分。如果用户后续两次都没这么做、又踩了坑，再升级为 skill。
182
183	---
184
185	## Rationalization Table
186
187	\| 念头 \| 现实 \|
188	\|---\|---\|
189	\| "用户的需求很具体，直接照做就好" \| 直接照做产出的是脚本，不是 skill \|
190	\| "4 个判断题太麻烦" \| 不过这 4 题，写出来的是噪音，反而稀释整个体系 \|
191	\| "先写出来，不好用再删" \| 删一个 skill 比加一个 skill 难——它已经污染了 system prompt \|
192	\| "用户说要的，肯定值得做" \| 用户说要 ≠ 是 skill。可能是 CLAUDE.md，可能是 hook \|
193	\| "skill 越多越显得体系完整" \| skill 多到一定程度互相冲突，反而每个都触发不准 \|
194
195	---
196
197	## Red Flags
198
199	- 你跳过 4 个判断题就开始写 → 停
200	- 你写了一个不带 Rationalization Table 的 skill → 不合格，回去补
201	- 你的 description 写的是"做什么"不是"什么时候用" → 不会触发
202	- 你写了第 N 个 paper-* skill 但还没用过 → 先用一周再加新的
203
204	---
205
206	## 来源
207
208	参考 superpowers:writing-skills（适配中文科研写作场景）。

People who liked this also viewed

6 picks

Type