chips

任务卡

任务卡是项目建议的任务、运行目标之外的辅助工作，或无法在一次运行的一小时预算内完成的测量，项目所有者可以在新会话中启动。它们以行的形式存放在每个项目各自的账本中，而建议工具中的卡片只是其中一行的视图。规则依据是 .agents/pstack/rules/chips.md，sync-pstack 会将其渲染到每个项目中。除非本会话是由卡片启动的（其任务简述中包含该任务自身所需的行），否则请在本会话首次写入账本前通读全文。此技能负责运行各模式；它本身不会添加任何规则。

以下每条命令都是 node .agents/pstack/decisions-check.mjs <command>，需在项目的检出目录中运行；如果卡片会话是在自己的工作树中打开的，则应使用其任务简述打印的路径。通过运行时的会话工具获取本会话 ID，例如在 Claude Code 桌面版中使用 get_session 并传入 self，然后对每次看板读取都传入 --session <id>。没有会话工具的运行时则不带该参数读取看板。

模式	用途
清理，/chips 不带参数、/chips all 或 /chips codex	更新本会话的待办任务，为可启动的任务制卡并汇报看板；all 还会纳入没有活动会话负责的任务，codex 则强制为其提供的每张卡片执行 Codex 交接
提供	添加一项发现，这是新工作进入账本的唯一方式
启动	在卡片所属的会话中，开始卡片开启的任务
放弃	记录所有者放弃某项任务的决定

pstack 也会调用这些模式。如果 pstack 的某个步骤要创建受跟踪的问题、后续事项或 reflect Backlog 项，或要在单独的 PR 中提交范围外的修复，则由负责人改为运行「提供」。每次交接、每次压缩后以及结束时，负责人都会运行一次快速清理，此操作会跳过步骤 3。询问未完成的任务卡（例如询问辅助工作「接下来做什么」）时，运行步骤 1 和 6，不执行步骤 1 的清理，也不写入任何内容。

清理

1. 运行 chips --session <id> 和 chips stale。过期报告会列出每项未完成任务的存续时间、自提供任务以来已删除或缺失的写入路径、这些路径上的提交记录、已关闭的 PR 等待项及其卡片，并按最可能过期的任务优先排列。 然后，按照 chips.md 中 Cleanup 的说明，清理已落地任务的卡片会话。使用会话工具列出所有会话（包括已归档的会话），例如 Claude Code 桌面版的 list_sessions，并设置 include_archived，且 limit 高于会话总数；将结果保存为运行目录中的 JSON 数组，然后运行 chips cleanup --sessions <file> --session <id>。使用会话工具归档它在 Archive 下列出的每个会话，再次保存列表，重新运行 chips cleanup，并运行它打印的 scan.mjs --remove 命令。保留第一次运行中供第 6 步使用的 Report 行。在 /chips all 下，按照 chips.md 中 Owner 的说明，使用最后保存的列表，通过 chips all --session <id> --sessions <file> 再次读取看板，并从此使用该看板。没有会话工具的运行时可跳过此项。
2. 将 Do 列表显示的处理流程与本次运行中 chips.md 的 Sweep 列出的行，一并通过一次 append --from <file> 批量处理：
   • Withdrawal 处理流程：对其列出的每张卡片调用 dismiss 工具，然后按照每项的说明，记录工具报告所决定的行。
   • Ledger 处理流程：记录其列出的每一行。
   • Card 处理流程：留待第 5 步处理。
   • 检查项：使用会话工具查询每个会话。如果工具报告某张卡片对应的会话已归档或不存在，则使用该卡片条目的 card: 记录 uncarded。对于其行未列出会话的已启动任务，按照条目说明查找会话，并使用 session: 记录 started。如果工具报告已启动任务的会话已归档，则使用工具读取其最后一份报告；若某次提交包含该更改，或报告指出该会话已交付更改，则记录 landed，并在报告列出补丁时附上 patch:。如果报告交还了尚未应用的补丁，则按照 chips.md 中 Landing 的说明落地该补丁，并使用 patch: 记录 landed。只有当报告未交还补丁，且此检出目录与该会话自己的工作树中，任务涉及的路径都没有未提交的编辑时，才记录 dismissed stopped。否则，或者当工具无法找到会话时，该任务仍保持 started；第 6 步说明原因。 再次运行 chips --session <id>，并重复此操作，直到 Do 列表只剩下卡片处理，或没有可处理的内容。若 append 拒绝某个批次，请按其提示修正或删除被拒绝的行，然后追加其余内容。
3. 根据过时报告给出的每项任务，结合其简介、这些事实和代码进行判断，并一次性追加所有行：
   • 如果树中已经包含该修复，则记录 dismissed done，并引用提交。
   • 如果任务提出后其目标已被删除，则记录 dismissed superseded。如果路径只是移动了，则记录 updated，并附上新的 writes:。
   • 缺失路径指任务错误命名的路径，或任务将创建的路径。用 git ls-files 找到实际路径，并记录 updated 及该路径；如果路径由任务创建，则保留原样。已添加卡片的任务使用 updated 只能删除路径，因此其会话要在 started 行中注明实际路径。
   • 如果任务等待的 PR 已关闭且未合并，则记录 updated，并填写当前等待项。
   • 如果两个未关闭的任务在解决同一个问题，则按 chips.md 的 Sweep 所述记录主题迁移，并记录 dismissed dup。如果保留任务已有卡片或已开始，则在另一个任务上记录 waits: task:<keeper>。
   • 对于已开始的任务，如果某个提交包含其更改，则记录 landed。第 2 步的检查项会根据其会话处理其余事项，因此绝不要询问负责人该会话是否仍在运行。
   • 如果报告将某项任务标记为可能过于单薄，则在计划中查找其发现，记录或运行其提出的事项，并将其记录为一条 folded 行。如果当前会话持有该任务的卡片，则先撤销卡片。如果另一个会话持有该卡片，则等卡片离开队列后再折叠该发现。如果没有来源持有该发现，则保持任务不变。第 6 步会说明哪些任务仍然过于单薄。
   • 对于每个持有卡片且 Ready 行指出其与另一个未关闭任务共享路径的任务，按第 5 步的方式判断其依赖关系，因为它可能在有人判断依赖关系之前就已添加卡片。如果它需要另一个任务的结果，则记录 updated，并附上其等待项以及 task:<that id>，已添加卡片的任务也会采用此记录。
   • 对于每个持有卡片的任务，按第 5 步所述的 chips.md Title 规则检查其工作量；如果不符，则记录 updated 并填写正确的 effort:，已添加卡片的任务也会采用此记录。
4. 对第 3 步所做的更改重复第 2 步。
5. 卡片处理：每添加一张卡片之前，判断该任务是否需要另一个未关闭任务的结果（先检查 Ready 行指出与其共享路径的任务），或需要其工作所依赖的未关闭设计问题的结果。如果需要，则记录 updated，并附上其等待项以及 task:<that id>，而不是添加卡片。同时，按 chips.md 的 Title 规则检查简介中显示的工作量，并在某项 (xhigh) 修复的发现指出其原因及所在位置时，记录 updated 并填写 effort: high；对于尚无人定位原因的 bug 或性能问题，则填写 effort: xhigh。然后，在 suggest 工具的上次结果所列待处理卡片少于 20 张时，在同一轮中将 Do 列表中的每项任务都作为卡片提供，使用 chips brief <id> 打印出的提示词原文及其简介中显示的工作量，随后记录 carded，并填写 card: 和 session:；在 /chips codex 下还要填写 codex: always。如果运行时没有 suggest 工具，则按 chips.md 的 Limits 所述，改为将计划 ## Open work 中的每项 Ready 任务添加为卡片。添加每张卡片前，检查任务的 writes: 是否涉及某个进行中的计划；凡 Status: 以 status.mjs 中某个单词开头的计划（例如 building），都算进行中。该计划的文件包括计划本身、决策日志，以及主题文件 <plans>/topics/<topic>.md。主题取自其 Topic: 行，或取自 .agents/pstack.json 中 pageTopic.field 指定的 frontmatter 列表第一项。其会话正在改写这些文件，而 chips 只能看到台账任务，因此不要添加卡片，而应记录 updated，并附上任务的等待项以及 run:<that plan>。
6. 首先报告清理工作的 Report 行、Sweep 清理的每项任务及其提交链接，以及 scan.mjs --remove 保留的每个工作树及其原因。然后用通俗文字逐行报告此 Sweep 记录的每一行；接着说明哪些任务可以开始、是否已有卡片，并在因 20 张卡片上限而未添加卡片的每项 Ready 任务旁写上 start <id>；还要说明哪些任务已开始、为何仍未关闭，以及 drop <id> 可以关闭它们；按等待对象分组说明等待事项；并列出待审查的快速工作。当某项任务等待的是负责人尚未提交的已完成工作时，报告应在列出可开始的任务之前建议提交该更改，并指出每项已完成任务，以及提交后会有多少个等待任务获释，因为下一波工作只有在此之后才会开始。每项任务都要写出其 id 和标题。报告中提及的每个提交都应链接到 GitHub 上的该提交，格式为 https://github.com/<owner>/<repo>/commit/<sha>；owner 和仓库名应从检出目录的 origin 远程读取。报告不得向负责人提问。当会话的报告或计划中存在需要负责人决定的问题时，由 lead 解决。它应依据适用于该问题的规则，在该计划中以 look Defaults 行的形式作答，并附上决策行和发给会话的消息。如果没有规则能够回答，则由 lead 将其作为 decide 任务提出。负责人提出异议时，lead 应撤销驳回并重新提出该任务。
7. 只要有任务处于已开始或已添加卡片状态，并且运行时会在后台命令退出时重新调用 lead，就按 chips.md 的 Waves 所述，在后台运行 chips wait --session <id>。当它退出并指出某个已开始的会话时，使用会话工具查询该会话。如果该会话仍以卡片对应的工作量运行，而 chips wait 会打印该工作量，则将其工作量降至简介所示的级别；如果 suggest 工具未提供工作量，则降至你所使用的级别，具体按 chips.md 的说明执行。降低后的工作量仅从会话下一轮开始生效，因此应排队发送一条消息，告知其继续当前任务，然后停止其当前轮次。随后再次运行此 Sweep。

提议

1. 先运行 chips --session <id>，然后对每个主题或标题涉及该发现的开放任务，使用 chips brief <id> 阅读其简要说明。
2. 按 chips.md 的 Offer 说明选择对应行：
   • 如果该发现属于某个已提议任务的问题，且该任务没有卡片，就在该任务上记录一行 folded，说明该发现补充了什么。
   • 如果该发现属于某个已开始任务或持有卡片的任务的问题，就在该主题下提议一个新任务，并设置 waits: task:<id>。卡片撤回后，chips 会将它合并到持有卡片的任务中。
   • 否则，使用 chips id 获取的 ID 提议一个新任务，标题使用简单的祈使句；仅在 chips.md 的 Title 规则要求时添加 (xhigh)，并按 chips.md 的 Owner 说明设置 writes:、topic:、kind:、waits:、owns: 和 session:（本次会话的 ID），使其成为本次会话的任务。对于它写入文件的每个活动计划，其 waits: 都要包含 run:<plan>；Sweep 第 5 步会找出这些计划。如果该发现回答了看板上列出主题的问题，就复用该主题。新主题只能命名一个所有者问题，不能命名一个领域。
3. 使用 append <plans>/suggested-tasks.decisions.tsv chip "<id> <title>" "<finding>" "<tokens>" <result> 追加该行。如果 append 拒绝该行，其消息会指出对应流程；请按提示操作。
4. 将卡片留给下一轮扫描。

开始

会话领取了卡片，或负责人通过“start ”启动的任务，都必须先按 chips.md 的 Sweep 说明执行以下步骤，然后才能写入任何内容。

1. 运行 chips brief <id>，并依据其输出内容开展工作，而不是依据卡片上的提示词。
2. 运行 chips。如果任务状态既不是 Ready 也不是 Started，就告知负责人它正在等待什么，然后停止。
3. 记录 started，其中 writes: 列出简要说明中未包含的路径；如果运行时会话工具提供了会话 ID，则在 session: 中填写该 ID。随后再次运行 chips brief <id>，因为在记录该行之前，任务可能发生变化。如果会话工具显示本次会话的 Effort 高于简要说明中的 Effort:，请在首次回复时告知负责人，因为会话无法降低自身的 Effort。
4. 如果要写入任务未列出的路径，必须先再记录一行 started 并加入该路径。如果 append 因另一个已开始任务在检出目录之外写入该路径而拒绝此行，请不要修改该路径，并告知负责人。
5. 工作完成后，按简要说明中的 landing 段落和 chips.md 的 Landing 说明提交成果，记录带有 patch: 的 landed，将运行目录合并到检出目录中且不覆盖现有内容，并在清理扫描的 --landed 检查通过后，最后运行的命令删除工作树。审核任务的会话必须先对其审核的每个任务记录 reviewed。

放弃

1. 如果任务已开始，记录 dismissed stopped。
2. 如果任务持有本次会话提议的卡片，调用其 dismiss 工具。如果工具报告负责人已启动该任务，就记录 started 并告知负责人。否则，记录带有其 card: 的 dismissed declined，替代 uncarded，以避免两者之间发生合并。
3. 如果任务持有另一会话的卡片，就记录带有该卡片 card: 的 dismissed declined。
4. 如果任务没有卡片，就记录 dismissed declined。