journal-reflection

日志反思

结构化反思，不再为日常记录添加多余负担。四种模式。选一种，简洁完成。

何时使用

用户要求反思、回顾或记录所学内容时触发。不用于晨间简报——这类需求转交给 daily-brief。

模式选择

用一个提示词一次性询问适用哪种模式。如果用户只说“写日志”但未指定模式，则默认使用日终模式。

1. 日终（5 分钟）：用 3 个问题回顾今天
2. 周终（15 分钟）：用 5 个问题回顾本周，并扫描规律
3. 决策回顾：用 4 个问题回顾一项过去的决策
4. 学习日志：记录一个新框架或概念，并联系 Ane 已经了解的内容
5. 交付后记录（2 分钟）：完成交付后，用 4 行记录“我学到了什么”，并追加到持续更新的日志中。比模式 4 更轻量（不深入探讨框架）；由交付触发，而非由概念触发。/wrap-up 会在会话结束时提供此选项；Ane 也可以随时直接触发。

各模式的提示词

日终

一次提一个问题，每次等待用户回答：

1. 今天完成了什么重要的事？（不是任务清单——而是什么真正“有进展”）
2. 什么事情造成了阻碍，代价是什么？
3. 明天有什么需要你做、而今天不需要的事？

最后总结：明天的一项承诺，用一句话表达，以动词开头。

周终

一次提一个问题：

1. 对照本周明确的目标，实际进展如何？（不要使用百分比）
2. 本周出现了哪些上周也出现的规律？
3. 你对工作本身，或对自己如何完成工作，有了什么新的认识？
4. 下周你会做哪些改变？具体、轻量、可验证。
5. 有什么值得称为胜利、但你还没有说出来的事？

最后总结：下周要留意的一种规律。

决策回顾

询问：

1. 当时做了什么决定？是什么时候做的？
2. 当时你掌握哪些信息，又有哪些只是猜测？
3. 此后的几天或几周发生了什么？
4. 如果今天再次面临这个决定，你会做出哪些不同的选择？

最后总结：一条要沿用的规则，用“如果……那么……”的形式表达。

学习日志

询问：

1. 这个概念或框架是什么？如果有作者和年份，请注明。
2. 它解决了什么旧框架无法解决的问题？
3. 它与 Ane 已在使用的什么内容有关联？
4. Ane 会首先在哪里应用它？

交付后记录

一次提一个问题。每个回答控制在一行；这是快速记录，不是完整反思。

1. 这项交付让你对工作有了什么新的认识？
2. 下次你会怎么做得不同？
3. 一件值得沿用的事。
4. 有什么做得不错、值得重复？（提取成功经验）

如果第 4 个回答提到一种可重复的系统行为（提示词模式、工作流、专家或模型选择），可以询问是否也将其记录为一条 feedback 记忆，并包含 Why: 和 How to apply: 两行——只需询问一次是或否，不要施压。这样，/improve-system 就能追踪已确认的成功做法，而不仅仅是修正事项。

如果 Ane 给交付起了名称或 slug，就使用该名称；否则请用户提供一个 2–4 词的标签。此模式会追加到一个持续更新的日志中（见“文件放置”），而不是每条记录单独创建一个文件。

输出格式

写入兼容 Obsidian 的 Markdown，并包含 YAML frontmatter：

---
date: YYYY-MM-DD
type: [daily | weekly | decision-review | learning-log]
tags: [journal, ...domain tags]
dg-publish: false
---

人物、概念、框架和项目使用 [[wiki-links]]。默认将 dg-publish 设为 false。如果用户表示笔记可以发布，则设为 true，并询问永久链接的 stub。

正文结构：每个提示词对应一个 H2 标题，答案以纯文本写在标题下；除非内容是列表，否则不要使用项目符号。

文件放置

Vault 根目录：OBSIDIAN_VAULT_ROOT（C:/Users/AGasser/OneDrive/Ane Obsidian Vault — 参见 ~/.claude/CLAUDE.md 中的路径常量表）。如果 Vault 路径可访问，请使用 Write 工具直接写入：

• 日终：5 JURNAL/5a Daily Notes/YYYY-MM-DD.md
• 周终：5 JURNAL/5b Weekly Notes/YYYY-Www.md
• 决策回顾：5 JURNAL/Decisions/YYYY-MM-DD-<slug>.md
• 学习日志：5 JURNAL/Learning/<slug>.md
• 交付后记录：追加到 5 JURNAL/Learning/deliverable-learning-log.md（单个持续更新的日志）。如果文件不存在，创建文件并添加 YAML frontmatter（type: learning-log）和一个 H1 标题，然后添加第一条记录。如果文件已存在，追加一个新的 ## YYYY-MM-DD — <deliverable label> 部分，将四个答案作为项目符号列出，并确保此前的所有记录逐字节保持不变（编辑保留）。

如果 Vault 路径不可访问（网页会话、其他设备），请在回复中返回 Markdown，并注明目标路径，以便用户手动保存。

写作规则

遵循 CLAUDE.md 的风格规范。有一项例外：如果 Ane 的回答本身带有反思性质，日志回答中可以使用被动和反思式表达。不要把她的话改写成主动语态——准确保留她的表达方式。

限制

不要编造反思内容。不要自动回答提示词。提示词应交给用户并等待回答。如果用户跳过某个提示，将该部分标记为 (skipped) 并继续。不要说教。

编辑保留协议

如果 Ane 引用了某个现有输出的路径，并要求改进、迭代或扩展该内容，则启用此协议。先读取文件，通过 Edit 工具在限定范围内修改，并确保范围外的内容逐字节保持不变，然后返回 EDIT-PRESERVATION DELIVERY 摘要。

当目标文件存在时，应用 mel_wiki/wiki/concepts/edit-preservation-protocol.md。