diff --git a/.agents/plugins/marketplace.json b/.agents/plugins/marketplace.json
index 422ba6a..3c51aa8 100644
--- a/.agents/plugins/marketplace.json
+++ b/.agents/plugins/marketplace.json
@@ -27,6 +27,18 @@
         "authentication": "ON_INSTALL"
       },
       "category": "Productivity"
+    },
+    {
+      "name": "req-tpm",
+      "source": {
+        "source": "local",
+        "path": "./stacks/req-tpm"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
     }
   ]
 }
diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json
index 31edc33..678adae 100644
--- a/.claude-plugin/marketplace.json
+++ b/.claude-plugin/marketplace.json
@@ -26,6 +26,16 @@
         "name": "Jiachen (MiniMax Code team)"
       },
       "homepage": "https://github.com/yujiachen-y/dotfiles"
+    },
+    {
+      "name": "req-tpm",
+      "source": "./stacks/req-tpm",
+      "description": "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.",
+      "category": "Productivity",
+      "author": {
+        "name": "MiniMax Code team"
+      },
+      "homepage": "https://github.com/MiniMax-AI/mcode-stack/tree/main/stacks/req-tpm"
     }
   ]
 }
diff --git a/README.md b/README.md
index 0761a2b..e40feb4 100644
--- a/README.md
+++ b/README.md
@@ -193,6 +193,7 @@ change it. To suggest a change here, open an issue; see
 ```text
 stacks/ronny/               Ronny's stack (MiniMax Code R&D lead), the first and most complete one
 stacks/jiachen/             Jiachen's stack: getting out of the agent loop, and turning notes into posts and videos
+stacks/req-tpm/             Optional: the requester and their agent act as a requirement's TPM (Feishu doc body, Meegle status); v0
 stacks/<name>/              One directory per team member; teammates are welcome to add theirs
 notes/                      Which runnable piece goes with each Engineering Notes article
 community/                  Stacks from outside the team, added by collaborators
diff --git a/README_ZH.md b/README_ZH.md
index 3eefe21..22750d7 100644
--- a/README_ZH.md
+++ b/README_ZH.md
@@ -153,6 +153,7 @@ AI 写代码越来越快，真正拉开差距的，是围绕 agent 的那一圈
 ```text
 stacks/ronny/               MiniMax Code 研发负责人 Ronny 的日常工作流，第一份，也是目前最完整的一份
 stacks/jiachen/             Jiachen 的工作流：把自己从 agent 的循环里解放出来，以及把笔记做成图文和短视频
+stacks/req-tpm/             可选：需求提出人和自己的 agent 一起当这条需求的 TPM（正文在飞书文档，状态在 Meegle），v0
 stacks/<name>/              每位成员一个目录，欢迎团队同事把自己的也放进来
 notes/                      「MCode 工程笔记」每一篇对应哪一份能跑的东西
 community/                  团队外的 stack，由协作者加进来
diff --git a/stacks/README.md b/stacks/README.md
index 1004171..2536ef6 100644
--- a/stacks/README.md
+++ b/stacks/README.md
@@ -8,6 +8,7 @@ MiniMax Code plugin package.
 | --- | --- | --- |
 | [`ronny`](ronny/) | Ronny, R&D lead | Skills and plain-text checklists |
 | [`jiachen`](jiachen/) | Jiachen, engineer | Skills and a `WORKFLOW.md` |
+| [`req-tpm`](req-tpm/) | MiniMax Code team | Optional v0 requirement-management stack: skills, templates and a `WORKFLOW.md` |
 
 Teammates are welcome to add their own; see below.
 
diff --git a/stacks/req-tpm/.claude-plugin/plugin.json b/stacks/req-tpm/.claude-plugin/plugin.json
new file mode 100644
index 0000000..627e2f8
--- /dev/null
+++ b/stacks/req-tpm/.claude-plugin/plugin.json
@@ -0,0 +1,11 @@
+{
+  "name": "req-tpm",
+  "displayName": "Requirement TPM",
+  "version": "0.1.0",
+  "description": "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.",
+  "author": {
+    "name": "MiniMax Code team"
+  },
+  "homepage": "https://github.com/MiniMax-AI/mcode-stack/tree/main/stacks/req-tpm",
+  "repository": "https://github.com/MiniMax-AI/mcode-stack"
+}
diff --git a/stacks/req-tpm/.codex-plugin/plugin.json b/stacks/req-tpm/.codex-plugin/plugin.json
new file mode 100644
index 0000000..78027af
--- /dev/null
+++ b/stacks/req-tpm/.codex-plugin/plugin.json
@@ -0,0 +1,28 @@
+{
+  "name": "req-tpm",
+  "version": "0.1.0",
+  "description": "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.",
+  "author": {
+    "name": "MiniMax Code team"
+  },
+  "homepage": "https://github.com/MiniMax-AI/mcode-stack/tree/main/stacks/req-tpm",
+  "repository": "https://github.com/MiniMax-AI/mcode-stack",
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "Requirement TPM",
+    "shortDescription": "Requester + agent as TPM for a requirement, from intake to outcome.",
+    "longDescription": "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.",
+    "developerName": "MiniMax Code team",
+    "category": "Productivity",
+    "capabilities": [
+      "Read",
+      "Write"
+    ],
+    "websiteURL": "https://github.com/MiniMax-AI/mcode-stack/tree/main/stacks/req-tpm",
+    "defaultPrompt": [
+      "帮我把这个需求受理一下：建文档和工作项",
+      "这个需求该不该插到本迭代？",
+      "这个需求上线一周了，效果达成了吗？"
+    ]
+  }
+}
diff --git a/stacks/req-tpm/.minimax-plugin/plugin.json b/stacks/req-tpm/.minimax-plugin/plugin.json
new file mode 100644
index 0000000..957d70d
--- /dev/null
+++ b/stacks/req-tpm/.minimax-plugin/plugin.json
@@ -0,0 +1,25 @@
+{
+  "schemaVersion": 1,
+  "name": "req-tpm",
+  "version": "0.1.0",
+  "displayName": "Requirement TPM",
+  "description": "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.",
+  "author": "MiniMax Code team",
+  "icon": "icon.png",
+  "category": "Productivity",
+  "exampleQueries": [
+    "帮我把这个需求受理一下：建文档和工作项",
+    "这个需求该不该插到本迭代？",
+    "这个需求上线一周了，效果达成了吗？"
+  ],
+  "apps": [],
+  "mcpServers": [],
+  "skills": [
+    "skills/req-intake/SKILL.md",
+    "skills/req-prioritize/SKILL.md",
+    "skills/req-design/SKILL.md",
+    "skills/req-track/SKILL.md",
+    "skills/req-ship/SKILL.md",
+    "skills/req-outcome/SKILL.md"
+  ]
+}
diff --git a/stacks/req-tpm/README.md b/stacks/req-tpm/README.md
new file mode 100644
index 0000000..b0f3b96
--- /dev/null
+++ b/stacks/req-tpm/README.md
@@ -0,0 +1,46 @@
+# req-tpm
+
+让需求提出人和自己的 Agent 一起，当这个需求的 TPM：从提出到效果验收，全程有文档、有工作项、有人在跟，不会悄悄丢掉。
+
+需求正文放飞书文档，状态和流转放飞书项目（Meegle）。每个 skill 都可以单独装、单独用，同时维护两边。
+
+## 生命周期
+
+```mermaid
+flowchart LR
+  A[req-intake<br/>该不该做<br/>预期效果] --> B[req-prioritize<br/>成本/影响/风险<br/>负责人拍板]
+  B --> C[req-design<br/>选项与决策<br/>波及面/检查点]
+  C --> D[req-track<br/>进展/阻塞/下一步<br/>停滞显式标出]
+  D --> E[req-ship<br/>回滚/可观测/DoD<br/>推进状态]
+  E --> F[req-outcome<br/>对照预期效果<br/>有证据才关闭]
+  F -- 未达成 --> C
+  A -- 建议不做 --> X[关闭并记录原因]
+  D -. 停滞 .-> D
+```
+
+| 阶段 | Skill | 产出写到文档哪一节 |
+| --- | --- | --- |
+| 受理 | `req-intake` | 1–3 |
+| 排期 | `req-prioritize` | 4 |
+| 方案 | `req-design` | 5–6 |
+| 跟进 | `req-track` | 7 |
+| 上线 | `req-ship` | 8 |
+| 验收 | `req-outcome` | 9 |
+
+## 几条规则
+
+- 预期效果在受理时就写死：指标、基线、目标、测法、观察窗口。最后用它验收。
+- 提出人提建议，负责人做优先级决定。Agent 不改别人需求的优先级。
+- 停滞本身是一条信息：报告里置顶，不自动催人，也不沉默。
+- 上线不等于完成。只有拿到效果证据才关闭。
+- 对外可见的写操作（评论、@人、状态流转）先给提出人看，确认后执行。
+
+## 依赖
+
+- `meegle` CLI（飞书项目），已登录；字段和状态见 [`templates/meegle-field-mapping.md`](templates/meegle-field-mapping.md)。
+- `lark-cli`，以用户身份（`--as user`）读写飞书文档。
+- 需求文档模板：[`templates/requirement-doc.md`](templates/requirement-doc.md)。
+
+---
+
+**English.** `req-tpm` lets whoever raises a requirement act as its TPM together with their own agent: challenge it at intake and write a measurable expected outcome, get a priority decision from the owner, record the design decision and blast radius, track status on a cadence and flag stale items, check rollback/observability/DoD before shipping, and close only with evidence against the expected outcome. The body lives in a Feishu doc; status lives in Meegle (Feishu Project). Each skill installs on its own.
diff --git a/stacks/req-tpm/WORKFLOW.md b/stacks/req-tpm/WORKFLOW.md
new file mode 100644
index 0000000..9022146
--- /dev/null
+++ b/stacks/req-tpm/WORKFLOW.md
@@ -0,0 +1,12 @@
+# req-tpm：什么时候用哪个 skill
+
+| 时刻 | Skill |
+| --- | --- |
+| 有人提了一个需求 | `req-intake` |
+| 迭代规划 / 有人要插队 | `req-prioritize` |
+| 排上了，开发之前 | `req-design` |
+| 每个工作日 / 每周跟进 | `req-track` |
+| 准备上线 | `req-ship` |
+| 观察窗口结束 / 想关单 | `req-outcome` |
+
+试点期间，我们先在 MiniMax Code 团队内部用，每个需求跑完整条链路后在文档里留一段使用记录，作为开放前的依据。
diff --git a/stacks/req-tpm/icon.png b/stacks/req-tpm/icon.png
new file mode 100644
index 0000000..a43df94
Binary files /dev/null and b/stacks/req-tpm/icon.png differ
diff --git a/stacks/req-tpm/plugin.json b/stacks/req-tpm/plugin.json
new file mode 100644
index 0000000..8d3b231
--- /dev/null
+++ b/stacks/req-tpm/plugin.json
@@ -0,0 +1,11 @@
+{
+  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
+  "name": "req-tpm",
+  "version": "0.1.0",
+  "description": "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.",
+  "author": {
+    "name": "MiniMax Code team"
+  },
+  "homepage": "https://github.com/MiniMax-AI/mcode-stack/tree/main/stacks/req-tpm",
+  "repository": "https://github.com/MiniMax-AI/mcode-stack"
+}
diff --git a/stacks/req-tpm/skills/req-design/SKILL.md b/stacks/req-tpm/skills/req-design/SKILL.md
new file mode 100644
index 0000000..e4b8fcc
--- /dev/null
+++ b/stacks/req-tpm/skills/req-design/SKILL.md
@@ -0,0 +1,73 @@
+---
+name: req-design
+description: "为已排期的需求做方案：列至少两个选项、写决策记录、评估波及面（blast radius）、定验收检查点，全部落进需求文档。Use when a requirement is scheduled and before implementation, or when someone asks 方案怎么定 / 这个改动会影响哪些地方."
+---
+
+# 方案设计（req-design）
+
+方案讨论最容易散在群聊和会议里。我们要求结论回到需求文档，形成一条能被后来人读懂的决策记录。
+
+## 1. 输入
+
+- 需求文档（`lark-cli docs +fetch --as user --doc <URL>`），重点读背景、预期效果、待确认问题。
+- 相关代码或系统现状：从真实仓库和文档里读，不凭印象。
+
+待确认问题里还有影响方案的项，先回去问提出人，不进入设计。
+
+## 2. 至少两个选项
+
+每个选项一段：做法、改动范围、成本、主要风险、放弃它的理由。「什么都不改，只改文档/流程」也算一个选项，值得写。
+
+## 3. 决策记录
+
+```text
+决定：选项 B
+原因：...
+放弃了：选项 A，因为 ...
+谁定的、何时：...
+假设（被推翻时要重新评审）：...
+```
+
+## 4. 波及面
+
+列出这次改动可能波及、但不在 diff 里的地方：调用方、配置、数据迁移、对外接口、文档、其他团队。每条写「怎么确认没坏」（一个测试、一条命令、一个负责人确认）。
+
+## 5. 验收检查点
+
+把 intake 的预期效果拆成实施过程中的检查点，每个检查点有可执行的检查方式：
+
+| 检查点 | 何时 | 怎么查 | 通过标准 |
+| --- | --- | --- | --- |
+| 方案评审通过 | 开发前 | 文档评审记录 | 负责人确认 |
+| 关键路径测试 | 合入前 | `<测试命令>` | 全绿，且新测试在旧代码上失败 |
+| 灰度指标 | 上线后 1 天 | 埋点看板 | 不劣于基线 |
+
+## 6. 写回文档并推进节点
+
+写进「5. 方案设计」「6. 验收检查点」（用 `+fetch --detail with-ids` 拿 block_id，再 `+update --command block_insert_after` 或 `block_replace`）。
+
+方案评审在 Meegle 上若是一个节点，评审结论按 meegle skill 的 `sop-transition-node.md` 写：
+
+```bash
+meegle workflow get-node --project-key <PK> --work-item-id <ID> --node-id-list '["<评审节点 key>"]' --format json
+meegle workflow update-node --project-key <PK> --work-item-id <ID> --node-id <评审节点 key> \
+  --fields '[{"field_key":"node_finished_opinion","field_value":"<评审意见>"}]'
+```
+
+节点流转（`workflow transition --action confirm`）由节点负责人确认后再执行。
+
+## 输出
+
+文档里的选项、决策记录、波及面、检查点四节齐全；给提出人一段摘要和仍未决的问题。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/skills/req-intake/SKILL.md b/stacks/req-tpm/skills/req-intake/SKILL.md
new file mode 100644
index 0000000..8578034
--- /dev/null
+++ b/stacks/req-tpm/skills/req-intake/SKILL.md
@@ -0,0 +1,86 @@
+---
+name: req-intake
+description: "在需求刚提出时，先挑战它是否该做，写下一条能验证的预期效果，再用模板建飞书需求文档和飞书项目（Meegle）工作项，两边互相链接。Use when someone raises a product or technical requirement, says 提需求 / 我想要 / 能不能加, or before any requirement work starts without a doc and a work item."
+---
+
+# 需求受理（req-intake）
+
+需求跟丢，多半丢在第一步：一句话在群里提了，没有文档，没有工作项，也没人写下"做成什么样算成"。这一步我们只做三件事：问清值不值得做，写下可验证的预期效果，把文档和工作项建出来并互相挂上。提出人是这个需求的 TPM，Agent 是他的搭档，不是替他拍板。
+
+## 1. 先挑战，再记录
+
+按下面顺序问提出人，答不上来的写进文档「待确认问题」，不替他编：
+
+1. **谁在什么场景下遇到什么问题？** 要一个真实例子（会话、截图、工单、数据），没有例子就标「无实证」。
+2. **不做会怎样？** 现在怎么绕过去的，绕过去的代价是什么。
+3. **有没有更小的做法？** 改文档、改配置、已有功能就能解决的，直接建议不立需求。
+4. **和谁有关？** 需求方、可能的执行人、要通知的人。
+
+结论只有三种：立项 / 建议不做（附原因，提出人确认后关闭） / 先补信息。
+
+## 2. 写预期效果（Expected Outcome）
+
+这是整条链路最后验收的依据（`req-outcome` 会回来对它）。每条必须同时有：
+
+| 项 | 例子 |
+| --- | --- |
+| 指标或可观察行为 | `/resume` 列表首屏加载 P95 |
+| 基线（现在的值，带来源） | 2.4 s，来自上周埋点 |
+| 目标 | ≤ 800 ms |
+| 怎么测、谁来测 | 同一埋点，上线后 7 天窗口，提出人看 |
+| 观察窗口 | 上线后 7 天 |
+
+写不出基线就先写「基线待测」和测法，不允许只写「体验更好」「更稳定」。
+
+## 3. 建飞书需求文档
+
+用 `templates/requirement-doc.md` 填好后创建（Markdown 导入）：
+
+```bash
+lark-cli docs +create --as user --doc-format markdown \
+  --title "【需求】<一句话标题>" --content @req.md \
+  [--parent-token <需求文件夹或 wiki 节点 token>]
+```
+
+记下返回的文档 URL。
+
+## 4. 建 Meegle 工作项并互链
+
+```bash
+meegle workitem meta-create-fields --project-key <PK> --work-item-type <类型 key> --format json
+meegle workitem meta-roles --project-key <PK> --work-item-type <类型 key> --format json
+meegle workitem create --project-key <PK> --work-item-type <类型 key> \
+  --fields '[{"field_key":"name","field_value":"<标题>"},{"field_key":"<需求文档链接字段>","field_value":"<文档 URL>"}]' \
+  --format json
+```
+
+- 模板 ID 是必填项（meegle skill 原文），从 `meta-create-fields` 里取。
+- 「需求文档链接」字段的 key 未核实，见字段映射文档；没有专门字段时，把链接写进 `description`。
+- 回写文档「1. 文档信息」里的工作项链接：
+
+```bash
+lark-cli docs +update --as user --doc <文档 URL> --command str_replace \
+  --pattern "工作项：待创建" --content "工作项：<Meegle 链接>"
+```
+
+## 5. 验收这一步
+
+- `meegle workitem get --project-key <PK> --work-item-id <ID> --format json` 能读回标题和文档链接。
+- `lark-cli docs +fetch --as user --doc <URL> --keyword "工作项"` 能看到 Meegle 链接。
+- 预期效果表每一行都有基线（或测法）和观察窗口。
+
+## 输出
+
+给提出人一张卡片：结论、预期效果表、文档链接、工作项链接、待确认问题。下一步通常是 `req-prioritize`。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/skills/req-outcome/SKILL.md b/stacks/req-tpm/skills/req-outcome/SKILL.md
new file mode 100644
index 0000000..1a1899c
--- /dev/null
+++ b/stacks/req-tpm/skills/req-outcome/SKILL.md
@@ -0,0 +1,55 @@
+---
+name: req-outcome
+description: "上线后对照 intake 写下的预期效果收集证据，判断是否达成；没达成就写清差距和下一步；只有拿到证据才关闭需求。Use after the observation window of a shipped requirement, when someone asks 这个需求效果怎么样 / 可以关了吗, or before closing a work item."
+---
+
+# 效果验收（req-outcome）
+
+需求的终点是效果，不是上线。我们只在证据对上 intake 的预期效果之后关闭需求。
+
+## 1. 取回预期效果
+
+```bash
+lark-cli docs +fetch --as user --doc <URL> --keyword "预期效果" --context-after 3
+```
+
+读出每一行的指标、基线、目标、测法、观察窗口。观察窗口没到，就只记中期读数，不下结论。
+
+## 2. 按原测法取数
+
+用 intake 写的同一个测法、同一个口径取数，自己复算一次。换了口径要写明，并说明为什么。不允许用「感觉好多了」「用户反馈不错」代替指标；定性反馈可以附上，但不算达成证据。
+
+## 3. 逐条判定
+
+| 预期 | 基线 | 目标 | 实测（来源） | 结论 |
+| --- | --- | --- | --- | --- |
+| ... | ... | ... | ...（看板链接/查询） | 达成 / 未达成 / 无法判断 |
+
+- **未达成**：写差距、可能原因（带证据）、下一步（继续优化 / 新需求 / 接受现状），下一步要有人和时间。
+- **无法判断**：通常是没埋点或口径变了，写清缺什么，回到 `req-ship` 补可观测性。
+
+## 4. 写回并关闭
+
+把表格写进「9. 效果验收」。
+
+全部达成，或提出人和负责人书面接受了未达成项，才推进到关闭状态（命令同 `req-ship` 第 3 节）。未达成且有后续时，在工作项评论里写下一步和新需求链接：
+
+```bash
+meegle comment add --project-key <PK> --work-item-id <ID> --content "<验收结论 + 文档链接>"
+```
+
+## 输出
+
+验收表、结论、关闭与否；没关闭时写下一次验收时间。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/skills/req-prioritize/SKILL.md b/stacks/req-tpm/skills/req-prioritize/SKILL.md
new file mode 100644
index 0000000..dea2d94
--- /dev/null
+++ b/stacks/req-tpm/skills/req-prioritize/SKILL.md
@@ -0,0 +1,84 @@
+---
+name: req-prioritize
+description: "对一个已受理的需求，对照当前在做的工作（WIP）评估成本、影响、风险，给出排期建议和理由；提出人提建议，负责人拍板。Use after req-intake, at backlog grooming or sprint planning, or when someone asks 这个需求优先级多高 / 能不能插队."
+---
+
+# 需求排优先级（req-prioritize）
+
+优先级不是提出人喊出来的，也不是 Agent 算出来的。我们的分工是：提出人和他的 Agent 把账算清楚、给出建议，负责人（空间里配置的 PM/Owner 角色）做决定。Agent 不改别人需求的优先级。
+
+## 1. 拉当前 WIP
+
+```bash
+meegle workitem query --project-key <PK> \
+  --mql "SELECT name, priority, status, current_status_operator FROM <类型 key> WHERE <状态不在已完成/已关闭>" \
+  --format json
+```
+
+MQL 写法先读 meegle skill 的 `references/mql-basics.md` 与 `mql-operators.md`；状态条件的具体写法见 `mql-time-status.md`。单次最多 50 条，多了按 `--session-id` 翻页。
+
+## 2. 三项各给一个档位和证据
+
+| 维度 | 档位 | 必须附的证据 |
+| --- | --- | --- |
+| 影响 | 高 / 中 / 低 | 受影响人数或场景频率，来自 intake 的实证 |
+| 成本 | S（≤2 人日）/ M（≤1 周）/ L（>1 周） | 粗拆的步骤，谁估的 |
+| 风险 | 高 / 中 / 低 | 碰到的模块、数据、权限、对外接口 |
+
+没证据的格子写「未知」，不要往中间档凑。
+
+## 3. 和 WIP 比
+
+- 这个需求要占谁的时间？那个人手上已有几项在做？
+- 插进来会推迟哪一项？把被推迟项的名字写出来。
+- 不插队的话最早什么时候能开始？
+
+## 4. 写建议
+
+```text
+建议：本迭代 / 下迭代 / 进 backlog / 不做
+理由：（一到三条，对应上面的证据）
+代价：插进来会推迟 <工作项名>
+需要负责人决定的点：...
+```
+
+把建议写进需求文档「4. 优先级评估」：
+
+```bash
+lark-cli docs +fetch --as user --doc <URL> --scope outline --detail with-ids
+lark-cli docs +update --as user --doc <URL> --command block_insert_after \
+  --block-id <「4. 优先级评估」标题的 block_id> --doc-format markdown --content @prio.md
+```
+
+在工作项上留评论并 @ 负责人（这是对外可见的动作，先给提出人看过再发）：
+
+```bash
+meegle comment add --project-key <PK> --work-item-id <ID> --content "<建议摘要 + 文档链接>"
+```
+
+## 5. 负责人决定之后
+
+由负责人或提出人本人改优先级字段；Agent 只在提出人明确说「按负责人的决定改」时执行：
+
+```bash
+meegle workitem update --project-key <PK> --work-item-id <ID> \
+  --fields '[{"field_key":"priority","field_value":"<option_id>"}]'
+```
+
+`priority` 是 meegle skill 示例里出现过的 key；option_id 必须先用 `meegle workitem meta-fields` 查。
+
+## 输出
+
+建议卡片 + 负责人的决定（谁、何时、在哪说的）。没拿到决定前状态保持「待排期」。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/skills/req-ship/SKILL.md b/stacks/req-tpm/skills/req-ship/SKILL.md
new file mode 100644
index 0000000..c6fed5e
--- /dev/null
+++ b/stacks/req-tpm/skills/req-ship/SKILL.md
@@ -0,0 +1,61 @@
+---
+name: req-ship
+description: "上线前做就绪检查（回滚方案、可观测性、完成定义 DoD），全部有证据后再推进 Meegle 状态或节点。Use before a requirement is deployed or marked done, when someone says 可以上线了吗 / 准备发布, or before transitioning the work item to a released state."
+---
+
+# 上线就绪（req-ship）
+
+「代码合了」不等于「可以上线」，更不等于「需求完成」。这一步把上线前必须有的东西逐条对证据，缺一条就不推进状态。
+
+## 1. 就绪清单
+
+| 项 | 要的证据 | 缺了怎么办 |
+| --- | --- | --- |
+| 完成定义（DoD） | design 里的检查点逐条打勾，附 PR、测试输出链接 | 回 design 或实施 |
+| 回滚方案 | 具体操作（回退版本号、开关名、命令）和谁有权限执行 | 写出来再上 |
+| 可观测性 | 能看到 intake 预期效果指标的看板或查询，上线前截一次基线 | 先补埋点，否则 outcome 无法验收 |
+| 影响面通知 | 波及面里列的人或团队已知会（链接） | 提出人去通知 |
+| 发布窗口 | 时间、负责人 | 和负责人对齐 |
+
+证据看真实输出：CI 是在最终提交上跑的吗？测试有没有被过滤跳过？
+
+## 2. 写回文档
+
+把清单和证据写进「8. 上线记录」。
+
+## 3. 推进 Meegle
+
+先查这个工作项是状态流还是节点流、当前能去哪里、需要什么必填项：
+
+```bash
+# 状态流
+meegle workflow list-state-transitions --project-key <PK> --work-item-id <ID> --format json
+meegle workflow list-state-required --project-key <PK> --work-item-id <ID> --state-key <目标状态 key> --format json
+meegle workflow transition-state --project-key <PK> --work-item-id <ID> --transition-id <transition_id>
+
+# 节点流
+meegle workflow get-node --project-key <PK> --work-item-id <ID> --format json
+meegle workflow transition --project-key <PK> --work-item-id <ID> --node-id <节点 key> --action confirm
+```
+
+`list-state-required` 默认返回全部必填项；加 `--mode unfinished` 只看还没填的。
+
+流转前把命令和目标状态给提出人看，确认后执行；流转后用 `workitem get` 读回状态。
+
+注意：推进到「已上线」不是「已完成」。关闭留给 `req-outcome`。
+
+## 输出
+
+就绪清单（每项：通过/缺失 + 证据链接）、执行了哪条流转命令及读回的状态、上线时截的基线。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/skills/req-track/SKILL.md b/stacks/req-tpm/skills/req-track/SKILL.md
new file mode 100644
index 0000000..0bcfaca
--- /dev/null
+++ b/stacks/req-tpm/skills/req-track/SKILL.md
@@ -0,0 +1,70 @@
+---
+name: req-track
+description: "按固定节奏跟进进行中的需求，用站会格式记录进展、阻塞和下一步；超过约定时间没有更新的需求要显式标出来，不能悄悄沉下去。Use for daily or weekly requirement check-ins, when asked 这个需求到哪了 / 有没有卡住的, or from a scheduled routine."
+---
+
+# 需求跟进（req-track）
+
+需求不是做砸的，多数是没人问着慢慢沉掉的。这一步就是定期问一句，并且把「没人更新」本身当成一条要上报的信息。
+
+## 1. 约定节奏
+
+在 intake 或 design 时和提出人约好：开发中默认每个工作日一次，排队中每周一次。写进文档「1. 文档信息」的「跟进节奏」。
+
+## 2. 拉状态
+
+```bash
+meegle workitem get --project-key <PK> --work-item-id <ID> --format json
+meegle workitem list-op-records --project-key <PK> --work-item-id <ID> --format json
+meegle comment list --project-key <PK> --work-item-id <ID> --format json
+```
+
+多个需求时用 `workitem query` 按提出人或标签筛，见 meegle skill 的 `mql-people-roles.md`。
+
+## 3. 站会三问
+
+对每个需求只写三行，事实来自上面的记录和关联的 PR/CI，不来自猜测：
+
+```text
+进展：自上次以来完成了什么（附链接）
+阻塞：卡在哪、等谁、从哪天开始
+下一步：谁、做什么、预计何时
+```
+
+## 4. 判定停滞
+
+满足任一条就标 **停滞**：
+
+- 操作记录和评论在约定节奏的两倍时间内没有新内容；
+- 同一阻塞连续两次跟进没变化；
+- 计划时间已过但状态没动。
+
+停滞不自动改状态、不自动催人。我们做的是：在给提出人的报告里置顶这一项，写清停了多久、最后一次动静是什么、建议找谁。提出人决定是否在工作项上评论或 @ 人：
+
+```bash
+meegle comment add --project-key <PK> --work-item-id <ID> --content "<站会三行>"
+```
+
+## 5. 记录
+
+把每次的三行追加到文档「7. 进展记录」末尾，保持时间顺序：
+
+```bash
+lark-cli docs +update --as user --doc <URL> --command append --doc-format markdown --content @standup.md
+```
+
+## 输出
+
+一张表：需求、状态、进展、阻塞、下一步、是否停滞。停滞项放最上面。只读汇总，不给人排名。
+
+## 用到的命令
+
+先确认身份和空间（每个会话一次）：
+
+```bash
+meegle project search --project-key "<空间名或 key>" --format json
+meegle workitem meta-types --project-key <PK> --format json
+lark-cli docs +fetch --as user --doc <需求文档 URL> --scope outline
+```
+
+字段 key、状态 key、transition_id 一律现查，不要凭记忆填，见 `templates/meegle-field-mapping.md`。
diff --git a/stacks/req-tpm/templates/meegle-field-mapping.md b/stacks/req-tpm/templates/meegle-field-mapping.md
new file mode 100644
index 0000000..1bc57e0
--- /dev/null
+++ b/stacks/req-tpm/templates/meegle-field-mapping.md
@@ -0,0 +1,32 @@
+# Meegle 字段 / 状态 ↔ 需求文档映射
+
+标注说明：**已核实** = 在 meegle CLI 源码自带的 skill 文档里出现过；**假设** = 没核实，必须在目标空间用 `meegle workitem meta-fields` / `meta-roles` / `workflow list-state-transitions` 现查后替换。
+
+## 字段
+
+| 文档位置 | Meegle 字段 | key | 状态 |
+| --- | --- | --- | --- |
+| 标题 | 名称 | `name` | 已核实（skill 示例） |
+| 2. 背景与问题（摘要）+ 文档链接兜底 | 描述 | `description` | 已核实（`workitem get` 默认字段） |
+| 4. 优先级 | 优先级 | `priority` | key 已核实（skill 示例），option_id 需现查 |
+| 1. 状态 | 状态 | `status` | 已核实（MQL 示例 key） |
+| 当前处理人 | 当前负责人 | `current_status_operator` | 已核实（`workitem get` 默认字段） |
+| 关注人 | 关注人 | `watchers` | 已核实 |
+| 需求文档链接 | 自定义链接字段 | 未知 | **假设**：空间需配置一个「需求文档」链接字段 |
+| 预期效果（摘要） | 自定义多行文本 | 未知 | **假设** |
+| 提出人 / 负责人 / 执行人 | 角色 | role_key 未知 | **假设**：用 `meta-roles` 查；角色只能经 `--role-operate` 改 |
+| 方案评审意见 | 节点字段 | `node_finished_opinion` | 已核实（sop-transition-node） |
+| 评审结论 | 节点字段 | `node_finished_conclusion` | 已核实，option_id 需现查 |
+
+## 状态 / 节点（全部为假设，对应敏捷看板列）
+
+| 阶段（skill） | 建议状态 | 进入条件 |
+| --- | --- | --- |
+| req-intake | 待评估 | 文档 + 工作项已互链 |
+| req-prioritize | 待排期 → 已排期 | 负责人决定已记录 |
+| req-design | 方案中 → 方案已评审 | 决策记录 + 检查点齐全 |
+| req-track | 开发中 | 有执行人和计划时间 |
+| req-ship | 已上线 | 就绪清单全部有证据 |
+| req-outcome | 已验收关闭 / 验收未达成 | 验收表有实测来源 |
+
+工作项是状态流还是节点流取决于空间配置：状态流用 `workflow transition-state`，节点流用 `workflow transition`。
diff --git a/stacks/req-tpm/templates/requirement-doc.md b/stacks/req-tpm/templates/requirement-doc.md
new file mode 100644
index 0000000..a4caf6b
--- /dev/null
+++ b/stacks/req-tpm/templates/requirement-doc.md
@@ -0,0 +1,60 @@
+# 【需求】<一句话标题>
+
+> 本文档是这个需求的唯一事实来源。讨论结论、决策、进展、上线和验收都回到这里。
+
+## 1. 文档信息
+
+| 项目 | 内容 |
+| --- | --- |
+| 需求名称 | |
+| 需求类型 | 产品需求 / 技术需求 / 技术选型调研 |
+| 提出人（TPM） | |
+| 负责人（拍板优先级） | |
+| 执行人 | 待定 |
+| 工作项：待创建 | |
+| 跟进节奏 | 开发中每工作日 / 排队中每周 |
+| 状态 | 草稿 |
+
+## 2. 背景与问题
+
+谁、在什么场景、遇到什么问题。附真实例子（链接、截图、数据）。没有实证写「无实证」。
+
+不做会怎样，现在怎么绕过去。
+
+## 3. 预期效果
+
+| 指标或可观察行为 | 基线（来源） | 目标 | 测法与负责人 | 观察窗口 |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+非目标（这次明确不做的）：
+
+## 4. 优先级评估
+
+影响 / 成本 / 风险（档位 + 证据），与当前 WIP 的比较，建议，负责人决定（谁、何时）。
+
+## 5. 方案设计
+
+选项 A / 选项 B / 决策记录 / 波及面。
+
+## 6. 验收检查点
+
+| 检查点 | 何时 | 怎么查 | 通过标准 |
+| --- | --- | --- | --- |
+
+## 7. 进展记录
+
+（`req-track` 按时间顺序追加：进展 / 阻塞 / 下一步）
+
+## 8. 上线记录
+
+就绪清单、回滚方案、可观测性、上线时间与基线快照。
+
+## 9. 效果验收
+
+| 预期 | 基线 | 目标 | 实测（来源） | 结论 |
+| --- | --- | --- | --- | --- |
+
+## 10. 待确认问题
+
+## 11. 参考资料