request-progress

请求进展

My Work 会为每个 人工请求 显示一张卡片，内容基于用户自己的提示词：对话中的第一个实质性请求会涵盖后续请求，而 Agent 的工作、活动和进展则显示在其下方，即使尚未记录任何工作也是如此。不过，人们很少能在一次对话中完成目标。他们会 /clear、切换 worktree、将工作交给 Codex，第二天再回来。此技能会将每个新对话的开场请求与其项目中的未完成请求进行比对，把这些对话合并为一个 整体请求，然后根据记忆回顾每个请求并撰写构建历程。

${CLAUDE_SKILL_DIR} 是存放此文件的文件夹。每个步骤都会运行一个 CLI：

CLI="bun ${CLAUDE_SKILL_DIR}/scripts/request-groups.mjs"

此工具以只读方式打开 ~/.claude-mem/claude-mem.db，且只写入 ~/.claude-mem/work-view/。My Work 会在一秒内获取更改：归组后的对话会显示为一张卡片，从最早的请求开始，并附有进度条；请求页面会显示构建历程、已发布工作的落地情况（使用情况、价值、回归问题、各项更改的原因）及其工作成果；每张卡片都会显示其服务的负责人目标；构建历程的第一段会作为 My Work 的摘要，而故事页则会显示交付速度、叙述和偏好。回顾不会更改请求记录的状态。

默认时间范围：14 天。请使用用户指定的时间范围。

1. 将对话归入整体请求

人类请求是 My Work 的顶层内容：每段对话开头的请求要么发起一个请求，要么继续一个请求。分组时，每段对话只根据其开头的实质性请求判断一次，并保留账本中已有的决定。请求必须位于同一个项目根目录内（项目键中第一个 / 之前的部分，因此同一仓库的工作树共享请求）；对话不能加入来自其他根目录的请求，apply 也会拒绝这种操作。

$CLI grouping-input --days 14

它会返回一个批次：最多 20 段账本尚未作出判断的对话，按时间从早到晚排列，且全部来自同一个项目 root；每段对话都包含其 openingAsk 和工作列表；该根目录的 openRequests（包含标题、anchor 对话、anchorAsk、recentAsks；已交付和已放弃的请求不包括在内）；以及 proposedLinks，即代码已关联的对话，因为它们写入了同一个工作状态列表，或记录了相同的 request_id（除非列表明显是通用分类，否则保留这些关联）。remaining 统计留待后续批次处理的未决对话数量。应用每个批次后，再次运行 grouping-input，直到 conversations 为空。

判断批次中的每段对话：

• continue：它服务于某个 openRequests（或同一批次中的另一段对话）。
• new：它发起自己的整体请求（单条对话组成的组）。
• ignore：它不是人类目标（自动生成的命名提示、机器人启动消息、没有请求内容的粘贴记录）。

支持 continue 的证据，按强弱排序：

1. 请求提及之前的工作：「这项工作做得很好，现在能否……」、「继续 X」、PR 或分支名称、粘贴的交接内容。
2. 两个请求中都出现同一个具名产物（功能、页面、技能、版本发布、错误），且时间相隔几天以内。
3. 记忆能够确认：对该产物执行 mem_search，找到的观察记录描述了来自两段对话的同一项更改。

措辞相似本身不构成证据，共用同一个仓库也不构成证据。不确定时，归为 new：错误合并的卡片会隐藏工作，拆分的卡片只会出现两次。要继续某个未结请求，请先列出其 anchor，再列出新对话，保留其标题，并附上带有证据的链接。只列出批次中的对话（对于未结请求，先列出其 anchor）。

应用这些判断：

$CLI apply - <<'JSON'
{
  "groups": [
    {
      "title": "Live My Work request cards",
      "conversations": ["[\"conversation\",\"claude\",\"<earliest>\"]", "[\"conversation\",\"codex\",\"<later>\"]"],
      "links": [{ "kind": "agent-judgment", "conversations": ["…", "…"], "evidence": "Oct 16 ask: \"this is excellent work, can you now add request cards\" continues the Oct 15 build" }]
    },
    { "title": "Pricing page copy", "conversations": ["[\"conversation\",\"claude\",\"<id>\"]"] }
  ],
  "ignored": [{ "conversation": "[\"conversation\",\"codex\",\"<id>\"]", "reason": "Automated workspace naming prompt" }]
}
JSON

命令会在遇到错误时立即失败；请修正输入后重新运行。规则如下：

• 按时间从早到晚列出 conversations。第一段对话会作为组 ID 的锚点，因此后续合并不会影响审核记录。
• 包含多段对话的组至少需要一个带有证据文本的链接（shared-work-list、shared-request-id 或 agent-judgment）。尽可能引用用户原话。
• title 应用通俗的词语描述目标（≤120 chars），而不是流程。
• 一个组中的所有对话都必须来自同一个项目根目录。

然后运行 $CLI pending --days 14 --limit 48。ungroupedConversations 应为 0；groups 列出需要审核的整体请求（新请求，或自上次审核后仍处于活动状态的请求）。

2. 根据记忆审核每个待处理请求

将待处理的组拆分成每批约 8 个，并行地将每个批次交给一个子 Agent，任务如下（填写 CLI 路径和组）：

审查 claude-mem 记忆中这些整体请求的进展。对于每个 groupId：

1. 运行 <CLI> show <groupId>，查看其对话、每条完整的人类请求（含提示词 ID 和时间）、每段对话自己的观察记录（ID、时间、类型、标题）、工作清单、日期、任何先前审查以及 reviewBasis。当 mode 为 "amend" 时，该组的对话与其 previousReview 相同，且 asks 仅包含 amendSince 之后的请求：从 previousReview 开始，只搜索记忆中 amendSince 之后发生的内容，并且只修改新证据会影响的内容（状态、百分比、日期、摘要、新里程碑、结果、偏好）。其余内容保持与先前审查一致。当 mode 为 "full"（没有先前审查，或对话已变更）时，从头开始审查。
2. 搜索记忆（mem_search、timeline、get_observations）查找结果：已合并的 PR、发布、部署、标记为完成的工作状态条目、负责人确认或否定结果的记录，或停止的工作。搜索请求中提到的具体产物，不要搜索泛泛的词语。获取你所依据的观察记录。
3. 仅依据证据作出判断：
   • state：shipped（已合并并发布或部署，或负责人确认已完成）| in-progress | stalled（3 天以上没有活动且尚未完成）| abandoned（明确放弃或被替代）| unknown（记忆中的信息太少）。
   • percent：0 尚未开始 · 10–30 探索或规划中 · 40–70 构建中 · 80–95 审核中、PR 已开启或等待发布 · 仅已交付时为 100。
   • startedAt（最早的请求）、shippedAt（仅已交付时填写）、lastActivityAt，均使用 ISO 日期。
   • summary（≤280 个字符，说明为用户交付了什么）、narrative（≤1200 个字符：说明构建过程，包括方向变化、返工和经验）、milestones（≤12 项，需标注日期，且每项的 evidence 都要引用观察记录 ID 或 PR 编号）。
   • 对于任何已交付或已发布内容的请求，填写 outcome（否则省略）。先调查，再仅根据证据作答；诚实地填写“no-evidence”或“unclear”：
     • landed：{text, at, evidence}，说明交付的位置和方式：合并的 PR、发布版本、部署或已发布页面。
     • usage：{level: in-use | some-use | no-evidence | unknown, text, evidence}。查找负责人或用户后续再次提及它、它运行中的观察记录、Agent 检查过的分析数据或日志，以及针对它提交的问题。
     • value：{level: high | medium | low | unclear, text, evidence}。说明它对我们的价值：后续工作是否以它为基础、负责人是否称赞或依赖它，或是否用其他内容替代它，以及它是否消除了成本或繁琐工作。
     • regressions（≤10 项）：{text, at, fixedBy, evidence}，记录它造成的任何问题：提及它的后续修复 PR 或提交、回滚、错误报告、负责人纠正。若问题尚未修复，fixedBy 为 null。
     • changes（≤12 项）：{what, why, at, evidence}，记录每项有意义的变更；why 必须来自负责人自己的请求（引用原文）、提交或 PR 消息，或导致变更的事件。不得写出无法引用证据的原因。
   • preferences（≤10 项）：仅根据 show 展示的负责人本人请求，记录负责人偏好的 Agent 协作方式。每项包含 preference（≤200 个字符，陈述偏好）、quote（逐字引用，≤300 个字符）、kind 和 at。quote 必须为原文；kind 为 directive | correction | praise | frustration。跳过粘贴的 Agent 文本、机密信息、密钥和令牌。
4. 记录结果：<CLI> record-progress - <<'JSON' {...} JSON，其中包含 groupId、state、percent、日期、summary、narrative、milestones、outcome、preferences、evidence 和从该组 show 输出中逐字复制的 reviewBasis（它标明了你审查的对话和活动）。通过 heredoc 传递 JSON；切勿将审查文件写入磁盘，因为其他审查者会同时运行。如果命令拒绝该内容，修正后重试。子任务完成不代表请求已交付。

返回已记录的组，以及无法记录的组并说明原因。

3. 将每项请求关联到其服务的目标

在评审完成后自行运行此命令（需要评审摘要）：

1. 运行 $CLI align-input。它会返回所有者当前的目标（每个目标都包含来自所有者目标列表的精确 goal 键、标题、产品和所有者本人的引述）、仍待关联的请求组（标题、首项请求、进度状态和摘要：此步骤尚未处理的组、自上次决策后请求发生变化的组，或目标发生变化时的所有组），以及它们之前的关联。如果没有列出任何组，则跳过此步骤：所有组都已完成关联，或者所有者目标技能尚未运行，此时每张卡片仍显示“尚未关联目标”。
2. 对每个列出的组，选择它直接推进的目标：通常为一个，最多三个。如果交付该请求能推动某项目标向前发展，则该请求服务于该目标。仅仅属于同一产品领域并不足够。当前不服务于任何目标的组应列入 unaligned。如果目标或请求没有变化，则保留之前的关联。
3. 每个关联都需要 evidence（≤300 个字符）：指出请求中哪些内容推动了该目标，并引用目标或请求中的原话。
4. 记录关联。每个列出的组都必须出现在 links 或 unaligned 中；未列出的组保留之前的关联。命令会进行验证，如果未通过，请修正后重试：

$CLI record-alignment - <<'JSON'
{"links": [{"groupId": "g_…", "goal": "<exact goal key>", "evidence": "…"}], "unaligned": ["g_…"]}
JSON

“我的工作”会在每张卡片上显示关联的目标；未关联的组显示“无目标”，此步骤尚未处理的组显示“尚未关联目标”。

4. 撰写构建历程

运行 $CLI story-input。如果没有之前的历程，它会返回所有评审；如果已有历程（update: true），它只会返回自撰写该历程以来事实（状态、百分比、日期、里程碑、偏好或结果）发生变化的评审。如果没有列出任何评审，则跳过此步骤：现有历程仍然成立。更新时，保留之前历程中仍然成立的章节和措辞，只修改列出的评审所带来的变化。撰写：

• narrative（markdown，≤12000 个字符，各段之间以空行分隔，章节标题使用 ## ）：按时间顺序撰写构建历程。先用一小段介绍交付速度（“我的工作”会将其显示为回顾），然后说明最初的计划、交付了什么及何时交付、从提出请求到交付花了多久、工作在哪些地方停滞或返工，以及由此得到的经验。只使用评审中注明日期的事实。称呼此人为“所有者”或“他们”；切勿猜测代词。
• preferences（≤30）：将每项请求的偏好合并为不同且可执行的陈述，说明所有者喜欢如何与 Agent 协作。supportCount 表示体现该偏好的请求数量；最多保留 3 条带日期的原文引述。删除只出现一次的备注。

$CLI record-story - <<'JSON'
{"narrative": "...", "preferences": [{"preference": "...", "kind": "directive", "supportCount": 3, "quotes": [{"quote": "...", "at": "ISO"}]}]}
JSON

最后告知用户评审了多少项请求、其中多少项关联到目标，并用两句话说明交付速度，以及五项最突出的偏好。