chore(skills): add learn-tidy skill for tidying practice code

- codifies the js_notes/ wrap-up workflow: run real output, turn mistakes
  into ❌/✅ traces, fix wrong result-comments, selectively absorb into
  my-mistakes.md, flexible commit decision

.claude/skills/learn-tidy/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: learn-tidy
+description: >
+  整理用户在 js_notes/ 学习练习里刚写完或改完的代码 —— 跑真实输出、把错法整理成
+  ❌/✅ 对照痕迹、修正写错的结果注释、把有教益的新错误吸收进 my-mistakes.md。
+  当用户说「整理」「整理一下」「tidy」「收拾干净」「帮我整理这段/这题」,或刚做完一章练习、
+  刚改完一段试验代码、留下了对错混杂的多版尝试时,主动用这个 skill。它是这个学习仓库
+  反复要做的收尾动作,专门服务 js_notes/ 的教学约定,别用内置 code-review 代替。
+---
+
+# learn-tidy · 整理学习练习代码
+
+把用户刚写/改的练习或试验代码"收拾干净",让它成为将来复习时**看得懂、可追溯、能跑**的
+学习痕迹。这是本仓库(30-Days-Of-JavaScript)`js_notes/` 反复要做的收尾动作。
+
+先读 `CLAUDE.md` 与 `js_notes/README.md` 里的辅导规则(它们是**具有约束力的**),本 skill
+是那套规则在"整理"这个动作上的具体落地,不得与之冲突。
+
+## 什么时候用
+
+- 用户说「整理」「整理一下 / 这段 / 这题」「tidy」「收拾干净」
+- 用户刚做完一章练习(A–F 之类)、或刚改完一段 `// 试验 / 探索` 代码
+- 文件里留下了**对错混杂的多版尝试**(比如 3 行 reduce、2 个同名 const)
+
+## 核心原则(为什么这么做)
+
+成品是**文件**,不是聊天:将来的用户只会翻文件,不会翻对话记录。所以整理的目标是让文件
+**自解释**——一眼看到"错在哪、为什么错、正解是什么"。而且**绝不留能跑的坏代码**:错的要么
+删、要么注释成对照,活代码必须是对的。
+
+## 流程(按顺序做,别跳步)
+
+### 1. 先读,再跑真实输出(绝不凭记忆)
+
+- Read 目标文件相关段落,搞清哪些是用户的练习答案、哪些是试验、哪些是还没动的「轮到你」。
+- **跑 `node js_notes/NN-topic.js`** 拿到**真实输出**。需要只查语法时先 `node --check`。
+- 临时验证可写 `/tmp/*.js` 跑,但**结论必须落进正式文件**,别把只存在于 /tmp 或聊天里的
+  结果当交付。
+- 用真实输出对照用户写的"预期注释"——**注释写错的结果要改对**(这是高频问题,例如用户
+  写 `// "修改y的name"` 但实跑是 `fn`)。
+
+### 2. 把错法整理成 ❌ / ✅ 对照(留学习痕迹)
+
+对用户犯过的错、或对错混杂的多版尝试:
+
+- **错的那版注释掉**(绝不留能跑的坏代码),放在**正解上方**。
+- 加一行简短 `// ❌ 原因` 说清*为什么*错;正解用 `// ✅` 标出、留作**活代码**。
+- 多版尝试(如 3 行 reduce)收敛成:错的都注释成 ❌ 对照,最优的一版留活代码。
+- 若某版"能救回来但不优雅",可用 `// 🔸` 标注中间方案,但活代码留最干净的那版。
+
+风格对齐用户已在 `06-arrays.js` / `07-objects.js` / `10-functions.js` 用的写法:
+
+```js
+// ❌ ^ 在 JS 是"按位异或"不是乘方:8^2=10、和平方无关
+// console.log(nums.filter(n => n % 2 === 0).map(n => n^2))
+// ✅ 乘方用 **(或 n*n)
+console.log(nums.filter(n => n % 2 === 0).map(n => n ** 2)) // [ 64, 100 ]
+```
+
+### 3. 决定要不要吸收进 my-mistakes.md(关键判断,别做流水账)
+
+**不是所有错误都记。** `my-mistakes.md` 是"复习时值得回看的坑",不是错误日志。三档处理:
+
+| 情况 | 怎么办 |
+|---|---|
+| 新的、有教益的坑(尤其"能跑不报错"的概念坑) | ✅ 新开一条 |
+| 已有条目的重演 / 变体 | 🔸 不新开,在原条目**补一句**新情境 |
+| 纯手误 / 已被现有条目覆盖 / 用户已自己改好且无新东西可学 | ❌ 不记 |
+
+新开条目沿用现有格式:**错法 → 现象 → 正解/根源 → 教训**,并带 `📍来源`(文件 + 练习号)。
+能跑不报错的坑标 ⭐,概念性推错(非手误)可标 ⭐⭐ 并注明"概念推错,非手滑"。若坑对应某个
+报错信息,顺手更新末尾的「高频报错 → 秒查表」。
+
+**拿不准值不值得记时,问用户。**(用户明确说过:记流水账他会反驳。)
+
+### 4. 不碰用户还没做的练习
+
+「轮到你」里用户**还没动手**的题,**绝不**往里写解答(哪怕注释掉也不行,会剧透)。整理只针对
+用户**已经写了**的答案/试验。
+
+### 5. 跑一遍验证 + 收尾
+
+- 改完后再 `node js_notes/NN-topic.js`(或 `node --check`)确认整章能跑、输出符合预期。
+- 如果这次整理正好是"一章练习全部做完",可按 `CLAUDE.md` 的「一章收尾必做清单」把 README
+  进度勾选也带上。
+
+### 6. commit —— 灵活判断,别默认执行
+
+**不要每次整理都自动 commit。** 由具体情形决定:
+
+- 若这次整理是一个**逻辑完整的收尾**(一章做完、或一段独立讲解落定),且工作区就这些改动
+  → 可以提议 commit,并给出 Angular 风格 message(`docs(js_notes): ...`),**先说清要提交什么**。
+- 若还在**中途**(用户可能马上继续改)、或工作区混着其它未完成改动 → **先别 commit**,
+  只把整理做好、告诉用户"整理完了,要提交时说一声"。
+- 拿不准时,问用户要不要提交,而不是擅自 commit。
+
+commit 前遵守 `CLAUDE.md` 的 Git 约定:干净拆分、绝不提交私密内容、不丢弃用户工作。
+
+## 结束时给用户的话
+
+简短汇报:跑出来的真实输出、留了哪些 ❌/✅ 痕迹、有没有(以及为什么)动 my-mistakes、
+要不要 commit。别长篇复述文件内容——用户会自己翻文件。