cycle-review

周期回顾

周期回顾是通过 GitHub Discussion 完成的一次往返流程。分支 A 将会议纪要发布为 Discussion，并将其整理成邮件议程草稿；会议讨论这些内容；项目经理将决策发布为评论；分支 B 再将这些决策写入跟踪系统。在进入分支 A 或 B 之前，加载 house-rules 和 writing-lean。

Discussion 是记录，也是下个周期纪要进行差异比较的基准。Discussion 的存放位置以及读写方式，请参阅编辑 Discussions。

**会议期间不编辑纪要。**项目经理使用相同的标题发布评论，之后由分支 B 将其整合。

周期是 Cycle 字段的一次迭代；工作状态由 Status 字段表示。两者都位于 CLHbid Delivery 项目中。请从 issue-tracker 技能中了解字段机制、Status 值、引用约定和所有看板查询——此技能会指出所需的操作方法，但不会重复说明，因此两者不会出现偏差。

面向业务撰写

**纪要是一份完整文档，面向业务撰写。**业务方无法访问 GitHub，因此每项内容都应使用通俗语言独立说明，并以对应问题的引用结尾，供项目经理查看。不要加入 Agent 评论——工具状态、操作方法的注意事项和流程说明应在对话中告知项目经理，或写入你自己的 TODO 列表。

**使用项目经理的口吻。**纪要和邮件都代表项目经理撰写。项目经理是唯一的开发者期间，开发工作要用“我”（“我正在修复这些问题”），绝不用“我们”；

纪要也是邮件议程，应在会议前两个工作日发送，周末不计——周二回顾意味着周五发送——这样可以通过邮件回复敲定决策，会议只讨论邮件中无法解决的事项。将其创建为由项目经理发送的 Outlook 草稿；绝不要发送。收件人填写会议邀请中的受邀者，正文使用纪要内容，先列决策，并删除 GitHub 引用——业务方无法打开这些引用——最后附上会议链接。

先发邮件。业务决策和分类处理（包括 Bug）出现后，都应通过邮件告知业务方——参见 issue-tracker 中的通过邮件向业务方征询。仅面向开发者的分类处理绝不能通过邮件或纪要传达给业务方。

只记录业务工作，计数除外。纪要中的每项内容都是业务工作；开发者工作只体现在“上个周期”中的全看板计数。business 筛选条件——参见 issue-tracker 中的业务与交付：顶层问题和 Epic 的子项——是起点，而非最终答案：提出哪些条目属于业务工作，再让项目经理逐项决定，不论是否纳入。 筛选条件唯一不能遗漏的是问题：如果一项工作因等待业务方输入而受阻，而该问题是普通父项的子问题，则描述父项的工作并引用子问题，这样分支 B 才知道答案应对应哪个问题。

**目标约为 60 行，表格最多五行。**这些只是目标，并非硬性限制。请根据 30 分钟会议的时间预算安排各部分篇幅；纪要只显示顺序。

部分	分钟
上个周期	3
即将到来的日期	4
下次回顾	1
通过邮件决定	1
决策	12
本周期	4
下个周期及待办	4
后续行动	1

按阅读顺序编号。“通过邮件决定”中的条目编号为 E1、E2……；“决策”中的条目编号为 D1、D2……。议程发送邮件之前，只要条目位置发生变化，就重新编号，确保编号仍按阅读顺序排列。邮件发送后，编号固定不变：之后新增的条目使用下一个未使用的编号，放在所属部分，并标记为 (在议程发送后新增)。

周期角色

角色根据 Cycle 字段的 configuration，按照会议日期确定，绝不使用今天的日期，也不按数组顺序或标题判断：

角色	来源
closing	在 iterations 或 completedIterations 中，结束日期为会议前一天的迭代
current	从会议当天开始的迭代
future	从 current 之后开始的两个迭代

迭代在结束它的会议前一天结束，因此，提前准备的会议记录会发现 closing 周期仍在进行。分支 A 需要会议日期；如果没有日期，就停止；分支 B 从会议记录的标题中获取日期；没有会议的分支 C 则按照 issue-tracker 中的说明，以今天为准确定正在进行的周期。如果无法确定角色，就停止并说明原因——绝不臆造归属。

每次成员变更都必须针对 Cycle 字段使用 gh project item-edit，且仅适用于已提交的单元——顶层 issue 或 epic 的子项；后代会继承，且绝不设置 epic 自身的 Cycle。每次状态变更都必须使用 issue-tracker 角色映射中的 Status 值。此技能不涉及里程碑 API。

每次执行变更操作前都必须确认。 显示拟定的周期和状态值、关闭操作、issue 正文编辑、会议记录正文及迭代配置差异，取得明确同意后再操作，然后读取写入结果。写入后立即读取的结果若不一致，表示尚未确认成功，而非失败——稍等片刻后重新检查，不要重新提交。

调用方式

• A. 准备 — /cycle-review prepare for the 2026-08-28 meeting, next one is 2026-09-11
• B. 处理会议记录 — /cycle-review process the notes from discussion 2323
• C. 调整 — /cycle-review move clhbid/clhbid.com#2325 into the current cycle; defer clhbid/CLHbid-LiveAuction#922 to the next one

分支 A — 准备会议记录

分支 A 发布会议记录讨论，并且仅在第 2–5 步的记录整理过程中写入问题跟踪器。这些步骤必须先执行，在开始撰写草稿之前完成，因为它们会影响会议记录的内容。会议不会决定这些事项：将其调查结果以及每项拟议的写入操作，作为第一轮 grill-me 提问交给项目经理——每个问题都要编号，并附上建议；收到的答复即为同意。

1. 检查 Microsoft 365。 通过 Microsoft 365 连接器执行邮件搜索和会议日历搜索，并根据能力查找相应工具。如果任一项失败，请停止，并告知项目经理先修复连接器再继续。此后，Outlook 可作为以下信息的来源：通过邮件敲定的决定、仍在等待回复的问题、会议邀请对象和加入链接，以及仅通过邮件讨论的问题的状态。
2. 开启下一周期。 当前周期和两个未来周期都必须存在。若缺少任一周期，则添加；如果会议已从计划日期移开，在写入新日期之前，角色将无法解析。这是破坏性配置写入——遵循 issue-tracker 中的流程，并将所有其他待处理更改合并到同一次写入中，因为第二次写入就意味着要再恢复一次整个看板。
3. 例行整理。 运行 issue-tracker 的 stale closed items 配方，并标记其返回的项目，以及任何应当出现在看板上却未出现的问题。两者正常情况下都应为空，因此只要有结果，就说明其背后的扫描流程出了问题。只有在会议等不及的情况下，才手动使用 archiveProjectV2Item 归档。然后运行 Epic candidates 配方，逐项查看结果，并将已错过时机的项目或开放子项明显超出一个周期的史诗任务提出来——“本周期和接下来几个周期”的承诺工作就是这类任务的典型特征。是否转换由项目经理决定，且须在会议前作出，绝不是一项决定：对于每个达成一致的项目，PATCH 其类型，清空其 Cycle，为承诺纳入周期的子项设置 Cycle，并沿状态阶梯推进其 Status——参见 issue-tracker 中的 Epics。也要提出 Epics ready to close 配方返回的项目；只有业务必须作出决定时，史诗任务才进入 Decisions。以上所有内容都不写入会议记录。
4. 已合并，但仍开放。 运行 issue-tracker 的 merged pull request, open issue 配方。GitHub 并未关闭这些问题——配方会说明原因——因此它们都是已完成但从未计入任何周期报告的工作。每一行最终都应以两种方式之一处理：以 completed 状态关闭，并注明拉取请求；或判断其仍在进行，因为该拉取请求是有意只完成部分工作。出于与第 3 步相同的原因，此内容不写入会议记录。
5. 回填周期外已完成的工作。 针对收尾周期的时间范围运行 issue-tracker 的 worked off-cycle 配方，并保留业务相关结果——顶层问题和史诗任务子项。普通父项的子问题无需写入——它会继承父项的周期。这是记账工作，不是分流处理：无需会议决定。
   • 已关闭的工作计入收尾周期——设置 Cycle——并可作为上一周期亮点。
   • 收尾周期内处理过的 In progress 工作，是尚未承诺纳入该周期就已开始的工作。将其计入当前周期——未完成的工作应归属将完成它的周期——并列入本周期。
   • 休眠工作——同一配方的 dormant 变体所列、在收尾周期开始前就已停止更新的工作——不做任何写入。将其提出来，并将其状态标记为 suspect。绝不自动计入任何周期，也绝不将其重置为 Backlog。
6. 阅读看板。 查看项目条目、Cycle 配置、上一周期会议记录中的讨论，以及上次评审以来的 Outlook 内容。
7. 打开草稿。 通过文档连接器创建 Claude Doc，并直接在其中起草会议记录；项目经理在文档中评论和编辑。每次写入前都要查看其编辑内容，并予以保留。 如果没有文档连接器，则在本地 Markdown 文件中起草并说明这一点。
8. 起草上一周期，以收尾周期的主题和日期为依据，撰写 TL;DR：
   • 对周期目标给出一个词的结论：达成、部分达成或未达成。
   • 全看板计数——新增、已关闭和未关闭的问题数量，以及相较上次评审的变化趋势——并统计新增问题中有多少属于开发工作，让业务方知道这类工作存在，但不必逐项列出。
   • 最多五项亮点，包括业务方关注的史诗任务进展，以及时间范围内关闭的任何史诗任务。
   • 延期项目，每项都附上原因，且原因只能来自直接证据：已关闭的拉取请求、评论、子问题状态。不要推断原因；没有依据就不写原因。将成员变动与上一份会议记录进行比较，确保延期清晰可见，而不是悄然纳入。
9. 起草即将到来的日期，使用 Date | What 表格，每个日期一行，列至第一个未来周期结束：促销、展会等业务日期、各占一行的拟议发布，以及休假安排。日期加粗以便醒目显示，每行以类别开头（Sale:、Release (proposed):）。只保留影响计划安排的内容。上一份会议记录中的每个日期，只要仍处于此时间范围内，就全部保留。 促销日期和发布日期规则以 clhbid/CLHbid-LiveAuction 中的 RUNBOOK——Checking the Sale Schedule 和 Choosing a Release Date——为准，绝不要依据主页，因为主页只列出接下来的几场促销。结尾询问参会者是否有遗漏事项，并写上：我们应该避开哪些高风险促销日期来安排发布？
10. 起草下次评审安排——日期、时间和地点，依据调用信息或填写拟议安排。它应放在 Decisions 之前，因为它决定当前周期何时结束，从而决定本周期能容纳多少工作。绝不能安排在促销当天。
11. 起草通过邮件敲定的决定——使用 ID | Description | Decision 简洁表格，列出上次评审以来通过邮件敲定的决定，以供参考。在 Outlook 和此后记录在问题答复中的内容里查找，并与项目经理确认清单。
12. 起草待决事项——使用 ID | Description | Recommendation 表格。列出每个仍处于 Waiting on input 状态的问题、每个仍在等待回复的 Outlook 问题，以及其他任何需要实质讨论的事项，例如项目经理已完成分流并带来征求意见的陈旧工作，每项各占一行，绝不汇总成计数。描述以加粗的通俗标题开头，并说明理由；建议应是团队可以原样接受的内容。 必须已经提出过这个问题——在议题上直接留言，或在邮件中提问，都足够。如果两处都没有提出，那就是错误：从未有人被问过，因此应如实说明，而不是根据标题还原一个问题。
13. 草拟本周期——本周期的主题和日期、用一句话说明原因，并列出主要工作，同时纳入回填已认可的内容。有始有终：已处于 In progress 的工作优先处理；只要这类工作尚未完成，就不应将新工作纳入本周期——告知项目经理待办工作量。
14. 草拟下个周期及待办项——先写第一个未来周期的主题和主要工作，然后列出有意不安排周期的业务事项，以及团队询问过但尚未安排周期的工作。已承诺在第二个未来周期开展的工作也写在这里，并注明其周期名称。任何事项留在待办项中之前，都要先询问是否值得做；如果不值得，建议将其关闭并标记为未计划，如果之后应重新考虑，则加以提醒——参见 issue-tracker 中的推迟工作。
15. 草拟后续行动，放在最后——保留此部分但不填内容，以展示负责人优先的格式。
16. 发布前检查，并直接修正草稿，而不是只注明缺漏。使用 grill-me 一次处理一个问题，解决草稿提出的缺漏和待定决策：
    • 自上次草稿以来关闭的 Epic 和事项，均已计入某个周期并反映在要点中；
    • 团队询问过的工作已安排周期，或列在待办项下；
    • 销售日期来自 RUNBOOK 的来源；
    • 每个事项都能独立理解，无需查看 GitHub；
    • D 和 E 编号按阅读顺序排列，但议程发布后添加的事项除外。
17. **与实时看板核对。**每个周期部分都必须逐项与看板上的实际内容一致。
18. **发布。**项目经理确认记录定稿后，根据文档内容创建讨论帖；如果本周期的记录已经存在，则更新讨论帖，然后创建邮件草稿。项目经理要求删除文档时，将其删除。分支 A 可重复运行：只要看板有变动，就再次运行，让同一讨论帖随之更新。每次更新前都要读取实时正文，并在其基础上修改：项目经理也会在 GitHub 上编辑记录。

记录的格式见记录，草稿中不包含决策列，且后续行动留空；两者都在返回时填写。

分支 B——处理返回的记录

通过讨论编号从 API 读取已发布的正文和项目经理的评论。

按照 issue-tracker 中的引用规则解析引用：评论可能使用不带前缀的数字和别名；不带前缀的 #<number> 按 clhbid/clhbid.com 解析，该仓库托管此讨论。

1. 上一个周期 — 讨论记录就是依据，回填已为分支 A 中的每个 Cycle 字段设定了值。无需写入。

2. 清理。 没有任何未关闭事项可以仍标记为即将结束的周期（看板上的 cycle:@previous is:open）。使用 gh project item-edit 重新分配所有遗漏项——通常设为当前周期，或在工作已取消时清空该字段。遗留的孤立事项此后将不会显示在任何按周期筛选的视图中。

3. 后续日期 — 仅供参考；无需写入跟踪器。后续会议记录会将其带入。

4. 下次评审 — 商定日期决定当前周期的结束时间。将其应用到 Cycle 字段的配置。此写入具有破坏性——请遵循 issue-tracker 中的流程。分支 A 通常已完成本周期唯一一次写入，因此商定日期本应随之写入。然后在该评审前两个工作日创建一个私密的一小时 周期评审准备日历事件，不添加参与者。

5. 通过邮件决定 — 每收到一项答复时，就已执行相应写入。检查每个议题是否都记录了答复；如果没有，请从 Outlook 将其记录为决策。

6. 决策 — 对于每个已答复的问题，在议题的两个位置记录：一条引用问题的评论，前缀为 > *Recorded from the <date> planning meeting.*——邮件决策则使用 email——以及将答复整合到议题正文中，确保接手工作的人能直接看到完整规格。评论是审计记录；正文是规格。绝不要删除已有内容。会议无法解决的事项应保持原样，包括 Waiting on input 状态。

   然后将其移出 Waiting on input，且只有在议题上的每个问题都有答复时才这样做：只有当更新后的正文已成为 Agent 无需其他背景即可执行的完整说明时，才设为 Ready for Agent；如果需要判断、外部访问、设计决策或手动测试，则设为 Ready for Human；如果已有答复但仍缺少足够细节，则设为 Backlog。如果答复引出了新问题，就还没有解除阻塞：按相同格式将新问题作为评论发布，并让议题保持在 Waiting on input。

   如果某项决策承诺开展或推迟工作，则设置 Cycle，或遵循 issue-tracker 中的推迟工作流程。商定关闭的 Epic 使用 gh issue close --reason completed；如果 Epic 继续开放，则将剩余工作登记为新的子议题，使其进度不再显示为已完成。

7. 本周期和下一周期及待办事项 — 为每个已承诺的工作单元设置 Cycle，跳过分支 A 回填已计入的事项。任何周期中有子议题首次被纳入承诺后，如果 Epic 尚未处于 In progress，就将其设为该状态。商定不值得开展的待办工作应使用 --reason "not planned" 关闭；如果之后应重新考虑，则添加提醒评论；其余事项保持在 Backlog，且不设置 Cycle。

8. 后续行动 — 根据事项描述而非负责人作出判断：负责人并不能说明什么，因为项目经理自己的事项既包括委派的跟踪器工作，也包括他们亲自处理的后续任务。执行跟踪器操作——周期和状态变更、关闭事项、起草新议题。不要处理人与人之间的后续事项。

9. 为会议记录中找不到看板上对应事项的工作起草议题——只指定类别类型，不设状态，正文根据会议记录撰写。这是新输入，因此与通过模板提交的事项一样，进入 Backlog。

10. 更新讨论内容，整合各项决策——在决策表中添加 Decision 列，并填写后续行动——然后重新检查会议记录发布后已关闭的议题：会议当天早晨合并的更改会在截点后发生，否则就会被计入错误的周期。

分支 C — 调整

使用 gh project item-edit 修改 Cycle 中的归属，或在工作已取消时清空该字段，然后在下一次会议记录讨论中注明此更改。

笔记

下面是一份已完成的笔记：这是输入分支 B 收到的内容，其中已填写 Decision 列和 Next Actions。它也是目标分支 A 起草时的参照：标题相同、顺序相同、提示词相同，只是没有这些内容。请复现这种结构。

注意语体：用业务语言描述结果；在 Next Actions 中先写负责人；每个事项都以引用收尾。不要出现字段名称和 gh 语法——团队会阅读这些内容，而分支 B 能根据描述识别出跟踪事项操作。

示例仅供说明。组织、人员、仓库、问题编号和标题均为虚构。此处没有任何真实工作。

# Cycle Review — 18 Mar 2026

## Last Cycle: Faster checkout (4 Mar → 17 Mar)

**Met.** 41 issues opened and 47 closed, leaving 212 open, down from 218 at the last review. 29 of
the new issues were behind-the-scenes developer work.

- Checkout finishes in under two seconds, even on sale days. (acme/shop#412)
- Customers can save a card for next time. (acme/shop#418)
- Gift cards are 5 of 8 steps done; balance lookup went live on 12 Mar. (acme/shop#400)
- Refund rounding is fixed, after finance flagged it mid-cycle. (acme/shop#430)

**Slipped:** moving saved cards to the new payment provider. The provider limits how fast cards can
be imported, so it runs in batches this cycle. (acme/shop#424)

## Upcoming Dates

| Date                | What                                |
| ------------------- | ----------------------------------- |
| **Sat 21 Mar**      | Sale: Spring sale                   |
| **Tue 24 Mar**      | Release (proposed): better search   |
| **Tue 24 – 26 Mar** | Jordan out                          |
| **Sat 28 Mar**      | Sale: Clearance sale                |
| **Tue 7 Apr**       | Trade show; Priya and Sam attending |
| **Thu 9 Apr**       | Release (proposed): gift cards      |
| **Sat 11 Apr**      | Sale: Easter sale                   |

Anything missing? Any high-risk sales we should avoid releasing around?

## Next Review

**Wed 1 Apr 2026, 10:00 AM MT**, by video call — link in the calendar invite.

## Decided by Email

| ID  | Description                                                              | Decision         |
| --- | ------------------------------------------------------------------------ | ---------------- |
| E1  | **Delivery estimates on product pages.** (acme/shop#441)                 | Yes, this cycle  |
| E2  | **Coupons that expire mid-checkout show an error.** (acme/shop#447)      | Fix after search |

## Decisions

| ID  | Description | Recommendation | Decision |
| --- | ----------- | -------------- | -------- |
| D1  | **Who sees the new prices first?** Switching everyone at once risks confusing regulars mid-order; a staged rollout lets us watch support calls. (acme/shop#433) | Returning customers first, everyone two weeks later. | Agreed. |
| D2  | **Pay for a hosted search service?** Our search struggles on sale days, but the service costs about $400 a month and this cycle's work may fix it. (acme/api#96) | Decide after this cycle, with real sale-day numbers. | Agreed; back as a Decision on 1 Apr. |
| D3  | **Close the old admin project?** Everything is done except one old web address still pointing at the retired server. (acme/shop#380) | Close it once the address is removed this cycle. | Agreed. |

## This Cycle: Search that finds things (18 Mar → 31 Mar)

Empty search results are our biggest source of complaints, and customers give up on sale days.

- Finish moving saved cards to the new provider. (acme/shop#424)
- Search copes with hyphens and misspellings. (acme/shop#437)
- Delivery estimates on product pages. (acme/shop#441)

## Cycle After & Backlog

**Gift cards (1 Apr → 14 Apr):** finish gift cards and launch them before the Easter sale.
(acme/shop#400)

**Backlog:**

- Loyalty points, asked about by Priya — waits until gift cards have launched. (acme/shop#450)
- Dark mode for account pages — nobody has asked since it was filed; close it, and reopen if that
  changes. (acme/shop#444)

## Next Actions

- **SAM:** Remove the old web address, then close the old admin project.
- **SAM:** Close dark mode as not planned.
- **JORDAN:** Collect sale-day search numbers for the hosted-search decision on 1 Apr.

编辑讨论

笔记放在 Meetings 类别中。

所有组织范围的讨论都托管在 clhbid/clhbid.com 仓库中，无论 github.com/orgs/clhbid/discussions 显示的是什么。API 通过该仓库访问这些讨论，这也就是为什么笔记中的纯 #<number> 会在 clhbid.com 中解析。

gh 没有讨论命令，因此请使用 gh api graphql：通过 createDiscussion 和 updateDiscussion 写入，通过 repository { discussion(number:) } 读取正文和评论。

迭代改进技能

修复技能，而不是输出。 每当草稿需要手动编辑时，无论是在文档中还是在 GitHub 上，这都是一个错误报告。请修改技能并重新运行，而不是手动修补笔记。