用途
该技能用于确定某次 PostHog 代码变更何时部署到给定环境。PostHog 的 CI 在每次提交发布到环境时，会向项目写入一个部署标记注释。这些注释为 hidden_in_user_interface: true，因此不会显示在界面中，容易被忽略，但它们是“何时发布”的权威来源。当有人员询问部署时间时，应始终检查这些注释，而不是从指标或事件量变化推断（后者会把采集变更与查询/代码变更混为一谈）。
部署注释
使用 posthog:annotations-list 并传入 {"search": "deploy"} 列出注释。每条部署标记的结构如下：
- content：Deployed PostHog/posthog@<sha> to <env>，其中 env 为 prod-us、prod-eu 或 dev
- creation_type：GIT
- scope：organization
- hidden_in_user_interface：true
- date_marker：部署时间（UTC）
注释按从新到旧返回；如需继续往前查找，可用 offset 分页。
工作流
-
找到变更的合并提交。先确定 PR（例如 gh search prs --repo PostHog/posthog --author <user> "<keywords>"），再执行 gh pr view <n> --repo PostHog/posthog --json number,title,mergedAt,mergeCommit,state。记下合并提交 SHA 和 mergedAt。
-
按从旧到新列出目标环境在合并时间附近的部署。匹配用户询问的区域（询问“the US”对应 prod-us，“the EU”对应 prod-eu）。注释按从新到旧返回，因此不要只取第 1 页上第一个匹配 to <env> 的结果——那是最新的部署。需用 offset 分页，直到找到 mergedAt 附近的标记，然后按时间顺序考察该环境的部署，从第一个 date_marker 晚于 mergedAt 的部署开始。在第 3 步中按从早到晚的顺序逐一检查。
-
确认被部署的提交确实包含该合并提交。较晚的 date_marker 是必要条件但非充分条件——一次部署可能在合并后不久触发，但构建的是稍旧的提交。需要验证祖先关系：
gh api repos/PostHog/posthog/compare/<merge_sha>...<deployed_sha> --jq '{status,ahead_by,behind_by}'
behind_by 为 0 且 status 为 ahead 或 identical，表示被部署的提交包含该合并提交——即为答案。若 behind_by > 0，则该部署早于此次变更；转到该环境下一个更新的部署（时间顺序上的下一个）并重新检查。第一个通过验证的部署就是发布该变更的部署。
- 报告所询问区域的部署时间（以及 PR/commit）。如相关，可提及其他区域——prod-us 与 prod-eu 通常相隔数分钟部署，但不是同时进行。
备注
- “Live in the US”对应 prod-us；“the EU”对应 prod-eu；dev 是内部预发环境，不面向客户。
- 对于 query-runner / 读路径变更，一旦部署，新行为会追溯适用于所有数据——因此无法从事件量判断时间，只能从部署注释判断。对于采集变更，新属性的事件量可作为辅助交叉验证，但注释仍是权威的部署时间。