Menu
将会话内容按主题聚合写入 Obsidian 工作日志或个人日记，并管理待办。当用户说「记录一下」「写日记」「更新待办」等要求记录时，或在会话末尾出现结构化结论/部署完成/调研成果时加载此技能，主动询问用户是否记录。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
将所有机器上的 Pi 和 OMP 会话整理成主题聚合的结构化日报，可选写入 Obsidian 工作日志。
往 pi 的 models.json 新增/适配 provider 模型，含取参、思考三层合成、capture.ts 实测验证与固定。
按需求从 npm pi-package 生态检索符合的 Pi Agent 扩展/技能/主题/prompt 包，采集 npm 元数据与 GitHub 信号，质量评估后整理成表格。与 pi-trending 互补（后者做热度发现）。
Free up disk space on Arch Linux WSL through layered cleanup: cache purge, orphan removal, package audit, and large file scanning. Use whenever the user mentions disk space, cleanup, storage, package review, or wants to shrink their WSL footprint — even if they just say "空间不够", "磁盘满了", "WSL 太大了", or "clean up my system". Prefer this skill over ad-hoc cleanup commands on Arch WSL.
Search and rewrite code by AST structure across 25 languages with ast-grep (sg). Use when the task is structural - find function calls shaped like X, rewrite console.log to logger.info, find all `as any`, migrate require() to import, find empty catch blocks, missing await, codemod a class hierarchy, scan project against YAML rules. Preferred over grep when the user mentions code SHAPE or needs deterministic refactoring across many files. Triggers: 'ast-grep', 'sg', 'ast grep', 'astgrep', 'find all functions that', 'find every call to', 'codemod', 'structural search', 'pattern match code', 'replace pattern across files', 'rename function everywhere', 'find usages of pattern', 'apply this transformation to all', 'migrate X to Y'.
Audit installed Hermes Agent skills for usage frequency and generates an interactive XLSX with Chinese descriptions, dropdown decision columns, and color-coded recommendations. Supports apply mode: reads decisions from XLSX and executes cleanup (delete/disable/enable) after user confirmation, with automatic backup. Smart filtering: already-disabled skills are not re-suggested for cleanup. Uses hermes internal API for authoritative skill classification (builtin/hub/local/external). Use when the user asks about Hermes skill usage statistics, wants to clean up unused Hermes skills, needs to disable low-usage skills, or mentions "技能审计", "清理技能", "不用的技能", "哪些技能可以删", "技能热度", "技能使用频率", "audit hermes skills". This skill is specific to Hermes Agent — do not use for other agents. Make sure to load this skill whenever Hermes skill management, cleanup, or usage analysis is mentioned.
| name | obsidian-diary |
| description | 将会话内容按主题聚合写入 Obsidian 工作日志或个人日记，并管理待办。当用户说「记录一下」「写日记」「更新待办」等要求记录时，或在会话末尾出现结构化结论/部署完成/调研成果时加载此技能，主动询问用户是否记录。 |
将当前会话的内容总结并写入 Obsidian 日记，同时搜索、更新、新增待办。
日记的目的是给人看的记录，不是 agent 工作日志。它的价值在于几个月后翻回来看还能知道那天发生了什么、为什么做了某个决策。所以必须做两件事：按主题组织（而不是按对话时间顺序平铺），合并相关事件（而不是一条一条回忆 dump）。
以下规则必须严格遵守，不因任何工作流步骤或上下文而改变。
只写会话/工具输出中有明确证据的内容。禁止添加虚构细节：不要写"根据习惯""顺手翻了翻""一般来说""按我的经验""社区也掉过坑"等会话未提供的信息。日记是真实记录，不是润色后的故事。
人称规则：涉及用户的感受、偏好、评价时，如果用户没有亲口说，不要替用户写。（✅ "记录一下" -> 用户说的。❌ "这是用户最介意的痛点" -> 用户没这么说。）不确定时只写客观事实，不写第三人称心理描述。
路径格式：{日记目录}/YYYY/MM/YYYY年M月D日星期X.md。关键约束：目录用纯数字（2026/05/），只有文件名含中文日期字符。完整对照表和常见错误见 references/diary-rules.md。
陷阱：用 write_file 直接写平级路径会创建错误位置的文件。先用 uv run --script scripts/obsidian-helper.py --vault <变体> 查看 DIARY_PATH 后再写入。
⚡ 用户指定优先：如果用户明确说了「记工作日志」「写个人日记」「记录到 personal」「更新工作日志」等变体指示，直接遵从用户的选择，不要用下面的判断规则覆盖。变体判断表只在用户没有明确指定时使用。
根据会话内容判断使用哪个变体：
| 场景 | 变体 | 判断依据 |
|---|---|---|
| 公司 Git 仓库的代码开发/运维 | work | 公司仓库、团队协作、交付物 |
个人 GitHub 仓库（如 pi-extensions、opencode fork） | personal | 独立项目、非公司交付物 |
| 下班后学的新技术（与公司项目无关） | personal | 个人技能提升 |
| 工作相关但属于个人探索性质的原型验证 | personal | 非交付物、非正式项目 |
| 混合内容（同一会话既有工作又有个人） | 拆分记录 | 分别写入两个变体 |
判断核心：内容是不是公司交付物/团队协作？ 是 -> work；否 -> personal。不要因涉及代码/Git 操作就自动归 work。
为什么切分？受众和用途不同。 工作日志会被同事和管理层查看（或作为日报素材），需要正式、客观、按子系统组织。个人日记只有自己看，可以更轻松，按自己的兴趣领域组织。混合内容时拆分后分别写入两个变体--投资分析归 personal，线上故障排查归 work。
脚本运行前需要配置文件 ~/.config/cnife-skills/obsidian-diary.json。
当脚本输出 CONFIG_MISSING=true 时，脚本会打印完整配置示例（含 base/diary_dir/template/exclude_meta 字段）。执行以下流程：
base 字段填入用户提供的路径，其余字段用默认值，除非用户明确要求修改）所有文件系统操作通过 scripts/obsidian-helper.py 完成，脚本路径相对于本 skill 目录。
必须使用 uv 运行（自动管理依赖）：
uv run --script scripts/obsidian-helper.py --vault <work|personal>
即使今天日记已存在，也要先运行脚本获取当日全文，用 patch 追加而非 write_file 覆盖。
在以下时机主动询问用户是否需要记录，不要自行写入：
询问格式：
如果没有会话上下文（例如在空会话或新对话中被调用），先问用户今天做了什么，再提议记录。
uv run --script scripts/obsidian-helper.py --vault <变体>
输出包含四个段落，一次拿齐：
日记不存在时脚本会自动从模板创建。
这是区分「流水账」和「好日记」的关键。不要直接按对话时间顺序写--先做主题分析。
扫描整个会话（包括工具输出），列出所有独立的主题。例如今天的会话如果包含 install daisy -> 分析中创智领 -> 跑红利筛选 -> 分析三只持仓 -> CouchDB 部署 -> Git 备份 -> SMB 备份，第一轮清单是 7 个 topic。
把语义相近的 topic 合并为同一个主题域。判断依据：这些事是否属于同一个目的或领域？ 聚合示例（好/坏对照）见 references/diary-rules.md 的 personal/work 变体好例子。
# 标题，其下用子 bullet 展开新内容能塞进已有章节的，不新开一段。 例如今天继续做投资分析，而日记里已经有 # 金融研究 段落，就在那个段落追加新 bullet，不要另起 # 金融研究（续）。
没找到对应章节的 -> 创建新的一级标题，插入到日记末尾（待办块之后）。
同一篇日记内，按重要性排序主题--通常工作/分析类在前、配置类在后。个人日记可以参考：投入时间多的 > 产出多的 > 顺手做的。
每个主题域内，从会话中识别关键事件，每个事件 1-2 行：
| 事件类型 | 记录要点 |
|---|---|
| 实现了功能 | 功能名称 + 核心特性 + 关键技术决策 |
| 调研了方案 | 调研对象 + 结论 + 选型判断（为什么选 A 不选 B） |
| 修复了问题 | 问题 + 根因 + 修复方式 |
| 做了决策 | 决策内容 + 理由 + 放弃的替代方案 |
| 部署/配置 | 环境 + 关键参数 + 验证结果 |
为什么只写 1-2 行？日记是索引，不是完整文档。 详细配置、代码片段、完整对话记录在独立文件里，日记只写结论和 links。几个月后翻回来看，看到一行就能想起当天做了什么；细节可以通过 link 或搜索找回。
使用 Edit（patch）工具直接编辑日记文件：
# 标题 + 内容示例：
# context 输出显示今日日记已有章节：
# Genos Reg Server
## 生产环境故障排查与修复
## IGV 可视化 Access forbidden 修复
# OneReason Backend
# 新内容（Genos 部署记录）的第 6 行后有 # Genos Reg Server，应在第 17 行之前插入
# 新主题如 # CouchDB 同步部署 -> 在文件末尾追加
更新已有段落（补充、修正、状态变更）：
更新历史待办：将对应文件中的 - [ ] 改为 - [x]，添加 ✅ YYYY-MM-DD，同时在今日日记添加 Obsidian 链接：
- [x] 任务描述 ✅ 2026-04-19 完成于 [[2026年4月15日星期三##任务标题]]
为什么加日期？因为 Tasks 插件按完成日期查询。 不加日期的话，回看时只知道"做过"，不知道什么时候做的，无法做周/月回顾。
本次会话产生的新待办，添加到今日日记末尾：
- [ ] 描述📅 YYYY-MM-DD动笔之前，在心里打好草稿，逐项检查以下 3 个 blocker。任一 blocker 不通过 -> 必须先修正草稿再写入文件：
| Blocker | 检查项 | 不通过则 |
|---|---|---|
| ① 事实虚构 | 每条 bullet 是否能追溯到会话中的具体对话或工具输出？不要写"根据习惯""随手""一般来说"等无来源内容 | 删除虚构内容 |
| ② 结构散乱 | 是按主题域聚合而非按时间流程平铺？新内容是否塞进了今日日记已有章节？ | 重新聚合主题 |
| ③ 流程噪音 | 是否混入了 agent 操作日志（Git 提交、验证流程、开发阶段标记、AGENTS.md 规则沉淀、配置文件路径、发布部署操作）？ | 删除噪音，只保留人的结论和决策 |
门禁未通过时不得确认。全部通过后，在内容摘要之前加一行门禁报告：
自检：事实✅ 结构✅ 噪音✅
新增的日记条目：
...
⚠️ 门禁报告只出现在确认摘要中，不要写入日记正文。
内容摘要：
如果本次没有实质性内容，询问用户是否仍要写入。
使用 Tasks 插件标准状态：
| 标记 | 状态 | 用途 |
|---|---|---|
[ ] | 待办 | 未完成的任务 |
[x] | 已完成 | 完成的任务，末尾加 ✅ YYYY-MM-DD |
[-] | 已取消 | 不再需要的任务，末尾加 ❌ YYYY-MM-DD |
可选状态（按需使用）：
[/] 进行中 - 已开始但未完成[>] 延期 - 推迟到以后[!] 重要 - 高优先级[?] 疑问 - 需要确认[h] 搁置 - 等待外部条件跨文件引用已完成待办时，使用 Obsidian 链接：[[日期文件名#任务标题]]
个人日记中涉及成人/R18 内容时使用隐喻和省略，不要直白描写。
只针对 R18 内容做隐晦化处理，不限制其他内容。