distill-my-life

Distill — 每日蒸馏

Luci 的 Life 页面会将这些文件作为数据读取。YAML 和 ## 标题 构成架构。标题下的正文会按原样显示。不要臆造架构未定义的字段。

Step 0：确保 life 文件系统

life 文件系统始终位于用户的主目录下，而不是当前仓库中：

• macOS / Linux：~/.Life
• Windows：%USERPROFILE%\.Life

如果 ~/.Life 不存在，请创建它。然后确保目录结构如下：

~/.Life/
  reflections/daily/          # daily reports (YYYY-MM-DD.md)
  entities/
    people/                   # people
    orgs/                     # organizations
    projects/                 # projects
    tools/                    # software tools

创建所有缺失的目录。不要事先询问。不要删除或移动已有内容。不要写入当前工作目录。

然后仅在 ~/.Life 中查找文件系统索引：

• 如果 ~/.Life/CLAUDE.md 存在，请使用它。
• 否则，如果 ~/.Life/AGENTS.md 存在，请使用它。
• 如果两者都不存在，请使用此技能中的默认设置（英文、按小时分块、不向外部发送）。不要创建索引文件——Luci 会在首次启动时写入这两个文件。

如果索引存在，请遵循其中的写作规则、每日报告格式和外部连接器配置。缺少的键使用上述默认设置。

Step 0.5：读取用户的规则

如果 ~/.Life/RULES.md 存在，请读取它。该文件由用户手动编写，说明谁是谁、哪些人或内容应排除，以及报告应如何撰写。

• 在本次运行的整个过程中遵循该文件。如果它与索引或此技能有冲突，以规则文件为准。
• 如果文件要求排除某个人、应用、网站或主题，该内容就不得出现在任何地方——既不能出现在每日日志文件中，也不能出现在实体文件或最终输出中。
• 绝不要写入 RULES.md。 不要创建、整理或重新格式化它，也不要将你了解到的信息附加到其中。它是用户的文档；Distill 只读取它。
• 文件不存在或无法读取时，请使用默认设置。不要创建文件。

Step 1：确定要处理的日期

• 写入任何内容之前，检查 ~/.Life/reflections/daily/ 中是否有匹配 YYYY-MM-DD.md 的文件。如果一个都没有，请记住这一点——这意味着今天的运行可能是本机上的首次蒸馏，这会影响 Step 4。
• 通过 Bash 获取今天的日期（切勿凭记忆猜测）。
• 日期范围：从上次完整蒸馏到昨天。只有 YAML 前置元数据同时包含 date 和 observation 时，每日文件才算完整。缺少这些键的文件视为缺失——请重新写入。
• 只处理已过完的日期——昨天及更早的日期。绝不要处理今天。
• 仅当某个日期已有完整文件时才跳过该日期。
• 如果积压超过 7 天，只处理最近 7 天，并在末尾明确列出跳过的日期。
• 即使某一天完全没有数据，也要生成完整文件：包含 YAML 和一个 observation，且不包含任何 ## 捕获区块。绝不要捏造内容。
• “没有数据”是指该日的每条 Luci 命令都以退出码 0 结束且没有返回任何内容。命令失败的日期不算无数据日。请参阅 Step 2。

Step 2：写入每日日志文件

通过 Luci CLI 获取当天的活动，然后写入 ~/.Life/reflections/daily/YYYY-MM-DD.md。按日期从早到晚处理。

从 Luci 提取某一天的数据

按照 luci 技能中的说明解析 <CLI>（先查找 discovery 文件，再查 PATH）。不要先运行 status：status 不会启动 Luci，而实际命令会在后台启动它并等待其就绪。下面的第一次 usage 调用是预检。

时间范围使用本地时间的 epoch 毫秒，格式为 <fromMs>:<toMs>。通过 shell 获取当天的午夜时间，切勿凭记忆填写：

• macOS：date -j -f '%Y-%m-%d %H:%M:%S' 'YYYY-MM-DD 00:00:00' +%s，然后 * 1000
• Linux：date -d 'YYYY-MM-DD 00:00:00' +%s，然后 * 1000
• Windows：[DateTimeOffset]::new([datetime]'YYYY-MM-DD').ToUnixTimeMilliseconds()

toMs 是次日午夜减 1。

1. 屏幕：<CLI> usage --tr <fromMs>:<toMs> --limit 500 --json。limit 是硬性上限，且 CLI 不支持分页，因此如果恰好返回 500 条记录，就按小时重新运行（24 个范围）并合并结果。
2. 音频：针对屏幕记录中出现的两三个主题（会议名称、项目名称），运行 <CLI> transcript "<keyword>" --tr <fromMs>:<toMs> --limit 500 --json。没有“全部音频”命令。
3. 详情：仅对文本过少、无法判断归属的记录运行 frame <ID>。

读取每条命令的退出代码：

• 0 且有记录：使用这些记录。
• 0 且没有记录：表示确实没有数据。如果当天的所有命令都没有记录，则将这一天写为无数据。
• 3：命令格式错误。根据 <CLI> --help 修正后重新运行。这绝不是用户的问题。
• 2 且标准错误中包含 "didn't respond in time"：将该范围的 --limit 调小或改为按小时运行，然后重试一次。如果再次失败，就停止。
• 2 且包含其他消息，或 1：停止。

停止意味着：不要为这一天写入每日文件，不要处理之后的日期，不要根据部分结果写入实体，也不要退而求其次进行猜测。之前日期已写入的文件保留。报告出错的日期，并逐字报告 CLI 标准错误中的那一行（该内容面向用户，且不含路径）。然后等待用户修复 Luci 并重新运行。 Luci 已安装时不应出现这些故障；不要反复重试，也不要尝试使用其他工具。

YAML（必填）

每个每日文件都必须以此 frontmatter 开头。observation 写成一个句子。slug 与实体文件名相同，不带 .md。列表为空时使用 []。始终使用 > 折叠 observation，避免句子中的冒号导致文件格式错误：

---
date: 2026-08-24
samples: 187
audio_segments: 148
first: "01:21"
last: "23:06"
observation: >
  Only 37 minutes of captured screen time before the 21-hour gap, and all
  of it went into recording and re-recording the same talk.
projects:
  - microsoft-luci-electron
people:
  - matt-pocock
orgs: []
---

samples 是当天 usage 返回的屏幕记录数量。 audio_segments 是你看到的不同转录片段数量；如果没有运行转录查询，则省略此字段。first 和 last 是最早和最晚屏幕记录的本地时间。仅当未查询相应数据源时才省略字段，绝不能因为命令失败而省略（命令失败意味着第 2 步已停止，且不会写入此文件）。

不要在正文下方再次写入 observation。Life 页面会读取 YAML 字段。

正文

frontmatter 之后：

1. 使用英文星期名称，格式为 # YYYY-MM-DD (Weekday)。
2. 用一段简短文字说明屏幕记忆的局限。
3. 按小时分块。根据时间戳对齐屏幕活动和实时转录。只写客观内容。若来源不确定，则省略。

标题格式固定。时间之间使用短横线。标题或空档标签前使用长破折号。不得使用其他形式的 ## 标题：

## HH:MM–HH:MM
## HH:MM–HH:MM — title
## HH:MM–HH:MM — no samples ({duration})

空档只写标题，不写正文。绝不要编造时间段来填补空档。绝不要只写一个时间戳而不写结束时间。

步骤 3：编写实体

总结时，留意人物、组织、项目和软件工具。

先读取 ~/.Life/entities/。为当天证据中出现的每个实体编写文件——不要询问：

• 人物 → ~/.Life/entities/people/<slug>.md
• 组织 → ~/.Life/entities/orgs/<slug>.md
• 项目 → ~/.Life/entities/projects/<slug>.md
• 软件工具 → ~/.Life/entities/tools/<slug>.md

Slug：小写 ASCII 字符、数字和连字符。如果该名称已有文件，请复用现有文件名（匹配 YAML name 或 # 标题）。

新文件：

---
name: Microsoft-Luci-Electron
kind: project
---

# Microsoft-Luci-Electron

- 2026-08-24: eight threads still in flight, including Insights unlock

kind 为 person、org、project 或 tool。

现有文件：

• 如果缺少 YAML，在当前正文上方插入 name / kind frontmatter。不要删除正文。
• 如果当天日期尚未作为 - YYYY-MM-DD: 列表项出现，则追加一项。
• 绝不编辑现有列表项。绝不将正文改写成摘要。

步骤 4：首次使用通知

只有当 ~/.Life/reflections/daily/ 在本次运行前（步骤 1）没有任何 YYYY-MM-DD.md 文件，且步骤 2 至少写入了一个每日文件时，才向 Luci 的本地通知中心添加一条祝贺通知，使其在下次打开应用时显示。此操作最多执行一次——如果已存在 id 为 first-distill 的条目，则完全跳过。

1. 查找 Luci 的配置文件：

   • macOS：~/.luciMicrosoft/luci-config.json
   • Windows：%USERPROFILE%\.luci\luci-config.json
   • Linux：~/.luci/luci-config.json

2. 如果文件不存在，则跳过此步骤——Luci 从未在此处运行过。

3. 将整个文件作为 JSON 读取。如果解析失败，则跳过此步骤；绝不覆盖无法读取的配置文件。

4. 文件中有一个 notifications 键，其值为数组（如果不存在，则按 [] 处理）。如果该数组中已有任何条目的 "id": "first-distill"，则跳过——通知已发送。否则，将此对象添加到数组最前面，且不改动文件中的其他键：

   {
     "id": "first-distill",
     "kind": "distill",
     "title": "You just distilled your first day!",
     "body": "Your first daily report is in ~/.Life. Keep it up and Luci will build a real picture of your work over time.",
     "at": <current time as epoch milliseconds>,
     "read": false,
     "to": "/v2/life"
   }
   

5. 将整个 JSON 对象写回同一路径，并原样保留其他所有键。

此操作只会让通知在下次打开或重启应用时显示——Luci 不会实时监视此文件。

步骤 5：个人档案

写入所有每日文件和实体后，判断是否需要更新用户的个人档案 ~/.Life/profile.md：

• 如果启动本次运行的提示词中包含 ## Then write the profile 章节，或说明当前不需要更新个人档案，则 Luci 已经做出决定。按其要求执行，并跳过此步骤的其余部分。
• 否则，符合以下任一条件时需要更新：
  • ~/.Life/profile.md 不存在，且 ~/.Life/reflections/daily/ 中至少有 3 个每日文件；或
  • 该文件存在，且其 frontmatter 中的 updated: 日期早于今天 7 天以上。

需要更新时，使用 luci-profile 技能编写：文件不存在时创建首份个人档案，否则每周重写。如果没有该技能，请先从 https://github.com/Memories-ai-labs/Luci-skills 安装。如果不需要更新，则不写入任何内容。

最终输出

• 步骤 0 中创建的文件夹（如有）。
• 已生成报告的日期（列出文件路径），包括因缺少 YAML 而重写的日期。
• 跳过的日期及原因。
• 如果 Luci 命令执行失败：失败日期、CLI 的原始错误消息，以及未处理之后任何日期这一事实。
• 已写入或追加的实体文件（如有）。
• 是否找到并应用了 ~/.Life/RULES.md。
• 是否发送了步骤 4 的首次使用通知。
• 步骤 5 是否写入了个人档案（首份或每周重写），或者未更新的原因。
• 如果 ~/.Life/CLAUDE.md 或 ~/.Life/AGENTS.md 中配置了外部连接器，则通过该连接器发送一条摘要消息（每次运行恰好一条）；如果未配置，则不发送。