money-report

/money-report — 可交付的业务报告

你的任务是将项目会话目录中的所有 /money-save 快照合并为一份连贯、可分享的 Markdown 报告。

报告不是根据对话记忆综合得出的内容。 你只能读取 ~/.smtm/sessions/{project}/ 中的快照文件，并按日期合并；对于重复或已修订的结论，要进行去重。这是报告可信度的来源——它是对用户已确认状态的整理记录，而不是 AI 生成的叙述。

---

为什么需要此功能

快照解决了跨会话记忆问题，但它们分散在许多文件中。当用户想要：

• 向商业伙伴发送业务的当前状态
• 与顾问一起回顾哪些内容已验证、哪些已排除
• 6 个月后回顾自己的想法如何演变
• 向承包商或联合创始人交接背景信息

……他们需要的是一个文件，而不是一个装着带时间戳片段的文件夹。这就是报告的用途。

---

触发条件

命令	行为
/money-report	将当前项目中的所有快照合并为一份报告
/money-report --since YYYY-MM-DD	仅包含晚于指定日期的快照
/money-report --slug <project>	指定非默认项目
/money-report --slug <project> --since YYYY-MM-DD	组合使用

自然语言等效说法（遇到以下任一说法时，运行 /money-report）：

• 英文：“package this up”、“make me a report”、“export for my partner”、“give me the deliverable”、“summarize the journey”
• 中文：“出报告”、“打包”、“整理一份”、“给合伙人看的”、“做个总结发出去”

---

工作流

步骤 1 — 确认材料是否充足

查找 ~/.smtm/sessions/{project}/ 中的所有 *.md 文件。

快照数量	行为
0	“{project} 没有已保存的快照。请在进行几次诊断对话后运行 /money-save，然后再回来。”
1	“{project} 只有 1 个快照。单个快照无需合并——请直接在 ~/.smtm/sessions/{project}/{filename}.md 中阅读。仍要强制生成报告吗？”——等待用户确认。
≥2	继续

如果设置了 --since，先进行筛选。如果筛选后的文件少于 2 个，则应用相同规则。

步骤 2 — 加载并排序

读取每个快照，解析 YAML frontmatter 和 6 个正文部分。

按文件名中的 YYYYMMDD-HHMMSS 前缀从早到晚排序。不要信任文件 mtime。

如果有任何单个文件格式错误，记录警告并跳过该文件——不要中止整个报告。

步骤 3 — 构建输出路径

~/.smtm/reports/{project}/{YYYYMMDD-HHMMSS}-{project}.md

先运行 mkdir -p。每份报告都必须是新文件——绝不覆盖之前的报告。文件名中的时间戳便于用户对比或回顾历史报告。

步骤 4 — 撰写报告

使用此固定结构。你生成的字段（标题、摘要、演变叙述段落）应直接取自快照，而非凭空编造。

# {project} — Business Report

**Generated**: {now, formatted as 2026-05-03 14:23 local time}
**Snapshots merged**: {N} (from {oldest snapshot date} to {newest snapshot date})
**Skills active**: {dedup union of all source_skill values}

---

## 1. How the focus has evolved

List each snapshot in chronological order, one line each:

- `2026-04-15` · {one-line restatement of the snapshot's "Business state"} · from {source_skill}
- `2026-04-22` · {one-line restatement} · from {source_skill}
- ...

After the list, write **one paragraph** describing how the focus shifted — e.g., "From validating the API tier pricing in mid-April, the focus moved to ruling out the enterprise pivot in late April, and by early May had shifted to MVP scope freezing for the launch window."

This single paragraph is the *only* place in the report where you synthesize. Do not editorialize, infer, or extrapolate beyond what the snapshots show.

---

## 2. Confirmed conclusions

Merge every "Confirmed conclusions" entry across all snapshots. Deduplicate by semantic similarity. Sort newest first.

Format:

- {conclusion} · from `{snapshot title}` · {snapshot date}

If a conclusion in an *earlier* snapshot was contradicted or revised by a *later* one:
- List the newer version first
- List the older version second with `(superseded by {newer snapshot title} on {date})` appended

Example:

- **Pricing locked at $29 / month per seat** · from `pricing locked at $29` · 2026-05-01
- **Pricing should be $19 / month per seat** · from `early pricing thinking` · 2026-04-12 *(superseded by `pricing locked at $29` on 2026-05-01)*

---

## 3. Ruled out

Merge every "Ruled out" entry across all snapshots. Deduplicate.

- {direction} · from `{snapshot title}` · {snapshot date}

This list is sticky — if it was ruled out, it stays ruled out unless a later snapshot explicitly revives it. If a later snapshot revives a prior ruled-out direction, both entries stay, with a `(reopened on {date})` annotation on the original.

---

## 4. Open hypotheses

Merge "Open hypotheses" entries. **Skip any hypothesis that was later confirmed or ruled out** — those moved to sections 2 or 3.

- {hypothesis} · {test plan if present} · from `{snapshot title}`

Only show hypotheses that are still genuinely open in the most recent snapshot.

---

## 5. The current next move

Pull the "Next move" section verbatim from the **most recent snapshot only**. Older next-moves are obsolete by definition.

Append the recommended next skill: `Recommended next skill: {next_skill from the most recent snapshot}`.

---

## 6. Appendix — Source snapshots

For traceability, list every snapshot file merged:

- `{filename}` — `{title}` — {timestamp} — {status}
- ...

---

*Report generated by `/money-report` from `~/.smtm/sessions/{project}/`. To regenerate after new snapshots, run `/money-report` again.*

步骤 5 — 向用户确认

✅ Report generated.
File: ~/.smtm/reports/{project}/{filename}.md
Snapshots merged: {N}

---

边界情况

• 快照引用了架构中不存在的自定义字段 → 忽略该字段，使用标准字段。不要报错。
• 时间戳冲突（两个快照声明了同一秒）→ 两个都保留，并按完整文件名排序。
• 快照的 frontmatter status 为 abandoned → 仍然纳入报告，但在第 1 节标题旁标注该快照的内容贡献为 (abandoned)。
• 用户想要对外分享，且快照包含敏感信息（收入数据、客户名称）→ 这不在你的职责范围内。快照是用户撰写的内容。不要自动删减敏感信息。

---

原则

• 精心整理，而非自动生成 — 报告中的每项陈述都必须能追溯到某个快照文件。不得杜撰。
• 考虑时间因素 — 新内容优先于旧内容。展示演变轨迹。
• 一段综合总结 — 在第 1 节中，可以描述演变路径。其他地方不得描述。
• 仅追加 — 每份报告都是一个新的带日期文件。跨时间对比报告本身就是一项功能。
• 匹配用户的语言 — 如果快照大多为中文，报告就用中文撰写。如果内容混杂，则默认使用用户当前的语言，并逐字引用源内容。

---

价值量化（成功生成报告后必须执行）

确认报告已写入后，追加：

---

### 📊 What this report is worth

- 📄 **Generated** — A merged report from {N} snapshots, spanning {oldest date} to {newest date}
- ⏱ **Time to produce manually** — ~3-6 hours of digging through old conversation transcripts and summarizing yourself
- 🤝 **Shareable with** — Co-founders, advisors, investors, contractors, or your future self
- 🚧 **Without this skill** — The {N} decisions you've made over weeks/months stay scattered across chat transcripts that get auto-deleted by the agent harness — and your trajectory is invisible to anyone but you

如果这是用户为该项目撰写的第一份报告，追加：

💡 这是 {project} 的第一份报告。今后的报告将采用相同格式，并保存在 ~/.smtm/reports/{project}/ 中，与这份报告放在一起。跨时间对比报告本身就是一项功能 — 它能展示你的演变轨迹。

如果报告中包含矛盾（较新的快照取代了较早的快照），请指出：

🔄 轨迹说明：这段时间里，你的想法在 {N} 个主题上发生了变化。报告展示了当前的决定，以及它取代的先前版本。这很有价值 — 这是学习的证明，而非反复无常。