cycle-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Cycle Review

The cycle review is a round trip through a GitHub Discussion. Branch A publishes the meeting notes as a Discussion, the meeting works through them, the project manager posts their decisions as a comment, and branch B turns those decisions into tracker writes.

The Discussion is the record, and the baseline the next cycle's notes are diffed against. See Editing Discussions for where they live and how to read and write one.

The notes are not edited during the meeting. The project manager posts a comment using the same headers, and branch B integrates it afterwards.

A cycle is an iteration of the

Cycle

field; work state is the

Status

field. Both live on the CLHbid Delivery project. Read the field mechanics, the
Status
values, the reference convention and every board query from the
issue-tracker
skill — this skill names the recipes it needs and never restates them, so the two cannot drift.

Everything branch A reports is the business view. Every section of the notes, every number quoted beside one, and anything said in conversation about them filters to business work with the

business

filter — see Business and delivery in

issue-tracker

: top-level issues and the children of epics. Every issue table opens with an Epic column naming the epic a row belongs to, blank for ordinary work; an epic's rows sit together, ordered by

Result

. An epic itself appears only in Epics. The one thing that must not be lost to the filter is a question: when the issue blocking on business input is a sub-issue of an ordinary parent, list the parent as the item and name the child, so branch B knows which issue the answer lands on.

The notes are a business document, written with

writing-lean

. No agent commentary — tooling state, recipe caveats and process notes go to the project manager in conversation or into your own TODO list.

Cycle Review是一个通过GitHub Discussion完成的往返流程。A分支将会议纪要作为Discussion发布，会议围绕纪要展开讨论，项目经理将决策以评论形式发布，B分支将这些决策转化为跟踪器写入操作。

Discussion是正式记录，也是下一个Cycle的纪要进行差异对比的基准。关于Discussion的存放位置以及读写方式，请参见编辑Discussion。

会议期间不得编辑纪要。项目经理使用相同的标题结构发布评论，会后由B分支进行整合。

一个Cycle是

Cycle

字段的一个迭代；工作状态对应

Status

字段。两者都属于CLHbid Delivery项目。请从
issue-tracker
skill中了解字段运作机制、
Status
取值、引用规范以及所有看板查询规则——本skill仅引用它需要的流程，绝不重复定义，因此两者不会出现偏差。

A分支报告的所有内容均为业务视角。纪要的每个章节、每个章节旁的数字，以及相关讨论内容，都通过

business

过滤器筛选为业务工作项——参见

issue-tracker

中的业务与交付部分：即顶层Issue和Epic的子项。每个Issue表格的首列为Epic列，标明该行所属的Epic，普通工作项则为空；同一Epic的行放在一起，按

Result

排序。Epic本身仅出现在Epics部分。过滤器绝不能漏掉的是问题：当需要业务输入而阻塞的Issue是某个普通父Issue的子Issue时，将父Issue列为条目并注明子Issue，以便B分支知道应该将答案同步到哪个Issue上。

纪要是一份业务文档，使用

writing-lean

规范撰写。不得包含Agent评论——工具状态、流程注意事项和过程说明应通过对话告知项目经理，或记入你自己的TODO列表。

Cycle roles

Cycle角色

Roles are resolved from the

Cycle

field's

configuration

by date, never by array order or by reading a title:

Role	Where it comes from
closing	the most recent entry in `completedIterations` — the cycle the meeting closes
current	the entry in `iterations` whose `startDate + duration` brackets today
future	the two entries in `iterations` starting after current

An iteration ends the day before the meeting that closes it. If the roles cannot be resolved, stop and say so — never invent an assignment.

Every membership change is

gh project item-edit

against the

Cycle

field, on committed units only — a top-level issue or a child of an epic; descendants inherit, and an epic's own

Cycle

is never set. Every state change is a

Status

value from the

issue-tracker

role map. The milestones API plays no part in this skill.

Confirm before every mutating step. Show the proposed cycle and status values, closures, issue body edits, notes body and iteration-configuration diff, get an explicit go-ahead, then read the write back. A read-back that disagrees straight after a write is unconfirmed, not failed — re-check after a moment rather than re-issuing it.

角色根据

Cycle

字段的

configuration

按日期确定，绝不能通过数组顺序或读取标题来确定：

角色	来源
closing	`completedIterations` 中最近的条目——本次会议要收尾的Cycle
current	`iterations` 中 `startDate + duration` 覆盖当天的条目
future	`iterations` 中在current之后开始的两个条目

一个迭代在收尾它的会议的前一天结束。如果无法确定角色，请停止并说明情况——绝不能自行编造分配。

所有成员变更都通过

gh project item-edit

命令修改

Cycle

字段，且仅针对已承诺工作项——即顶层Issue或Epic的子项；子项会继承父项的Cycle，Epic本身的

Cycle

永远不会被设置。所有状态变更都使用

issue-tracker

角色映射表中的

Status

值。本skill不涉及milestones API。

每个变更步骤前都要确认。展示拟修改的Cycle和Status值、关闭操作、Issue正文编辑、纪要正文以及迭代配置差异，获得明确批准后再执行写入，然后回读验证。写入后立即回读结果不一致属于未确认，而非失败——请稍等片刻后重新检查，不要重复发起请求。

Invocation

调用方式

A. Prepare —

/cycle-review prepare for the 2026-08-28 meeting, next one is 2026-09-11

B. Process notes —

/cycle-review process the notes from discussion 2323

C. Adjust —

/cycle-review move clhbid/clhbid.com#2325 into the current cycle; defer clhbid/CLHbid-LiveAuction#922 to the next one

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

Branch A — Prepare the notes

A分支——准备纪要

Branch A publishes the notes discussion and writes to the tracker only in the bookkeeping steps below. They run first, before a line of the draft is written, because they change what the tables say. Automatic means no meeting decides them — they still show their list and take a go-ahead, like every other mutation.

Open the next cycle. Three iterations must be live: current plus two future. If only two are, add one. This is a destructive configuration write — follow the procedure in
```
issue-tracker
```
, and fold every other pending change into the same write, because a second one costs a second restore of the whole board.
Housekeeping. Run the
```
issue-tracker
```
stale closed items recipe and flag what it returns, along with any issue that should be on the board and is not. Both are healthy empty, so a result is a signal that the sweep behind them is failing. Report it to the project manager in conversation and archive by hand with
```
archiveProjectV2Item
```
only if the meeting cannot wait. Then run the Epic candidates recipe, read each result, and put the ones that slipped or whose open children plainly exceed a cycle to the project manager — work committed "this cycle and the next few" is the signature. Converting is the project manager's call, made before the meeting, never a
```
Decision
```
line: for each agreed one, PATCH its type, clear its
```
Cycle
```
, set
```
Cycle
```
on the children being committed and move its
```
Status
```
along the ladder — see Epics in
```
issue-tracker
```
. All of this stays out of the notes.
Merged, still open. Run the
```
issue-tracker
```
merged pull request, open issue recipe. GitHub closed nothing for these — the recipe says why — so each is finished work that no cycle report has ever credited. Every row ends one of two ways: closed as
```
completed
```
naming the pull request, or judged still live because the pull request was a deliberate partial. Report the closures to the project manager in conversation. This stays out of the notes for the same reason step 2 does.
Worked-off-cycle backfill. Run the
```
issue-tracker
```
worked off-cycle recipe against the closing cycle's window and keep the business results — top-level issues and epic children. A sub-issue of an ordinary parent needs no write and no row — it inherits its parent's cycle. This is bookkeeping, not triage: no meeting decision, no
```
Decision
```
line.
- Closed work is credited to the cycle it was completed in — set
```
Cycle
```
  — and appears as an extra
```
➕ Added mid-cycle, done
```
  row in Last Cycle.
- In progress
  work touched during the closing cycle was picked up without ever being committed to it. Credit it to the cycle now opening — unfinished work belongs to the cycle that will finish it — and record it in both places: an
```
➕ Added mid-cycle, not done
```
  row in Last Cycle whose reason says it carries forward, and an entry in Committed This Cycle.
- Dormant work — the dormant variant of the same recipe, untouched since before the closing cycle began — gets no write. List it as its own decision with its status flagged suspect. Never auto-credit it, and never reset it to
```
Backlog
```
  .
Read the board. Project items, the
```
Cycle
```
configuration, and the previous cycle's notes discussion.
Draft Last Cycle. Restate the closing cycle's goal, then table every committed unit in it. Result
is filled in — closed is
```
✅ Done
```
, open is
```
❌ Slipped
```
. Reason
is blank unless the row slipped or was added mid-cycle, and it is filled only from direct evidence: a closing pull request, a comment, sub-issue state. Leave it blank rather than inferring one. Diff the membership against the previous cycle's notes so slippage and mid-cycle additions are visible rather than silently absorbed.
Draft Epics. One row per open epic, from the
```
issue-tracker
```
Epics recipe: its
```
Status
```
, progress as
```
completed of total
```
, and the children committed to the current cycle. An epic closed during the window gets a final row,
```
🏁 Completed
```
. Below the table, a Ready to close line with its own
```
Decision
```
for every epic the Epics ready to close recipe returns. Closing is the meeting's call, and a decision to keep one open names what remains to be done.
Draft Next Cycle Review — date, time and location together, from the invocation or empty. It comes before Current Cycle because it sets when the cycle ends, and therefore how much fits in it.
Draft Current Cycle, sections in this order, because each one feeds the next: New Issue Triage (every issue opened since the closing cycle started,
```
Decision
```
blank), Stale Issues (next step), Waiting on Input (every
```
Status = Waiting on input
```
issue, listed one at a time with its own
```
Decision
```
, never summarised as a count), Significant Dates (a blank prompt), then Committed This Cycle, carrying anything the backfill already credited.
Report the count of items already
```
In progress
```
alongside Committed This Cycle. We finish what we start: started work takes precedence, and new work should not be accepted into the cycle while it is outstanding.
Each Waiting on Input row states the question and its decision. The question must already exist as a comment on the issue — a plain comment stating it is enough; the Triage Notes heading is a convention, not the test. If no comment asks it, that is an error: the question has never been put to anyone, so say so rather than reconstructing one from the title.
Draft Stale Issues. Run the
```
issue-tracker
```
stale issues recipe and report two numbers: the total stale, and how many went newly stale during the cycle just closing. Then do the reading:

Close candidates — a handful, judged on old, underspecified or duplicate. This means reading each candidate's body and cross-checking the board for duplicates. Sorting by age is not the job.
Needs a cycle, not a close — stale work that plainly still needs doing, flagged for pulling into this cycle's triage instead.
Newly stale, worth a look — anything that went stale this cycle and looks important on its own evidence: comment volume, a prior assignee, other issues referencing it. A judgement call, not a threshold.

Draft Future Work — one sub-section per future cycle, headed by the iteration name, each with its own table, so the load committed to each is visible at a glance.
Draft the closing sections. Out of Office is a blank prompt for the team. Next Actions is present but empty, showing the owner-first shape.
Reconcile against the live board. Every cycle section must agree with what the board actually says, item for item.
Publish. Create the Discussion, or update it if this cycle's notes already exist. Branch A is re-runnable: run it again whenever the board changes and it revises the same discussion.

Every section is worked one decision at a time. Each triage line, each

Waiting on input

question and each stale candidate carries its own

Decision

, never a shared verdict at the end of a table.

See The notes for the shape, with every

Decision

Reason

and Next Actions line blank in the draft and filled in on the way back.

A分支发布纪要Discussion，且仅在以下台账整理步骤中对跟踪器执行写入操作。这些步骤优先执行，在撰写任何草稿内容之前完成，因为它们会改变表格中的内容。_自动_意味着无需会议决策——但和其他所有变更一样，仍需展示操作列表并获得批准。

开启下一个Cycle。必须有三个活跃迭代：当前Cycle加两个未来Cycle。如果只有两个，就添加一个。这是一个破坏性配置写入操作——请遵循
```
issue-tracker
```
中的流程，并将所有其他待处理变更合并到同一次写入中，因为第二次写入会需要再次恢复整个看板。
内务整理。运行
```
issue-tracker
```
的陈旧已关闭项流程，标记返回的结果，以及所有应该在看板上却不在的Issue。正常情况下这两类都应为空，因此如果有结果，说明背后的清理机制出现了问题。通过对话将其报告给项目经理，仅在会议不能等待的情况下，才使用
```
archiveProjectV2Item
```
手动归档。然后运行候选Epic流程，逐一读取结果，将那些已延期或开放子项明显超出一个Cycle工作量的条目提交给项目经理——典型特征是被标记为“本周期及后续几个周期”的工作。转换为Epic由项目经理决定，且在会议前完成，绝不会出现在
```
Decision
```
行中：对于每个同意转换的条目，PATCH其类型，清除其
```
Cycle
```
，为已承诺的子项设置
```
Cycle
```
，并将其
```
Status
```
沿流程阶梯推进——参见
```
issue-tracker
```
中的Epics部分。所有这些操作都不会出现在纪要中。
已合并但仍开放。运行
```
issue-tracker
```
的已合并Pull Request对应开放Issue流程。GitHub不会自动关闭这些Issue——流程中说明了原因——因此这些都是已完成但从未被任何Cycle报告计入的工作。每一行最终有两种处理方式：以
```
completed
```
状态关闭并注明对应的Pull Request，或者判定为仍在进行中，因为该Pull Request是有意的部分提交。通过对话将关闭操作报告给项目经理。和第2步一样，这些操作也不会出现在纪要中。
周期外工作回填。针对即将收尾的Cycle时间窗口，运行
```
issue-tracker
```
的周期外完成工作流程，保留业务相关结果——即顶层Issue和Epic子项。普通父Issue的子Issue不需要写入也不需要出现在表格中——它会继承父项的Cycle。这是台账整理，而非Triage：不需要会议决策，也不会出现在
```
Decision
```
行中。
- 已关闭工作计入其完成时所在的Cycle——设置
```
Cycle
```
  ——并在上一Cycle中作为额外的
```
➕ Added mid-cycle, done
```
  行出现。
- In progress
  工作：在收尾Cycle期间被处理但从未被承诺纳入该Cycle的工作。将其计入当前开启的Cycle——未完成的工作属于将要完成它的Cycle——并在两个位置记录：在上一Cycle中添加
```
➕ Added mid-cycle, not done
```
  行，原因注明结转，同时在本Cycle承诺工作中添加条目。
- 休眠工作：同一流程的休眠变体，指在收尾Cycle开始前就未再被处理的工作——不执行写入。将其单独列为决策项，状态标记为存疑。绝不能自动计入，也不能将其重置为
```
Backlog
```
  。
读取看板数据。包括项目条目、
```
Cycle
```
配置，以及上一个Cycle的纪要Discussion。
起草上一Cycle内容。重述收尾Cycle的目标，然后将其中所有已承诺工作项列成表格。Result
字段需填写——已关闭为
```
✅ Done
```
，开放为
```
❌ Slipped
```
。Reason
字段为空，除非该行是延期项或周期中新增的，且仅基于直接证据填写：收尾Pull Request、评论、子Issue状态。宁可留空也不要推断。将成员构成与上一个Cycle的纪要进行差异对比，以便延期和周期中新增项清晰可见，而非被默默吸收。
起草Epics部分。根据
```
issue-tracker
```
的Epics流程，每个开放Epic占一行：包含其
```
Status
```
、进度（格式为
```
completed of total
```
），以及承诺纳入当前Cycle的子项。在时间窗口内关闭的Epic会有一个最终行，标记为
```
🏁 Completed
```
。表格下方是可关闭部分，针对可关闭Epic流程返回的每个Epic，都有单独的
```
Decision
```
行。关闭是会议的决策，如果决定保持开放，需注明剩余待完成的工作。
起草下一次Cycle Review信息——包括日期、时间和地点，从调用参数中获取或留空。它放在当前Cycle内容之前，因为它决定了当前Cycle的结束时间，从而决定了能容纳多少工作。
起草当前Cycle内容，按以下顺序排列各小节，因为每一节都为下一节提供输入：新Issue Triage（自收尾Cycle开始以来创建的所有Issue，
```
Decision
```
为空）、陈旧Issue（见下一步）、等待输入（所有
```
Status = Waiting on input
```
的Issue，逐一列出，每个都有单独的
```
Decision
```
，绝不能仅汇总数量）、重要日期（空白提示），然后是本Cycle承诺工作，包含回填已计入的所有内容。
在本Cycle承诺工作旁，报告已处于
```
In progress
```
状态的条目数量。我们完成已启动的工作：已启动的工作优先，在未完成之前，不应接受新工作进入Cycle。
每个等待输入行都要说明问题及其决策。该问题必须已作为评论存在于Issue中——普通评论说明即可；_Triage Notes_标题只是惯例，不是硬性要求。如果没有评论提出该问题，那就是错误：这个问题从未向任何人提出过，因此请如实说明，不要根据Issue标题自行推断。
起草陈旧Issue部分。运行
```
issue-tracker
```
的陈旧Issue流程，报告两个数字：陈旧Issue总数，以及在刚收尾的Cycle中新增陈旧的数量。然后进行人工研判：
- 关闭候选——少量条目，基于_过旧_、_需求不明确_或_重复_判定。这意味着需要阅读每个候选条目的正文，并交叉检查看板上是否有重复项。按时间排序不是这一步的工作。
- 需要纳入Cycle而非关闭——明显仍需完成的陈旧工作，标记为拉入本次Cycle的Triage。
- 新增陈旧，值得关注——在本Cycle内变为陈旧，且根据自身迹象看起来重要的条目：评论数量、之前的负责人、其他Issue的引用。这是主观判断，而非阈值判定。
起草未来工作部分——每个未来Cycle对应一个子小节，以迭代名称为标题，每个都有自己的表格，这样每个Cycle的承诺工作量一目了然。
起草收尾章节。外出休假是给团队的空白提示。下一步行动存在但为空，展示“负责人优先”的格式。
与实时看板对账。每个Cycle章节的内容都必须与看板的实际内容逐项一致。
发布。创建Discussion，如果本Cycle的纪要已存在则更新它。A分支支持重复运行：每当看板发生变化时重新运行，它会修改同一个Discussion。

每个章节都按决策项逐一处理。每个Triage行、每个

Waiting on input

问题、每个陈旧Issue候选都有自己的

Decision

，绝不能在表格末尾放一个统一的结论。

关于格式请参见纪要，草稿中所有

Decision

、

Reason

和下一步行动行均为空，在返回处理时填写。

Branch B — Process the returned notes

B分支——处理返回的纪要

Read the published body and the project manager's comment from the API by discussion number.

Accept both reference forms. A qualified

<org>/<repo>#<number>

resolves as written; a bare

#<number>

resolves against

clhbid/clhbid.com

, the repo hosting the discussion. Say which issue you resolved a bare reference to before acting on it.

Last Cycle — the discussion is the record and the backfill already set every
```
Cycle
```
in branch A. Nothing to write.
Sweep. No open item may still carry the closing cycle (
```
cycle:@previous is:open
```
on the board). Reassign every straggler with
```
gh project item-edit
```
— usually to current, or clear the field if the work was dropped. An orphan left behind is invisible to every cycle-scoped view from then on.
New Issue Triage — apply each line: set
```
Cycle
```
and
```
Status
```
with
```
gh project item-edit
```
, or close the issue with
```
--reason "not planned"
```
.
Stale Issues — apply each line: close candidates are closed
```
--reason "not planned"
```
; work pulled into a cycle gets its
```
Cycle
```
set like anything else triaged at this meeting; items merely flagged as worth watching get no write at all — they are informational, and they resurface in next cycle's stale report on their own.
Waiting on Input — for each answered question, record it on the issue in two places: reply to the comment that asked it, prefixed
```
> *Recorded from the <date> planning meeting.*
```
, and fold the answer into the issue body so someone picking the work up cold has the whole spec. The comment is the audit trail; the body is the spec. Never delete what was there. An item the meeting could not resolve is left untouched,
```
Waiting on input
```
and all.
Then route it off
```
Waiting on input
```
, and only when every question on the issue is answered:
```
Ready for Agent
```
only if the updated body now reads as a complete brief an agent could work from cold;
```
Ready for Human
```
if it needs judgement, external access, a design decision or manual testing;
```
Backlog
```
if it is answered but still underspecified. An answer that raises a new question has not unblocked anything: post the new question as a comment in the same shape and leave the issue on
```
Waiting on input
```
.
Significant Dates and Out of Office — informational; no tracker write.
Committed This Cycle and each Future Work section — set
```
Cycle
```
on each committed unit, skipping anything the branch A backfill already credited. The first child of an epic committed to any cycle moves the epic to
```
In progress
```
if it is not there already.
Epics — the table is informational; the Ready to close lines are writes. An agreed close is
```
gh issue close --reason completed
```
; an epic kept open has what remains filed as a new child, so its progress stops reading complete.
Next Actions — decide by what the line describes, not who owns it: the owner tells you nothing, since the project manager's own lines cover both delegated tracker work and follow-ups they handle themselves. Execute the tracker actions — cycle and status changes, closures, the new-issue draft. Leave person-to-person follow-ups alone.
Apply any agreed cycle date change to the
```
Cycle
```
field's configuration. The write is destructive — follow the procedure in
```
issue-tracker
```
. Branch A has usually already made this cycle's one write, so an agreed date should have gone in with it.
Draft an issue for work in the notes that matches nothing on the board — category label only, no state, body drawn from the notes. It is new input, so it lands in
```
Backlog
```
like anything filed from a template.
Update the discussion with the decisions integrated, then re-check for issues closed since the notes were published — meeting-morning merges land after the cut and would otherwise be credited to the wrong cycle.

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

支持两种引用格式。完整的

<org>/<repo>#<number>

格式按原样解析；仅写

#<number>

的格式会基于承载Discussion的仓库

clhbid/clhbid.com

解析。在执行操作前，请说明你将裸引用解析到了哪个Issue。

上一Cycle——Discussion是正式记录，且A分支的回填已经设置了所有
```
Cycle
```
。无需写入操作。
清理。任何开放条目都不应再属于收尾Cycle（看板上的
```
cycle:@previous is:open
```
）。使用
```
gh project item-edit
```
重新分配所有遗留项——通常分配到当前Cycle，如果工作已被放弃则清除该字段。从那以后，被落下的孤立项在所有按Cycle筛选的视图中都不可见。
新Issue Triage——执行每一行的决策：使用
```
gh project item-edit
```
设置
```
Cycle
```
和
```
Status
```
，或者以
```
--reason "not planned"
```
关闭Issue。
陈旧Issue——执行每一行的决策：关闭候选以
```
--reason "not planned"
```
关闭；被拉入Cycle的工作和本次会议Triage的其他条目一样设置
```
Cycle
```
；仅被标记为值得关注的条目完全不执行写入——它们只是信息性的，会在下一个Cycle的陈旧报告中自动重新出现。
等待输入——对于每个已回答的问题，在Issue的两个位置记录：回复提出问题的评论，前缀为
```
> *Recorded from the <date> planning meeting.*
```
，并将答案整合到Issue正文中，这样接手工作的人无需上下文就能看到完整需求。评论是审计轨迹；正文是需求规格。永远不要删除原有内容。会议无法解决的条目保持原样，包括
```
Waiting on input
```
状态在内。
然后，仅当Issue上的所有问题都得到回答后，才将其移出
```
Waiting on input
```
状态：仅当更新后的正文是完整的需求说明，Agent无需额外上下文就能直接工作时，才设为
```
Ready for Agent
```
；如果需要判断、外部访问权限、设计决策或手动测试，则设为
```
Ready for Human
```
；如果已回答但需求仍不明确，则设为
```
Backlog
```
。如果一个答案引出了新问题，说明并未解除阻塞：以相同格式将新问题作为评论发布，并将Issue保持在
```
Waiting on input
```
状态。
重要日期和外出休假——仅作信息参考；无需写入跟踪器。
本Cycle承诺工作和每个未来工作小节——为每个已承诺工作项设置
```
Cycle
```
，跳过A分支回填已计入的条目。如果某个Epic的第一个子项被承诺纳入任何Cycle，且该Epic尚未处于
```
In progress
```
状态，则将其移至该状态。
Epics——表格仅作信息参考；可关闭行需要执行写入操作。同意关闭的Epic使用
```
gh issue close --reason completed
```
关闭；保持开放的Epic需将剩余工作作为新子项提交，这样其进度就不会显示为完成。
下一步行动——根据行内容描述的事项而非负责人来决定是否执行：负责人没有参考意义，因为项目经理自己的行既包括委派的跟踪器工作，也包括他们自己处理的跟进事项。执行跟踪器相关操作——Cycle和Status变更、关闭操作、新Issue草稿。人际跟进事项则无需处理。
将所有商定的Cycle日期变更应用到
```
Cycle
```
字段的配置中。该写入是破坏性的——请遵循
```
issue-tracker
```
中的流程。A分支通常已经完成了本Cycle的一次写入，因此商定的日期应该已经在那次写入中同步了。
为纪要中看板上没有对应条目的工作起草Issue——仅添加类别标签，不设置状态，正文从纪要中提取。这是新输入，因此和通过模板提交的任何内容一样，归入
```
Backlog
```
。
更新Discussion，整合所有决策，然后重新检查自纪要发布以来关闭的Issue——会议当天早上的合并操作会在截止时间之后完成，否则可能会被计入错误的Cycle。

Branch C — Adjust

C分支——调整

Move membership with

gh project item-edit

Cycle

, or clear it when work is dropped, then note the change in the next notes discussion.

使用

gh project item-edit

修改

Cycle

字段来调整成员构成，或者在工作被放弃时清除该字段，然后在下一次纪要Discussion中记录变更。

The notes

纪要

Below is a completed set of notes — the input branch B receives, every

Decision

Reason

and Next Actions line filled in. It is also the target branch A drafts toward: the same headings, the same order, the same prompts, with those fields blank instead. Reproduce this shape.

Notice the Next Actions register: outcomes in business language, owner first. Field names and

gh

syntax never appear there — the team reads this, and branch B recognises a tracker action by what it describes.

Illustrative example. The organisation, repositories, issue numbers and titles are invented, chosen to cover the range of states the skill has to handle. Nothing here is real work.

markdown

undefined

以下是一份完整的纪要示例——B分支接收的输入，所有

Decision

、

Reason

和下一步行动行都已填写。它也是A分支起草的目标格式：相同的标题、相同的顺序、相同的提示，只是这些字段为空。请遵循此格式。

请注意下一步行动的记录方式：用业务语言描述结果，负责人在前。字段名和

gh

语法永远不会出现在这里——团队阅读这部分内容，B分支通过描述的内容来识别哪些是跟踪器操作。

示例说明。组织、仓库、Issue编号和标题都是虚构的，用于覆盖本skill需要处理的各种状态。此处没有真实工作内容。

markdown

undefined

Cycle Review — 18 Mar 2026 meeting

Last Cycle: Checkout reliability & vendor migration (4 Mar → 17 Mar 2026)

Goal: Stop checkout failing under load, and finish moving off the old payments vendor.

Epic	Issue	Title	Result	Reason
acme/site#421	acme/site#423	Export stored payment methods from the old vendor	✅ Done	—
acme/site#421	acme/site#424	Import stored payment methods into the new vendor	❌ Slipped → current cycle	The vendor's import API rate-limits at a rate that makes a single-pass import impossible; needs a batched approach.
	acme/site#412	Retry failed payment captures instead of dropping them	✅ Done	—
	acme/site#418	Checkout times out when the vendor is slow to respond	✅ Done	—
	acme/api#207	Remove the legacy payments client	✅ Done	—
	acme/infra#88	Alert on checkout error rate rather than raw 5xx count	✅ Done	—
	acme/api#215	Retire the vendor webhook shim	❌ Slipped → current cycle	Blocked on acme/site#424 — the shim cannot go until stored methods have moved.
	acme/site#430	Fix the currency rounding error on partial refunds	➕ Added mid-cycle, done	Reported by finance mid-cycle and treated as urgent; nothing was displaced to fit it.
	acme/infra#91	Rotate the credentials the old vendor had access to	➕ Added mid-cycle, done	Closed during the cycle without ever being committed to it.
	acme/api#219	Split the checkout handler so failures are isolated	➕ Added mid-cycle, not done	Picked up mid-cycle without being committed; carries into the current cycle, where it is listed under Committed This Cycle.

Decision: Both slipped items carry into the current cycle as-is. The batching approach for acme/site#424 is agreed in principle — no rework of what has already migrated.

Goal: Stop checkout failing under load, and finish moving off the old payments vendor.

Epic	Issue	Title	Result	Reason
acme/site#421	acme/site#423	Export stored payment methods from the old vendor	✅ Done	—
acme/site#421	acme/site#424	Import stored payment methods into the new vendor	❌ Slipped → current cycle	The vendor's import API rate-limits at a rate that makes a single-pass import impossible; needs a batched approach.
	acme/site#412	Retry failed payment captures instead of dropping them	✅ Done	—
	acme/site#418	Checkout times out when the vendor is slow to respond	✅ Done	—
	acme/api#207	Remove the legacy payments client	✅ Done	—
	acme/infra#88	Alert on checkout error rate rather than raw 5xx count	✅ Done	—
	acme/api#215	Retire the vendor webhook shim	❌ Slipped → current cycle	Blocked on acme/site#424 — the shim cannot go until stored methods have moved.
	acme/site#430	Fix the currency rounding error on partial refunds	➕ Added mid-cycle, done	Reported by finance mid-cycle and treated as urgent; nothing was displaced to fit it.
	acme/infra#91	Rotate the credentials the old vendor had access to	➕ Added mid-cycle, done	Closed during the cycle without ever being committed to it.
	acme/api#219	Split the checkout handler so failures are isolated	➕ Added mid-cycle, not done	Picked up mid-cycle without being committed; carries into the current cycle, where it is listed under Committed This Cycle.

Decision: Both slipped items carry into the current cycle as-is. The batching approach for acme/site#424 is agreed in principle — no rework of what has already migrated.

Epics

Work too large for one cycle, delivered a child at a time. Progress counts children.

Epic	Status	Progress	Committed this cycle
acme/site#421 · Migrate stored payment methods to the new vendor	`In progress`	3 of 8	2 · acme/site#424, acme/site#425
acme/api#198 · Schema consolidation	`Ready for Human`	0 of 6	—
acme/site#390 · Review and close the never-triaged backlog	`Ready for Human`	0 of 4	1 · acme/site#450
acme/site#380 · Retire the legacy admin	`In progress`	5 of 5	—

Ready to close

acme/site#380 — every child is closed. Decision: Kept open — the old admin's DNS entry still points at the retired host; filed as a new child, and the epic closes with it.

Work too large for one cycle, delivered a child at a time. Progress counts children.

Epic	Status	Progress	Committed this cycle
acme/site#421 · Migrate stored payment methods to the new vendor	`In progress`	3 of 8	2 · acme/site#424, acme/site#425
acme/api#198 · Schema consolidation	`Ready for Human`	0 of 6	—
acme/site#390 · Review and close the never-triaged backlog	`Ready for Human`	0 of 4	1 · acme/site#450
acme/site#380 · Retire the legacy admin	`In progress`	5 of 5	—

Ready to close

acme/site#380 — every child is closed. Decision: Kept open — the old admin's DNS entry still points at the retired host; filed as a new child, and the epic closes with it.

Next Cycle Review

Agreed first, because it sets when the current cycle ends and therefore how much fits in it.

Date: 1 Apr 2026 Time: 10:00 AM MT Location: Video call — link in the calendar invite

Agreed first, because it sets when the current cycle ends and therefore how much fits in it.

Date: 1 Apr 2026 Time: 10:00 AM MT Location: Video call — link in the calendar invite

Current Cycle: Search relevance (18 Mar → 31 Mar 2026)

New Issue Triage

Every issue opened since the last cycle, and where it landed.

Epic	Issue	Title	Status	Decision
acme/site#421	acme/site#425	Cut over checkout to the new vendor's stored methods	`Ready for Agent`	➡️ This cycle — the last step of the migration
	acme/site#437	Search returns nothing for hyphenated terms	`Backlog`	➡️ This cycle — reported by three customers this week
	acme/site#441	Add a "recently viewed" row to the listings page	`Backlog`	⏸ Reporting refresh — no urgency, and it fits that theme better
	acme/api#224	Document the search ranking fields	`Ready for Agent`	➡️ This cycle — small, and unblocks acme/site#437
	acme/infra#96	Evaluate a managed search service	`Waiting on input`	⏸ Apr 15 – Apr 28 — see Waiting on Input below
	acme/site#444	Dark mode for the account pages	`Backlog`	🚫 Closed, not planned — nobody has asked for it; reopen if that changes

Every issue opened since the last cycle, and where it landed.

Epic	Issue	Title	Status	Decision
acme/site#421	acme/site#425	Cut over checkout to the new vendor's stored methods	`Ready for Agent`	➡️ This cycle — the last step of the migration
	acme/site#437	Search returns nothing for hyphenated terms	`Backlog`	➡️ This cycle — reported by three customers this week
	acme/site#441	Add a "recently viewed" row to the listings page	`Backlog`	⏸ Reporting refresh — no urgency, and it fits that theme better
	acme/api#224	Document the search ranking fields	`Ready for Agent`	➡️ This cycle — small, and unblocks acme/site#437
	acme/infra#96	Evaluate a managed search service	`Waiting on input`	⏸ Apr 15 – Apr 28 — see Waiting on Input below
	acme/site#444	Dark mode for the account pages	`Backlog`	🚫 Closed, not planned — nobody has asked for it; reopen if that changes

Stale Issues

58 stale business issues across

Backlog

and

Ready for *

, untouched 8+ weeks; 7 newly stale since this cycle opened. 54 of the 58 are

Backlog

Triage at this scale will not be fixed one issue at a time — acme/site#390 is the lever worth pulling, and its first child is committed this cycle.

Close candidates

Issue	Title	Why it's a candidate	Decision
acme/site#102	Investigate an idea for the landing page	Open 14 months. The issue template was never filled in — every section is still an empty comment.	✅ Closed, not planned
acme/api#61	Consider caching the catalogue response	Open 9 months, empty body, no comments. The title is the entire specification.	✅ Closed, not planned
acme/api#77	Cache catalogue responses at the edge	Duplicates acme/api#61, filed later with more detail.	✅ Closed as duplicate of acme/api#61

Needs a cycle, not a close

Epic	Issue	Title	Why	Decision
	acme/api#230	Add retries to the nightly settlement export	`Ready for Agent` . Fully briefed and genuinely needed — finance re-runs it by hand every time it fails — but nine weeks without a cycle.	➡️ This cycle

Newly stale, worth a look

Epic	Issue	Title	Why it's worth a look	Decision
	acme/infra#84	Remove the old vendor's IAM roles	Went stale during the very cycle themed on the vendor migration.	✅ Closed — the work was done and the issue was left open by accident
	acme/api#198	Schema consolidation	An epic with six children and nothing committed. Real design discussion in the comments, and it looked close to agreement before it went quiet.	➡️ Reporting refresh — commit its first child

58 stale business issues across

Backlog

and

Ready for *

, untouched 8+ weeks; 7 newly stale since this cycle opened. 54 of the 58 are

Backlog

Triage at this scale will not be fixed one issue at a time — acme/site#390 is the lever worth pulling, and its first child is committed this cycle.

Close candidates

Issue	Title	Why it's a candidate	Decision
acme/site#102	Investigate an idea for the landing page	Open 14 months. The issue template was never filled in — every section is still an empty comment.	✅ Closed, not planned
acme/api#61	Consider caching the catalogue response	Open 9 months, empty body, no comments. The title is the entire specification.	✅ Closed, not planned
acme/api#77	Cache catalogue responses at the edge	Duplicates acme/api#61, filed later with more detail.	✅ Closed as duplicate of acme/api#61

Needs a cycle, not a close

Epic	Issue	Title	Why	Decision
	acme/api#230	Add retries to the nightly settlement export	`Ready for Agent` . Fully briefed and genuinely needed — finance re-runs it by hand every time it fails — but nine weeks without a cycle.	➡️ This cycle

Newly stale, worth a look

Epic	Issue	Title	Why it's worth a look	Decision
	acme/infra#84	Remove the old vendor's IAM roles	Went stale during the very cycle themed on the vendor migration.	✅ Closed — the work was done and the issue was left open by accident
	acme/api#198	Schema consolidation	An epic with six children and nothing committed. Real design discussion in the comments, and it looked close to agreement before it went quiet.	➡️ Reporting refresh — commit its first child

Waiting on Input

Epic	Issue	Question	Decision
	acme/infra#96	Is moving search to a managed service worth the cost, or do we keep running it ourselves?	Worth doing eventually, but not now — revisit once search relevance work has settled and we know the real query load. Deferred to Apr 15 – Apr 28.
	acme/site#433	Which customer segments should see the new pricing display?	Not resolved — nobody on the call had the definitive answer. Left as `Waiting on input` ; it will reappear in next cycle's notes on its own.

Epic	Issue	Question	Decision
	acme/infra#96	Is moving search to a managed service worth the cost, or do we keep running it ourselves?	Worth doing eventually, but not now — revisit once search relevance work has settled and we know the real query load. Deferred to Apr 15 – Apr 28.
	acme/site#433	Which customer segments should see the new pricing display?	Not resolved — nobody on the call had the definitive answer. Left as `Waiting on input` ; it will reappear in next cycle's notes on its own.

Significant Dates

Upcoming events to plan releases around.

Date	Event	Note
Thu 26 Mar	Quarterly catalogue refresh	Highest-traffic day of the quarter. No deploys that day; the release goes out the following morning.
Mon 6 Apr	Finance close for Q1	Refund and rounding behaviour must not change during that week.

Upcoming events to plan releases around.

Date	Event	Note
Thu 26 Mar	Quarterly catalogue refresh	Highest-traffic day of the quarter. No deploys that day; the release goes out the following morning.
Mon 6 Apr	Finance close for Q1	Refund and rounding behaviour must not change during that week.

Committed This Cycle

Epic	Issue	Title	Status
acme/site#421	acme/site#424	Import stored payment methods into the new vendor	`In progress`
acme/site#421	acme/site#425	Cut over checkout to the new vendor's stored methods	`Ready for Agent`
acme/site#390	acme/site#450	Close the never-triaged issues older than a year	`Ready for Human`
	acme/api#219	Split the checkout handler so failures are isolated	`In progress`
	acme/api#215	Retire the vendor webhook shim	`Ready for Human`
	acme/api#224	Document the search ranking fields	`Ready for Agent`
	acme/site#437	Search returns nothing for hyphenated terms	`Backlog`

Epic	Issue	Title	Status
acme/site#421	acme/site#424	Import stored payment methods into the new vendor	`In progress`
acme/site#421	acme/site#425	Cut over checkout to the new vendor's stored methods	`Ready for Agent`
acme/site#390	acme/site#450	Close the never-triaged issues older than a year	`Ready for Human`
	acme/api#219	Split the checkout handler so failures are isolated	`In progress`
	acme/api#215	Retire the vendor webhook shim	`Ready for Human`
	acme/api#224	Document the search ranking fields	`Ready for Agent`
	acme/site#437	Search returns nothing for hyphenated terms	`Backlog`

Future Work

The two cycles after the current one. Committing work here now means it has a home when the current cycle closes, rather than being re-argued every fortnight.

Reporting refresh (1 Apr → 14 Apr 2026)

Epic	Issue	Title	Status
acme/api#198	acme/api#226	Merge the two customer tables	`Ready for Human`
	acme/site#441	Add a "recently viewed" row to the listings page	`Backlog`

The listings redesign is already designed and underway in a pull request. It sits beneath acme/site#441, along with acme/site#446 — "Sort recently viewed by last visit" — which was folded in as part of that work.

Epic	Issue	Title	Status
acme/api#198	acme/api#226	Merge the two customer tables	`Ready for Human`
	acme/site#441	Add a "recently viewed" row to the listings page	`Backlog`

Apr 15 – Apr 28 2026

No theme agreed yet, so the cycle carries its dates as a placeholder until one is.

Epic	Issue	Title	Status
	acme/infra#96	Evaluate a managed search service	`Waiting on input`

No theme agreed yet, so the cycle carries its dates as a placeholder until one is.

Epic	Issue	Title	Status
	acme/infra#96	Evaluate a managed search service	`Waiting on input`

Out of Office

ALEX: Out 24–26 Mar.
No other absences reported for the current or upcoming cycles.

ALEX: Out 24–26 Mar.
No other absences reported for the current or upcoming cycles.

Next Actions

Each follow-up as OWNER: action, stated as the outcome rather than the mechanics. Tracker writes default to the project manager, delegated to the agent as needed; name the person when it is someone else's job.

SAM: Email the team proposing that Apr 15 – Apr 28 be spent clearing work that was already in progress before cycles were introduced.
SAM: Create an issue for the 26 Mar catalogue refresh — nothing on the board covers it.
ALEX: Get a definitive answer on the pricing-display segments in acme/site#433 before the next meeting, and record it on the issue.

undefined

SAM: Email the team proposing that Apr 15 – Apr 28 be spent clearing work that was already in progress before cycles were introduced.
SAM: Create an issue for the 26 Mar catalogue refresh — nothing on the board covers it.
ALEX: Get a definitive answer on the pricing-display segments in acme/site#433 before the next meeting, and record it on the issue.

undefined

Editing Discussions

编辑Discussion

Notes go in the Meetings category.

Every org-wide discussion is hosted by the
clhbid/clhbid.com
repository, whatever

github.com/orgs/clhbid/discussions

implies. That is the repo the API addresses them through, and it is why a bare

#<number>

in the notes resolves against

clhbid.com

gh

has no discussion command, so use

gh api graphql

createDiscussion

and

updateDiscussion

to write,

repository { discussion(number:) }

to read a body and its comments back.

纪要存放在Meetings分类中。

所有组织级Discussion都托管在
clhbid/clhbid.com
仓库中，不管

github.com/orgs/clhbid/discussions

的URL看起来如何。这是API访问这些Discussion的目标仓库，也是纪要中裸引用

#<number>

会基于

clhbid.com

解析的原因。

gh

没有专门的discussion命令，因此使用

gh api graphql

：写入用

createDiscussion

和

updateDiscussion

，读取正文和评论用

repository { discussion(number:) }

。

Iterating on the skill

技能迭代

Fix the skill, not the output. Whenever a draft needs hand-editing, that edit is a bug report. Change the skill and re-run rather than patching the notes by hand.

修复skill本身，而非输出结果。每当草稿需要手动编辑时，这个编辑就是一个bug报告。请修改skill然后重新运行，而不是手动修补纪要。