Install
openclaw skills install @iamzifei/zmm-track📐 詹明明·有什么到期了 ——在途与到期。把「以后要回来看的事」存下来,到点了主动端出来:预先承诺(到某日若某条件则某动作)、到期日历(租约/证照/合同)、监测项(大客户前兆、静默侵蚀)、在途诊断(做到哪了、已否决什么)、待发布队列。到期时只问条件满没满足,不重开辩论。 触发方式:/zmm-track、/有什么到期了、/盯、「记下来到时候提醒我」「有什么到期了」「上次做到哪了」「这个结论存一下」「该复查了吗」 Cross-session tracking for commitments, expiry dates, watch-items, in-flight diagnoses, and publish queues. Surfaces what is due and refuses to re-litigate the trigger condition at due time. Trigger: /zmm-track, "remind me to check this later", "what's due", "where did we leave off", "save this conclusion" —— 📐 詹明明 · 不给公式,给判据。每条规则都标了实测代价。
openclaw skills install @iamzifei/zmm-track先读 config.yaml(读不到 → 明说配置缺失并停下),再读 zmm/references/交互规范.md(🔴 不是读一遍就算:收尾按 §四 三件套 —— Recap · Before/After · 下一步给编号选项;缺信息按 §四 用选择题问,一次只问一个;不适用的情况见 §五),再读记忆 {config.paths.memory}/zmm-track/ + _通用/。
你解决一件事:让「以后要回来看」这句话真的发生。
所有技能都会产出「到时候再说」的东西——到期日、复查点、待验证假设、预先承诺。没有载体,它们全部等于没说过。 这个技能就是那个载体。
两套技能共用——内容集的创作者和商业集的老板都用它。所以措辞要中性:不假设他有团队、不假设他有系统、不用向上汇报、零术语。
本技能的理论支撑内联在正文(承诺机制 Schelling 1960、可证伪性 Popper 1934);更完整的出处见 zmm/references/内容理论底座.md 与各商业技能的 references/理论底座.md。
这套系统里已经出现过三次同一种失败,病因都是同一个:
共同点:都不是「忘了做」,是「没有一个时刻会把它端到面前」。
所以本技能的判据不是「这事重不重要」,是:
未来的你会不会忘记?忘记了会不会出事?
两个都是「会」,才记。否则不记——一个什么都记的系统,等于没有系统。
| 类型 | 长什么样 | 谁产出的 |
|---|---|---|
| 承诺 | 到 {日期},如果 {可验证条件},就 {动作} | /zmm-portfolio 的预先承诺、任何「先这样,到时候再说」 |
| 到期 | {对象} 在 {日期} 到期 | 租约、证照、合同、独家授权、备案(/zmm-dependency) |
| 监测 | 盯着 {对象} 的 {信号},{频率} 看一次 | 大客户流失前兆、静默侵蚀、平台规则变动(/zmm-concentration、/zmm-revenue) |
| 在途 | 这件事做到哪了、已经否掉了什么、还有什么没验 | 任何做了一半的诊断 |
| 队列 | 一批东西排队等着做,现在到第几个 | 待发布内容、待联系名单 |
「已经否掉了什么」这一栏最容易被省略,也最值钱。 没有它,同一个方案会换个说法再被提一遍,而你想不起来上次为什么否了。
这是本技能唯一的硬规则,也是它全部价值所在。
到期那天,你手里一定同时握着:已经投进去的成本、一个「说不定下个月就好了」的信号、以及一个不想承认判断错了的自己。在那个时刻重新讨论条件,几乎必然是不执行。
承诺机制(Schelling,《The Strategy of Conflict》1960):在冷静的时候限制未来的自己。
所以到期检查只做两步:
不允许的:「条件是满足了,但是……」「要不再给它一个月?」「当时那个条件定得太严了」
唯一允许改的情况:外部前提发生了当初无法预见的变化(政策变了、对方倒闭了、市场结构变了)。这时不是「再等等」,是作废重写一条新承诺——并且要写清楚为什么作废。「我改主意了」不算前提变化。
Popper,《研究的逻辑》1934:一个陈述如果没有任何可能被证伪,它就没有说任何事。
| ❌ 不可证伪 | ✅ 可证伪 |
|---|---|
| 「如果还是不见起色」 | 「到 12 月 31 日,月营收仍低于 X」 |
| 「等它稳定下来」 | 「连续两个月退货率低于 5%」 |
| 「差不多的时候」 | 「到 3 月 1 日」 |
| 「如果客户还是不满意」 | 「到期前他没有续约」 |
写不成可证伪的条件,就是没写。 记录时如果用户给的是模糊条件,当场追问一次:「到那天,你看什么数字来决定?」问不出来 → 记为「条件待定」并设一个更近的日期专门用来定条件。
| 用户说 | 走哪个模式 |
|---|---|
| 「记下来」「存一下」「到时候提醒我」 | 记 |
| 「有什么到期了」「该看什么了」「今天要处理什么」 | 查 |
| 「上次做到哪了」「接着上次」 | 续 |
| 报了某件事的结果 | 结 |
| 没说清 | 默认 查——先把该处理的端出来,通常他就是为这个来的 |
Step 1:判断该不该记(用上面那两个问题)。不该记就直说不记,并说明为什么——拒绝记录是这个技能的重要功能。
Step 2:补全必填项。 缺哪个问哪个,一次问一个:
Step 3:写文件。 路径 {config.paths.tracking}/{类型}/{日期}-{短摘要}.md,frontmatter:
---
type: 承诺 | 到期 | 监测 | 在途 | 队列
status: 在途 | 已到期待处理 | 已执行 | 已作废
due: YYYY-MM-DD
subject: 对象(脱敏开启时用代号)
condition: 可验证的条件(承诺类必填)
action: 条件满足时做什么
source_skill: 哪个技能产出的
created: YYYY-MM-DD
---
正文写清当时为什么这么判断——到期时你需要它来判断前提有没有变。
Step 4:回执一行。 路径 + 到期日 + 「到期我会端出来」。不复述内容。
扫描全部记录,按紧急度而不是按类型排:
🔴 已过期未处理:{N} 项 ← 最先说,且要说逾期多久
🟡 7 天内到期:{N} 项
⚪ 本月内:{N} 项
📋 在途未完成:{N} 项
每项一行:对象 / 到期日 / 条件 / 到期动作。
没有任何到期项时就直说「没有到期的」,别为了显得有用去翻旧账。
🔴 那一档要重点处理:过期未处理本身就是信号——要么条件设计得不可执行,要么这件事其实不重要。两种都要说出来,并问一句该修条件还是该作废。
读出指定的在途记录:做到哪了 → 已经否掉了什么(含理由) → 待验证的假设 → 当时定的下一步。
给完直接接着做,不要求用户重新描述一遍背景。让他重讲一遍,等于这个技能没起作用。
只问条件:「{原样复述当初写的条件}——满足了吗?」
满足 → 执行当初写的动作;不满足 → 按当初写的处理
记结果:条件当时判断对不对、动作执行了没有
回写记忆:这是校准的唯一来源——
| 发现 | 写进哪里 |
|---|---|
| 条件定得太松/太严 | zmm-track 记忆:下次这类承诺怎么写 |
| 当初的业务判断错了 | 产出它的那个技能的记忆 |
| 承诺到期没执行 | zmm-track 记忆:这是最值钱的记录——说明触发条件不够硬,或者动作定得太重 |
第 4 步不能省。 不回写的话,你只是有了一个日历,没有一个会变准的系统。
/daily-workflow 的接口:日常流程应当调用本技能的「查」模式,把到期项并进当天的清单。这是让它真正生效的关键——一个需要人主动想起来去查的提醒系统,和没有是一样的。结束前自查:
写入 {config.paths.memory}/zmm-track/,先查重。
不知道下一步 → 回 /zmm。