minimax-ai/req-tpm
Requirement management where the requester and their agent act as the requirement's TPM: intake with a measurable expected outcome, priority recommendation for the owner, design decision record, cadence tracking that flags stale items, ship readiness, and evidence-based outcome review. Body in a Feishu doc, status in Meegle.
为已排期的需求做方案：列至少两个选项、写决策记录、评估波及面（blast radius）、定验收检查点，全部落进需求文档。Use when a requirement is scheduled and before implementation, or when someone asks 方案怎么定 / 这个改动会影响哪些地方.
在需求刚提出时，先挑战它是否该做，写下一条能验证的预期效果，再用模板建飞书需求文档和飞书项目（Meegle）工作项，两边互相链接。Use when someone raises a product or technical requirement, says 提需求 / 我想要 / 能不能加, or before any requirement work starts without a doc and a work item.
上线后对照 intake 写下的预期效果收集证据，判断是否达成；没达成就写清差距和下一步；只有拿到证据才关闭需求。Use after the observation window of a shipped requirement, when someone asks 这个需求效果怎么样 / 可以关了吗, or before closing a work item.
对一个已受理的需求，对照当前在做的工作（WIP）评估成本、影响、风险，给出排期建议和理由；提出人提建议，负责人拍板。Use after req-intake, at backlog grooming or sprint planning, or when someone asks 这个需求优先级多高 / 能不能插队.
上线前做就绪检查（回滚方案、可观测性、完成定义 DoD），全部有证据后再推进 Meegle 状态或节点。Use before a requirement is deployed or marked done, when someone says 可以上线了吗 / 准备发布, or before transitioning the work item to a released state.
按固定节奏跟进进行中的需求，用站会格式记录进展、阻塞和下一步；超过约定时间没有更新的需求要显式标出来，不能悄悄沉下去。Use for daily or weekly requirement check-ins, when asked 这个需求到哪了 / 有没有卡住的, or from a scheduled routine.