Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

review: honest scorecard, one change, back to work

复盘：坦诚计分卡、至多一项调整、回归工作

Diagnose freely, change the machine once. The founder who rebuilds their system every week ships systems instead of shipping the business. Review makes the week legible, then enforces the discipline that makes next week better instead of merely different.
  the week
     |
  [ evidence ]   log rows, learnings, decisions, roadmap movement
     |
  [ scorecard ]  vs wiki/business/vision.md, failures verbatim
     |
  [ ONE change ] at most one, defended, on the record
自由诊断，仅调整一次机制。每周重构系统的创始人，最终交付的是系统而非业务本身。复盘让本周工作清晰可见，进而强化纪律性，让下周变得更好而非仅仅不同。
  the week
     |
  [ evidence ]   log rows, learnings, decisions, roadmap movement
     |
  [ scorecard ]  vs wiki/business/vision.md, failures verbatim
     |
  [ ONE change ] at most one, defended, on the record

Step 0: Preflight

步骤0：预检

Read 
${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md
and run its Universal preflight. A Fresh, Partial, or Wrong-folder result routes to 
/co-founder:co-founder-setup
(re-sync for Partial) and stops without writing a review. On Ready, read the charter and path map.
Done when: the founder system is Ready and the review evidence paths are known.
读取
${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md
并执行其中的Universal preflight。若结果为Fresh、Partial或Wrong-folder，则跳转至
/co-founder:co-founder-setup
（针对Partial状态重新同步），且停止操作不生成复盘报告。状态为Ready时，读取章程和路径图。
完成标志：创始人系统处于Ready状态，且已明确复盘证据路径。

Step 1: Gather the evidence

步骤1：收集证据

Set the review period before scoring anything. Find the latest 
type: review
page in 
wiki/business/reviews/
. For the first review, 
period_start
is the date of the genesis 
setup
row in 
log.md
; later reviews start the day after the latest 
period_end
. 
period_end
is today. If the latest review already ends today, update that same review only after explicit confirmation; never create an overlapping period.
Read that inclusive period slice, citing everything: 
log.md
rows inside the boundaries, 
baton.md
and each active initiative's Log (the canonical record of what was COMMITTED: the named next moves and dates that define "supposed to move"), learning notes written (with their cost/result), decision rows, initiative movement (steps checked, states flipped, fog graduated), anything still sitting in "Needs your call", and the previous review note's "Next week's candidate" section, carried back as a candidate only, never as pre-approved work. Read 
wiki/business/metrics.md
as the financial source of record; each number must have a dated source. Learning 
cost
/
result
fields may explain a metric but never silently replace a missing total. The vision file is the bar; no vision file means the review runs shallow and says so, recommending the vision skill first.
Every claim in the scorecard traces to a row or a file. A week with thin logs gets reported as thin on record, never reconstructed from vibes.
Apply the shared durable claim admission gate while gathering, not after scoring. Reopen every cited file and quote the row that supports the claim. A one-row tracker proves one logged block, not a 14-day measurement. Monthly recurring revenue is a run-rate, not weekly cash received or weekly net. A founder-reported result with no instrument row is 
Founder-stated: unverified
. When a downstream note repeats a claim, check the original receipt instead of trusting the note.
Reconcile lifecycle evidence before scoring it. If the founder says a piece shipped, confirm the date, update its canonical 
content_state
and 
published_at
, then reconcile its index/hub, serving roadmap checkbox, publication metric, and eligible voice-sample reference. Until that transaction is complete, report the statement as founder-stated/unverified and do not score the piece as shipped. Apply the same rule to customer evidence and roadmap completion conditions.
Review never authors or reconstructs missing customer-facing copy. A reported publication can advance an existing content file only when the vault already contains the exact published text. If the founder reports another post but supplies no text, record only the bounded publication claim as founder-stated/unverified, ask for the exact copy, and leave content lifecycle plus roadmap unchecked. Content-engine owns any new draft.
Before moving content to 
approved
or 
published
, capture the founder's exact approval or publication words in an immutable 
raw/inbox/session-receipt-<date>-<slug>.md
. Set 
approval_receipt: <path>#<exact words>
and, for publication, 
publication_receipt: <path>#<exact words>
. An edit to one phrase is not whole-artifact approval. Graph-audit rejects lifecycle state without these checked anchors. These are T1 consent surfaces (shared contract, Immutable consent receipts): with no founder yes on record, review does not advance the content state and does not write the approval field.
Done when: the week's facts are collected with their sources.
在打分前先确定复盘周期。在
wiki/business/reviews/
中找到最新的
type: review
页面。首次复盘时，
period_start
为
log.md
中初始
setup
记录的日期；后续复盘的起始日期为最新复盘记录的
period_end
次日。
period_end
为今日。若最新复盘的结束日期已为今日，则仅在获得明确确认后更新该复盘记录；绝不创建重叠周期。
读取该包含性周期内的所有内容并引用来源：边界内的
log.md
记录、
baton.md
以及每个活跃项目的Log（记录已承诺事项的权威文件：定义“应推进”的指定后续行动和日期）、已撰写的学习笔记（含成本/结果）、决策记录、项目进展（已勾选步骤、状态变更、模糊事项明确）、仍处于“需您决策”状态的事项，以及上一次复盘中“下周候选事项”部分的内容（仅作为候选事项纳入，而非预先批准的工作）。读取
wiki/business/metrics.md
作为财务记录来源；每个数据必须有日期标注的来源。学习笔记中的成本/结果字段可用于解释指标，但绝不能替代缺失的总计数据。愿景文件是衡量标准；若无愿景文件，则复盘仅做浅层分析并说明情况，优先推荐使用愿景技能。
计分卡中的每一项主张都必须追溯至某条记录或某个文件。记录单薄的一周需如实报告记录不足，绝不能凭感觉重构内容。
收集证据时同步应用共享的持久主张准入规则。重新打开每个引用的文件并引用支持主张的具体记录。单条记录只能证明一次已记录的工作块，而非14天的成果衡量。月度经常性收入是运行率，而非每周到账现金或每周净收入。无工具记录的创始人报告结果标记为
Founder-stated: unverified
。当下游笔记重复某一主张时，需核查原始记录而非信任该笔记。
打分前先核对生命周期证据。若创始人称某件事已完成，需确认日期，更新其权威的
content_state
和
published_at
字段，然后核对其索引/中心、服务路线图复选框、发布指标以及合格的语音样本参考。在完成该核对流程前，将该陈述标记为创始人自述/未验证，且不将该事项计为已完成。客户证据和路线图完成条件也适用同一规则。
复盘绝不撰写或重构缺失的客户面向内容。仅当库中已包含确切的发布文本时，报告的发布才能推进现有内容文件的状态。若创始人报告发布了另一篇帖子但未提供文本，则仅记录该有边界的发布主张为创始人自述/未验证，请求提供确切文本，且不勾选内容生命周期和路线图完成项。新草稿由内容引擎负责。
在将内容移至
approved
或
published
状态前，需将创始人的确切批准或发布话语捕获至不可变的
raw/inbox/session-receipt-<date>-<slug>.md
文件中。设置
approval_receipt: <path>#<exact words>
，对于发布状态，设置
publication_receipt: <path>#<exact words>
。仅修改一个短语不代表对整个作品的批准。Graph-audit会拒绝无这些已勾选锚点的生命周期状态。这些属于T1 consent surfaces（共享契约、不可变同意记录）：若无创始人的明确同意记录，复盘不得推进内容状态，也不得填写批准字段。
完成标志：已收集本周所有事实及其来源。

Step 2: The scorecard

步骤2：计分卡

One screen, against the vision's quarter goal and direction:
  • Moved: what actually advanced, with the receipt.
  • Stalled: what was supposed to move and did not. Verbatim, unlaundered: "the pricing page did not happen" is a fact; "made progress on positioning" covering the same week is a lie with better manners.
  • The money: what came in, what went out, what it says (from the period's dated rows in 
    wiki/business/metrics.md
    , with learning cost/result as explanation; "not tracked for this period" is a legitimate, flagged entry).
  • The vault: lessons banked this week, and notes now past their 
    review_after
    date (flag the stale list for steward's next health-check).
  • Score vs the quarter goal: on track / behind / off, in one line with the number that says so.
Done when: the founder sees the week as it was, not as it felt.
单屏展示，对照愿景中的季度目标和方向：
  • 推进事项：实际取得进展的内容，附记录凭证。
  • 停滞事项：应推进但未推进的内容。如实记录，不加修饰：“定价页面未完成”是事实；“在定位上取得进展”用来掩盖同一周的停滞则是粉饰的谎言。
  • 资金情况：收入、支出及其说明（来自周期内
    wiki/business/metrics.md
    中的带日期记录，学习成本/结果可作为补充解释；“本期未追踪”是合法的标记项）。
  • 知识库：本周积累的经验教训，以及已过
    review_after
    日期的笔记（标记该过期列表，供管理员下次健康检查处理）。
  • 季度目标达成评分：按预期推进/落后/偏离，用一句话加数据说明。
完成标志：创始人看到本周的真实情况，而非主观感受。

Step 3: The one change

步骤3：至多一项调整

At most ONE change to how the business works this week: a system, a habit, a cadence, an offer's mechanics. The founder proposes or picks from your recommendation; either way it gets defended out loud: what problem this change solves, the evidence from the scorecard, what would prove it worked by next review. Diagnosis is unlimited; surgery is rationed.
An internal, reversible workflow adjustment cites the scorecard evidence that motivates it; it uses the shared reversible-internal-experiment contract: founder yes, review date, success condition, and undo condition. It does not manufacture an outside source. A customer-facing, money, strategy, readiness-state, or hard-to-reverse change is consequential and clears both receipt legs before it can become the week's one change. A missing leg parks the candidate in the shared canonical shape; it is not the chosen change.
The founder's explicit yes is a precondition, not prose review may supply. The 
Founder's yes:
field is a T1 consent surface (shared contract, Immutable consent receipts): capture the exact yes in the immutable 
raw/inbox/session-receipt-<date>-<slug>.md
and link it as 
[receipt: raw/inbox/<file>#<exact words>]
before writing the one change or any decision row. Without that anchor, leave the candidate unchosen and write no 
Founder's yes:
field; a supplied date is never a substitute for the words.
Ask before you assert: never present a quantity, duration, sample size, date, or causal motive in prose before asking the founder for it or citing a receipt for it.
Apply the shared parameter gate before making the change concrete. A duration, cadence, or target comes from an admitted receipt or one founder question. Without it, recommend the behavior without an invented number or preserve 
Working hypothesis: unverified
as next week's candidate.
The urge for a second change goes on the record under "next week's candidate" and waits. A change that is hard to reverse, surprising, and a real tradeoff earns a decision row.
Zero changes is a legitimate outcome; a machine that worked this week does not need improving to feel productive.
Done when: at most one change is on the record with its defense, or none, said plainly.
本周至多对业务运作方式做出一项调整：可以是系统、习惯、节奏、产品机制等。创始人可自行提议或从推荐项中选择；无论哪种方式，都需公开论证：该调整解决的问题、计分卡中的支撑证据、到下次复盘时如何证明调整有效。诊断无限制，但调整需节制。
内部可逆的工作流调整需引用计分卡中推动调整的证据；需遵循共享的可逆内部实验契约：创始人同意、复盘日期、成功条件、撤销条件。不得编造外部来源。面向客户、涉及资金、战略、就绪状态或难以逆转的调整影响重大，需满足两项记录要求才能成为本周的调整项。若缺少任一记录要求，则将候选调整项存入共享的标准格式中，不选为最终调整项。
创始人的明确同意是前提条件，而非复盘可自行补充的内容。
Founder's yes:
字段属于T1 consent surfaces（共享契约、不可变同意记录）：需将确切的同意话语捕获至不可变的
raw/inbox/session-receipt-<date>-<slug>.md
文件中，并以
[receipt: raw/inbox/<file>#<exact words>]
的形式链接，之后才能记录调整项或任何决策记录。若无该锚点，则不选择候选调整项，也不填写
Founder's yes:
字段；提供日期绝不能替代明确的同意话语。
先询问再断言：在向创始人询问或引用记录之前，绝不在文本中提及数量、时长、样本量、日期或因果动机。
在明确调整内容前应用共享的参数规则。时长、节奏或目标需来自已确认的记录或创始人的回答。若无相关信息，则仅推荐行为方式，不编造数字，或保留
Working hypothesis: unverified
作为下周候选事项。
对第二项调整的需求需记录在“下周候选事项”中等待处理。难以逆转、出人意料且涉及真实权衡的调整需生成决策记录。
零调整也是合理结果：本周运作良好的机制无需为了显得有成效而强行改进。
完成标志：至多一项调整已记录并附论证，或明确无调整，表述清晰。

Step 4: Close the loop

步骤4：闭环处理

Write the review note to 
wiki/business/reviews/review-<period_end>.md
with base-five frontmatter plus 
type: review
, 
period_start
, 
period_end
, and 
review_state: complete
. List it in 
index.md
under Reviews and link 
hub/business.md
. The note's required sections: the scorecard, the one change and its defense, "Next week's candidate", "Steward queue" (notes past 
review_after
, or "None."), and "Bank queue" (reviewed initiatives and the lesson each should bank, or "None."). For every non-None item, append a pending entry to 
queue.md
: review → steward for stale notes, review → bank for reviewed initiatives. Put the queue IDs in these note sections. Queue items that live only in chat or inside a review paragraph are not queue items. Append 
## [period_end] review | <period_start> to <period_end>
to 
log.md
.
state: reviewed
has a checkable bar: the current state is exactly 
executing
, every box under the initiative's Next steps is checked OR the remaining unchecked work has been moved to 
Roadmap → Stopped
with a founder-confirmed date and reason, the scorecard names its outcome this week, "Needs your call" is "None." or explicitly non-blocking, and Parked recommendations is "None." Re-read the state immediately before writing it. 
planned
work routes to sprint or state repair; 
idea
and 
survived
route to their missing gate; 
reviewed
and 
banked
remain closed. Initiatives passing the legal 
executing → reviewed
transition get the state flip plus a Log line: 
- [date] review: outcome judged; hand to bank for <lesson topic>
. Move each changed initiative to the matching hub bucket and update the index summary, baton, roadmap conditions, and queue projection in the same linked-state transaction.
Quarterly cadence, deterministic: 12 
review
rows in 
log.md
since the last 
vision
row, or 84+ days since 
vision.md
was updated, adds a "Vision nudge" line to the note and the close; the quarter goal just got scored 12 times, and the founder knows things they did not know when they set it.
Close in chat: the score line, the one change (or none), the ONE next move.
将复盘笔记写入
wiki/business/reviews/review-<period_end>.md
，包含base-five前置元数据以及
type: review
、
period_start
、
period_end
和
review_state: complete
。在
index.md
的Reviews部分列出该笔记，并链接至
hub/business.md
。笔记需包含以下必填部分：计分卡、调整项及其论证、“下周候选事项”、“管理员队列”（已过
review_after
日期的笔记，或“无”）、“知识库队列”（已复盘的项目及每个项目应存入知识库的经验教训，或“无”）。对于每个非“无”的项，需在
queue.md
中添加待办条目：复盘→管理员处理过期笔记，复盘→知识库处理已复盘项目。将队列ID添加至笔记对应部分。仅存在于聊天或复盘段落中的事项不算队列项。在
log.md
中追加
## [period_end] review | <period_start> to <period_end>
。
state: reviewed
有明确的检查标准：当前状态为
executing
，项目后续步骤下的每个复选框已勾选，或未勾选的剩余工作已移至
Roadmap → Stopped
并附创始人确认的日期和原因，计分卡已标注本周成果，“需您决策”为“无”或明确无阻塞，“已暂停的推荐”为“无”。在写入状态前需重新核对。
planned
工作需转至sprint或状态修复；
idea
和
survived
工作需补充缺失的准入条件；
reviewed
和
banked
状态保持关闭。通过
executing → reviewed
合法状态转换的项目需更新状态并添加Log记录：
- [date] review: outcome judged; hand to bank for <lesson topic>
。将每个状态变更的项目移至对应的中心分类，并在同一关联状态事务中更新索引摘要、接力棒记录、路线图条件和队列预测。
季度节奏固定：自上次
vision
记录以来，
log.md
中有12条
review
记录，或
vision.md
更新已超过84天，则需在笔记和结尾添加“愿景提醒”内容：季度目标已完成12次评分，创始人已掌握设定目标时未知的信息。
在聊天中收尾：评分结果、调整项（或无调整）、唯一的后续行动。

Mandatory filing gate

强制归档检查

  1. Run 
    scripts/graph-audit
    on every touched durable file, including every created or reconstructed content artifact.
  2. Fix every violation and rerun it. The review, founder approval, lifecycle changes, and queue writes remain incomplete until it exits zero.
Done when: the note is filed, the log row exists, and next week's review can measure this week's change.
  1. 对所有修改过的持久文件（包括所有创建或重构的内容工件）运行
    scripts/graph-audit
    。
  2. 修复所有违规项并重新运行。只有当该脚本返回零错误时，复盘、创始人批准、生命周期变更和队列记录才算完成。
完成标志：笔记已归档，Log记录已生成，下周复盘可衡量本周的调整效果。