采集全矩阵的状态。
每日 cron 与发版 webhook 双触发,自动收集发布、活跃度与指标;项目增删只改一行配置。
- GitHub
yPulse 持续采集产品矩阵的全部状态——发布、进度、功能、任务——并把它们收进一个可编排的指挥台。状态是干活的副产品,不是一项额外的工作;而监控,只是这个中枢的第一块能力。
以下数字由 yPulse 实时读取——这块落地页本身,就是 yPulse 的一个终端。
这套系统的方法论
一块看板,装下整个矩阵首页是可拖拽编排的看板,布局按账号保存。每个项目的发布、活跃度、完成度在同一视野里——不用打开十几个仓库,就知道今天该看哪一个。
看它具体做什么每日 cron 与发版 webhook 双触发,自动收集发布、活跃度与指标;项目增删只改一行配置。
每个仓库自带 .roadmap/features.yaml,写完功能顺手记一行;每晚汇总成完成度与发布时间线。
idea / task / todo 统一入口,inbox → triaged → doing → done;成熟的开发任务毕业为 GitHub Issue。
网页看板、Discord 斜杠命令(含自然语言捕获 /c)、Claude MCP 六个工具——同一个任务库,加终端不动数据模型。
yPulse 不是从「我想要一块 dashboard」开始的,而是从三个判断开始的。
任何需要专门抽时间去「更新状态」的系统,三周内必然荒废。所以状态必须从工作本身溢出:发版触发采集,提交携带台账,对话即是录入。
功能台账与代码同仓、同 PR、同评审。状态与工作零距离,就不存在「忘了同步」这回事。
一个数据核,入口可以无限多。网页、Discord、MCP 只是最先长出来的三个;终端是消耗品,数据模型是资产。
这三条原则,比任何一个具体功能都更值得抄走。
中枢的职责是替一个人扛起「协调层」——公司里由状态会、运营和 CRM 分摊的那一层。按这个方向,能力在逐块生长: