money-retro

/money-retro — 每周业务复盘

标准启动：生成输出前，按照 /money § 标准技能启动流程执行 5 步启动序列（解析 slug → 写入遥测数据 → /money-retro 从遥测数据读取，而不是自动加载经验，因为它分析的正是使用模式本身 → 如有项目本地技能则展示 → 加载所有原子类别，以便复盘建议能指出其所体现的创始人原则）。

你的任务是读取磁盘上本周累积的状态，并生成一份犀利、有证据支撑的复盘。这不是打气，而是呈现实际发生了什么、哪些事项停滞了，以及下周应该做出哪些改变。

复盘完全依据磁盘上的内容——会话、经验、技能使用遥测数据，以及用户提供的任何收入数据。不要编造超出证据支持范围的叙述。

---

触发方式

命令	行为
/money-retro	复盘过去 7 天的当前项目
/money-retro --days N	自定义时间范围（例如，--days 30 表示按月复盘）
/money-retro --slug <project>	复盘其他项目
/money-retro --portfolio	汇总复盘 ~/.smtm/sessions/ 中的所有项目

自然语言说法：

• “每周复盘”“业务复盘”“我们发布了什么”“本周进展如何”
• “周复盘”“业务回顾”“本周怎么样”

---

加载内容

对于指定时间范围（默认 7 天，从现在往前计算）：

1. 快照：~/.smtm/sessions/{slug}/ — 按文件名时间戳筛选，保留 ≥ 时间范围起始时间的快照
2. 新增经验：~/.smtm/projects/{slug}/learnings.jsonl — 按 captured_at ≥ 时间范围起始时间筛选
3. 技能使用遥测数据：~/.smtm/analytics/skill-usage.jsonl — 按 ts ≥ 时间范围起始时间筛选，并按技能分组
4. 可选：收入数据 — 如果用户提供数字（例如，“MRR 从 $X 增至 $Y”），则纳入。否则省略收入部分。
5. 以往复盘：~/.smtm/projects/{slug}/retros/ — 用于比较趋势

如果时间范围内没有任何记录（没有快照、经验或技能使用记录），请直接说明：

过去 {N} 天内，{project} 没有活动记录。这可能是因为你没有在启用 ~/.smtm/ 的情况下运行 money-* 技能，也可能是该项目处于休眠状态。两种情况都没问题——但没有内容可供复盘。

---

工作流程

第 1 步——汇总本周情况

对于指定时间范围，计算：

• 时间范围内的快照：数量，以及每个快照的标题和状态
• 已做出的决策：从每个快照的 Confirmed conclusions 部分提取
• 已排除的事项：从每个快照的 Ruled out 部分提取
• 未解决的假设：从每个快照的 Open hypotheses 部分提取
• 停滞的假设：来自 ≥14 天前快照的未解决假设，且没有后续快照
• 新增经验：数量 + 类别
• 已使用技能：按频率排序的直方图

第 2 步——识别“停滞”事项

满足以下条件的假设属于“停滞”：

• 在 ≥14 天前的快照中提出
• 同一项目中没有后续快照确认或排除该假设
• 没有新增经验涉及该假设

这些是价值最高的发现——创始人通常会忘记原本打算验证的假设。

第 3 步——找出未使用的技能

根据 skill-usage.jsonl，列出用户在该项目中从未运行过的技能，或运行过但过去 30 天内未运行的技能。这些是可激活的候选技能。

不要对每个未使用的技能都说教——根据当前项目状态，挑出 1–2 个最相关的技能。如果他们已经发布产品，却从未运行过 /money-ads，那么它就是候选技能。如果他们还没有产品，那么 /money-ads 未被使用是合理的；不要提及它。

第 4 步——输出

# Weekly Business Retro — {project}

**Window**: {start date} → {end date} ({N} days)
**Generated**: {now}

---

## What you decided this week

{For each snapshot's "Confirmed conclusions" — list with snapshot title and date.}

If no snapshots: "No new decisions checkpointed. Either nothing was decided, or `/money-save` wasn't run."

---

## What you ruled out

{Aggregated from snapshots' "Ruled out" sections, deduplicated.}

If empty: "Nothing was explicitly ruled out this week."

---

## Stalled hypotheses (action required)

These hypotheses were opened ≥14 days ago and never tested:

| Opened | Days stalled | Hypothesis | From |
|---|---|---|---|
| 2026-04-15 | 18 | Reddit r/SaaS will convert at >2% | snapshot:wedge-locked |
| ... | | | |

For each stalled item, suggest the cheapest test to resolve it.

If empty: "All open hypotheses are <14 days old. No stalls."

---

## Learnings captured

{Show recent learnings added in the window, with category and confidence.}

If empty: "No new learnings captured. If you observed any patterns this week, run `/money-learn add`."

---

## Skill activity

| Skill | Runs this week | Trend vs prior week |
|---|---|---|
| /money-discover | 3 | ↑ (was 1) |
| /money-content | 8 | → (was 7) |
| /money-ads | 0 | — (never run) |
| ... | | |

---

## Activation candidates (skills you haven't used)

Pick 1-2 high-relevance unused skills. Frame as a question:

> 💡 You've shipped the product and run `/money-content` 8 times — but never `/money-ads`. With your current MRR trajectory, paid ads might be the next leverage point. Want me to walk you through `/money-ads` next session?

---

## Revenue (only if user provided)

Show MRR/revenue if the user shared numbers. Otherwise omit.

---

## Recommended focus for next week

ONE thing. Not three. The single highest-leverage move based on what the retro surfaced.

Format: "**Focus**: {one sentence}. **First action**: {today or tomorrow specific step}."

---

## Snapshot of project state

- Total snapshots in project — {N}
- Total learnings — {N} ({validated} validated, {emerging} emerging, {hypothesis} hypothesis)
- Project age — {months since first snapshot}
- Open hypotheses — {N}

第 5 步 — 保存回顾

将回顾内容写入 ~/.smtm/projects/{slug}/retros/{YYYYMMDD-HHMMSS}-retro.md。每次回顾都新建一个文件（绝不覆盖）。这样可以逐步记录项目的进展情况。

向用户确认：

✅ 回顾已保存到 ~/.smtm/projects/{slug}/retros/{filename}.md 与上周的回顾对比：~/.smtm/projects/{slug}/retros/{prior filename}.md

---

Portfolio 模式（--portfolio）

如果使用 --portfolio 调用，则汇总 ~/.smtm/sessions/ 中的所有项目。输出内容相似，但会增加一个顶层的“项目汇总”表：

项目	本周快照数	新增心得	停滞项	状态（最近的快照）
musicapi	3	2	0	进行中
kolfind	0	0	4	⚠️ 已停滞
ccapi	1	0	1	进行中

这里的“停滞”信息尤其有价值——独立创始人往往会把注意力都放在更喧闹的产品上，却有一个产品在悄然走向衰亡。

---

原则

• 叙述只依据证据 — 如果内容没有出现在快照、心得或遥测日志中，就不要写入回顾。不要编造故事。
• 停滞的假设是最有价值的发现 — 大多数创始人会快速浏览活动部分，但看到“你从未测试那个 3 周前计划要测试的东西”时，就会停下来仔细查看。
• 只设一个重点，而不是五个 — 建议越多，效果越弱。选出最有价值的一项行动。
• 关注趋势，而不只是快照 — 尽可能与前几周进行比较。趋势能揭示某个时间点的情况可能掩盖的内容。
• 不要因为技能未使用而指责用户 — 提出 1–2 个最相关的技能即可，但不要因为用户没有运行所有技能而让他们感到羞愧。

---

回顾之后

始终推荐以下一项：

• 如果回顾揭示了一个明显但尚未记录的模式，推荐 /money-learn add
• 如果用户已根据建议的重点采取行动，推荐 /money-save
• 如果多个停滞的假设表明计划本身需要重新审视，推荐 /money-panel
• 如果事项停滞是因为执行受阻，而不是缺少时间，推荐 /money-diagnose

---

价值量化（必须放在输出末尾）

• ⏱ 节省的时间 — 约 1–2 小时，无需翻查旧聊天记录和快照，也无需费力回忆当时的决定
• ⚠️ 规避的风险 — （1）停滞的假设数月都未得到测试；（2）重复开展相同活动（例如运行 /money-content 12 次）却不检查投资回报；（3）专注于喧闹的项目，却忽略悄然衰亡的副项目；（4）每周重复同样的事情，却不主动调整方向
• ✅ 你获得的内容 — 决策／排除项／停滞项／心得／技能活动，以及一个建议重点；如果涉及多个项目，还会附上项目汇总
• 🚧 没有这项技能 — 到了季度末，你将无法说清楚发生了什么变化，而且至少有一个假设会在未经测试的情况下悄然过时