Jira 太重——一个 3 人团队用 Jira 的摩擦成本比收益高。Linear 好一些，但还是 dashboard 思维：你得主动去看，它不会来找你。
tempo 的出发点是反过来：让 AI PM 来主动驱动，人的时间用在判断和执行，而不是协调和同步。
给小团队的 AI 项目经理。
每天按节拍推进度，按需开 issue，
带温度，不打鸡血。
--goal 描述目标，自动拆解并创建结构化 GitHub issue/team-pm-agent我们团队 4 个人，每周花在"协调"上的时间，比花在"执行"上的多。 不是懒，是因为这三件事没人能省掉。
状态会议、进度追踪、问"搞完了没"。每次打断都是 15 分钟的上下文切换。
任务太大，工程师不知道从哪下手；太小，PM 累得要死。拆任务本身就是工作。
代码在动但人卡住了。看 commit 数发现不了这个。冷 dashboard 更发现不了。
Jira 太重——一个 3 人团队用 Jira 的摩擦成本比收益高。Linear 好一些，但还是 dashboard 思维：你得主动去看，它不会来找你。
tempo 的出发点是反过来：让 AI PM 来主动驱动，人的时间用在判断和执行，而不是协调和同步。
PM 不应该是盯着 dashboard 的人，
应该是感受团队节拍的人。
不同时段需要不同视角。六个预设 prompt 共享底层工具集—— 同一个 PM，早上是指挥，下午是检查员，晚上是记录员， 遇到 issue 关闭时是情绪教练。
Agent 有 7 个工具——4 个只读（GitHub issue、用户活动、Supabase 指标），3 个写（通知、创建 issue）。 PM 不直接 close / move / reassign issue。 AI 改 issue 状态难以 review，错了一次就破坏整个 sprint 视图。LLM 推建议，人手动执行。
PM Agent 是定时任务 + 事件驱动，不是请求-响应。GitHub Actions cron 是最合适的基础设施——不需要 HTTP 端点，不需要常驻进程，跟主服务完全解耦，PM 挂了不影响生产。
每个 issue 必须做到"工程师无需追问就能开始"。坏任务 vs. 好任务：
把这些词写进 prompt 的 forbidden list，LLM 生成时会主动避开：
替换成人话："我看到了" / "有点担心" / "这个能不能" / "试一下"。
借鉴非暴力沟通（NVC）四步框架，适配团队场景简化为三段。 每段 prompt 里给 ❌ 错例 / ✅ 对例对比——有了对比，LLM 就不容易偷懒写空话。
真实输出 522 字。三段结构清晰，0 个 jargon，0 个鸡血词。实测团队反馈："感觉比我还了解我在干嘛"。
节流设计：同一 issue 5 分钟内重复触发只跑最新一次（concurrency cancel-in-progress），LLM 自己判断"没有新东西就 skip 不发"。
在任意项目目录下运行 /team-pm-agent，交互式收集团队信息，自动生成所有文件并填入真实配置。
安装向导会打印精确的 secret 列表（只列你用的平台）。飞书用 FEISHU_APP_ID，Slack 用 SLACK_WEBHOOK_URL，两个都用设 NOTIFY_PLATFORM=both。
不发真消息、不创建 issue，只看 LLM 输出质量。满意了再 live。
commit 包含 .github/workflows/ 即可。GitHub Actions 会在每天 09:00 / 14:00 / 19:00（北京时间）自动跑。
在 GitHub Actions 手动触发 mode=plan，填入目标描述，Agent 自动拆解并创建结构化 issue。
Claude Code skill · 交互式安装向导 · 自动填入团队信息 · 5 步部署