wrap-up

会话收尾

分阶段执行会话结束工作流，而非一次并行检查。按顺序运行：

1. 预检 — 确认仓库并记录分支。
2. 收集（只读检查 1 至 6）— 收集状态；不写入任何内容。
3. 报告 — 提供一份汇总状态清单。
4. 提交并推送（设有门槛，自动执行）— 记录副作用，然后提交待处理工作。
5. 可选后续事项（选择加入，合并为一个提示词）— 技能与学习循环。
6. 继续会话交接（自动执行，有未完成工作时才触发）— 编写启动下一次会话的提示词。

仅报告模式。 如果 Ane 调用 /wrap-up report、/wrap-up --report-only，或只要求查看状态，则运行第 1 至第 3 阶段，然后停止。不要写入、提交或运行任何后续事项，也不要编写交接内容。

日期。 使用会话环境中的当前日期。绝不要猜测。

第 1 阶段 — 预检

当前线程已关闭。 从现在起，将每个新问题、解释请求和后续要求留到第 6 阶段的交接中处理，不要在当前会话中回答。发生时用一行说明：Parked for the next session: <ask>. Ane 可以重复提出要求以覆盖此规则，此时你再回答。原因（2026-07-30 /improve-system 第 4 次运行）：连续五个有记录的会话中，线程本身都在 190k–227k 时关闭，所有超出的内容都来自决策后问答、额外检查和收尾循环。关闭会话约需 50k；在收尾时回答新要求才会让用量翻倍。

运行 git rev-parse --git-dir 2>/dev/null。如果失败（不是 git 仓库），跳过 git、harness 和提交部分。只运行检查 3 和 4，提供简短报告，并以以下内容结束：

ℹ️  Not a git repo — git, harness, and commit checks skipped.

否则，记录一次分支：git branch --show-current。将其作为第 4 阶段分支保护所用的预期分支，并在报告标题中显示。

记录本次会话写入过的所有仓库，而不仅是工作目录。 进入第 2 阶段前，列出本次会话实际操作过的仓库：工作目录，以及任何写入或提交过文件的其他仓库。将该集合记为仓库集合，并针对其中每个仓库运行检查 1、第 4 阶段门槛以及提交操作，在报告中为每个仓库标注名称。git status 只会读取当前目录，因此，如果会话在项目仓库中生成交付成果，之后又从工作文件夹执行收尾，那么报告会显示工作区干净，而实际工作仍暴露在其他位置。证据（2026-08-01）：整个会话的输出都落在工作文件夹之外的一个项目文件夹中，其中包括 Ane 手动编辑的规范版 .docx（仍未跟踪），以及一个由 Agent 写入且别处不存在的文件；工作文件夹仓库干净，若只检查该仓库就会报告“可以安全关闭”。没有远程仓库并非需要修复的问题。 为防止 OneDrive 回滚而设立的 1. Ane's PROJECTS 下三个仅本地仓库，应报告 no remote by design，跳过推送，且绝不要提议添加 origin。 对集合中另一个仓库进行只读探查可能会被拦截，而拦截通常是在提示你寻找成本更低的证据。 编辑保护机制会根据命令指定的文件夹来判断，因此，当某个仓库中有 Ane 手动编辑过的产物时，即使 git -C <other-repo> config --get ... 不会写入任何内容，也会被拒绝。不要为了读取状态而使用 --accept：保护机制正确地识别出这些产物已有改动，而为了生成一行报告就解除拦截，等于把 Ane 的保护措施花在了记录工作上。不妨先问问，是否已有证据能证明这一事实。本次会话中针对该情况通过的 harness 检查，比手动重新读取文件更有力，因为它是计算得出的，而非凭目测判断。证据（2026-09-10）：为了确认一次刻意的临时还原已恢复，在收尾时读取 Personal-project-a 的 user.email，因该仓库中的两个手动编辑过的 .docx 文件而被拦截；check_git_identity_by_content 已经断言了同一情况且检查通过，因此检查结果就是答案，无需再读取文件。如果没有现成的断言，就把探查单独放在一条命令中：当天被拦截的调用与桌面同步和交接状态检查打包在一起，导致这两项检查也一并失败。

恢复检查——绝不要完整执行两次收尾流程。 如果本次会话中已运行过收尾流程，并在第 4 阶段的 harness 关卡处停止，那么这次调用是恢复流程（RESUME），而不是重新开始收尾。先说 Resuming wrap-up at the harness gate.，然后只运行：harness（第 2 阶段的检查 2）、第 4 阶段的关卡、提交和推送，以及第 6 阶段。除此之外跳过第 2 和第 3 阶段；除非 Ane 要求，否则跳过第 5 阶段。相关检查结果没有变化，重新推导这些结果是收尾过程中最大的一笔可避免成本：2026-07-28 的 local-analyst-mirror-freshness-check 记录显示，执行了两轮收尾流程，还进行了成本日志核对，几乎使本次会话的开销翻倍。恢复流程只需运行一次 harness 并完成一次提交，不需要再做一遍会话复盘。

第 2 阶段 — 收集（只读检查）

1. Git 状态 运行 git status --short。对于尚未推送的提交，运行 git log --oneline "@{u}.." 2>/dev/null。如果分支没有上游（git rev-parse @{u} 失败），请明确说明：尚无内容推送，推送步骤会设置 -u。没有上游时，不要报告“全部已推送”。报告未提交文件（数量 + 列表）、未推送提交（数量 + 列表）以及当前分支。如果两者都为空，请明确说明。

已提交并已推送，不等于已进入目标分支。 git status 和 @{u}.. 都是相对于当前所在分支进行检查，因此，会话工作的所在分支若是某个功能分支，就可能报告“没有未提交内容，全部已推送”，但真正被使用的分支仍保留旧内容。只要会话的目的是改变其他界面读取的内容，这一点就很重要，例如镜像、已发布的默认分支、npx skills add（它会从默认分支安装，而不是从你的分支安装）、部署或发布。因此，如果会话工作旨在改变远程发布的内容，请对照 origin/<default-branch> 进行验证，并在报告中说明检查的是哪个分支。证据（2026-08-03）：两个仓库都处于 wave0-skill-fixes 分支；每次清理提交都报告成功，但 origin/main 仍包含会话删除的全部 25 个文件，以及另外 5 个文件中的个人项目名称。收尾时两个仓库的状态都显示干净。如果当天运行了定时镜像，同步过去的就会是本次会话原本要删除的所有内容。只需两行即可完成这项低成本检查：git ls-tree -r --name-only origin/main -- <path-that-should-be-gone> | wc -l 和 git rev-list --left-right --count origin/main...HEAD。 同一项检查也适用于反向情况：产物已经提交，但依赖项没有。 会话可以正确地将使用方提交到其默认分支，却仍然让该使用方无法使用，因为它导入的模块还留在另一个仓库里尚未合并的功能分支上。所有本地检查都能通过——两棵工作树都干净、两个分支都已推送、测试框架也通过——因为工作树检出了该分支，导入也能正常解析。因此，如果会话提交的内容导入了自己也编写的代码，请在导入目标自己的 origin/<default-branch> 上验证，而不只是检查产物。一行命令：git show origin/main:<module-path> | grep -c "def <the-new-function>"，结果为 0 就意味着使用方正在使用其他人都拿不到的代码。证据（2026-08-03，wave-2-office-review-pass）：office-review-pass 技能已提交到 personal-skills 的 main 并全局安装，但它导入的 render_review 只存在于 work-folder 仓库的 wave2-office-review-pass 上；检出 main 后，技能的读取模式在导入时就会报错。解决办法是在结束会话前合并，而不是把这件事留给下一次会话的第一步——交接说明不能代替可正常使用的默认分支。

工作树干净并不能证明没有发生劫持。 Phase 4 的分支完整性门禁只会在有内容需要提交时运行，而 check-branch-integrity.sh 只检查领先于 origin/main 的提交。后台循环若一次性完成提交并推送，就能同时绕过这两项检查：没有未提交内容，也没有领先的提交，门禁报告 Clean，却根本没有运行。2026-07-28，提交 622325d 于 21:16:57 出现在 main 上，并非由该会话编写；它还顺带将该会话自己的两个提交推送到了 origin。收尾时工作树干净，领先提交数为 0，因此没有任何检查发现问题。因此，这项检查应始终列出会话时间段内的提交，无论推送状态如何（git log -10 --format="%h | %ad | %s" --date=format:"%H:%M:%S"），并在 ERRORS 下将主题不为会话所识别的提交标记为 ⚠️ Unattributed commit。报告问题，但不要采取行动：该提交已经在 origin 上，在收尾时将其还原，比指出问题更危险。参见 reference_loop_guard_gap_markerless 记忆。

2. 测试框架（项目感知） 如果仓库根目录存在 tests/run_tests.py，并且会话改动过测试框架覆盖的文本文件（Markdown、代码、配置），则运行 python tests/run_tests.py 并报告结果。请使用普通 Bash 工具运行，绝不能只通过 context-mode 的沙箱运行：沙箱 Shell 使用 UTF-8 编码，曾掩盖两个 cp1252 UnicodeEncodeError 错误（Wave 3 和 Wave 5-2，2026-08-04），而这些错误在 Ane 自己的终端中会导致测试失败。“改动过”是指本会话期间任何时候编辑过，无论更改仍未提交还是已经提交。若通过，报告 ✅ Harness N/N。若失败，逐项列出失败，并标记为 ⚠️ HARNESS:，同时建议使用 /test 查看详情。如果测试框架文件不存在，则静默跳过此项检查——大多数仓库都没有 MEL 测试框架。

不要根据工作树是否干净来决定是否运行此检查。 工作树干净意味着更改已提交，不代表更改正确。2026-07-28，收尾时工作树干净，但测试框架未通过：某项编辑改到了 claude-ai-shareable-export/（生成的镜像目录），而不是规范的根文件，check_claude_ai_sync 因此发现了差异。如果以未提交文件为门槛，会在测试框架未通过、损坏的 claude.ai 导出文件已推送到 origin 的情况下结束会话。 对失败的同步或镜像检查重新运行一次，再采取行动。 比较同一文件的两个副本（技能缓存与克隆、生成的镜像与规范版本）的检查，在并行进程正在写入时可能会暂时失败。2026-07-28，skill-repo:local cache content matches clone 报告 drifted: ann, vi，当时后台 npx skills add 正在传播刚推送的提交；这两个文件的字节内容已经完全一致，克隆也已推送。若根据该检查失败时给出的建议“push to personal-skills”采取行动，就会做错。将测试脚本重新运行一次：如果失败消失了，那就是发生了竞争。如果仍然失败，在复制任何内容之前，先诊断哪一侧已过时，因为复制会覆盖较新的一侧（参见 reference_skills_mirror_stale_clone_gotcha 记忆）。

3. 最近的错误 扫描本次对话，查找错误消息、失败的命令，或已发现但尚未修复的问题：堆栈跟踪、“error:”、“failed”、“TODO”、明确表示“我稍后会修复”的内容。

4. 待处理事项 找出 Ane 表示会做或尚未完成的事项：

• 待审核或发送的文件
• 提到的后续任务
• 延后的决定
• 尚未采取的明确“下一步”

5. 未提交更改风险 如果存在未提交文件，请运行 git diff --stat，评估有哪些内容可能丢失。

6. Desktop / claude.ai 导出差异（基于项目判断） 如果仓库根目录中存在 scripts/check_desktop_sync.py，请运行 python scripts/check_desktop_sync.py。此脚本会显示自上次上传后发生变化的 claude.ai Desktop 项目文件（claude.ai 项目没有文件 API，因此必须始终手动重新上传）。如果报告 [DRIFT]，请列出 Ane 必须重新上传的导出文件，以及后续的 --mark-synced 操作。如果报告没有差异，或脚本不存在，则静默跳过本节。

第 3 阶段 — 报告

以简洁的清单形式交付。每项一行。不要写引言。

SESSION WRAP-UP — [date] — branch [branch]

GIT
  ✅ Nothing uncommitted          OR  ⚠️  N file(s) uncommitted: [list]
  ✅ All pushed                   OR  ⚠️  N commit(s) not pushed: [list]   OR  ⚠️  No upstream — nothing pushed yet

HARNESS (only when relevant files were touched)
  ✅ N/M checks passed            OR  ⚠️  N harness check(s) failing — /test for detail

ERRORS
  ✅ No unresolved errors         OR  ⚠️  [description of unresolved issue]

PENDING ACTIONS
  ✅ Nothing open                 OR  ⚠️  [action]: [what Ane committed to]

DESKTOP SYNC (only when scripts/check_desktop_sync.py exists and reports drift)
  ⚠️  Re-upload to claude.ai Desktop: [export file(s)] — then run check_desktop_sync.py --mark-synced

RECOMMENDATION
  [One sentence: either "Safe to close" or specific action to take first]

在仅报告模式下，到此为止。

第 4 阶段 — 提交并推送

报告之后，如果存在未提交文件或未推送的提交，请在本工作时段结束前完成提交并推送。Ane 有一项长期指示：每个工作时段结束时都要提交并推送。不要征求是否可以提交当前会话中尚未提交的工作——直接执行。以下关卡仍然适用。

关卡 1 — 测试脚本必须通过（如果已运行）。 如果第 2 项检查已运行，且报告中出现任何 ⚠️ HARNESS: 行，则停止。不要提交。告知 Ane 测试脚本未通过，并建议使用 /test 查看详情。到此结束本次收尾。

同时说明恢复路径，否则停止会导致多做一次完整检查：修复后重新运行 /wrap-up — 它会从测试脚本关卡继续，不会重复会话检查。如果没有这句话，Ane 会重新启动一次全新的收尾流程，并因未发生变化的问题而将第 2、3 和 5 阶段重复执行两遍。

关卡 2 — 分支保护（检出 + 内容）。 首先，将当前的 git branch --show-current 与第 1 阶段记录的预期分支进行比较。如果不同，后台进程可能在会话期间检出了另一个分支并接管了工作树（这是记录在案的 ralph-loop 隐患）。停止，并先询问 Ane，再进行提交。 然后防范分支名称检查无法发现的内容劫持（循环将自己的提交提交到匹配的分支上）。如果仓库根目录中存在 scripts/check-branch-integrity.sh，就运行它。若发现循环创建的提交，或直接位于 main 上的提交，它会以非零状态码退出（SUSPICIOUS）。遇到 SUSPICIOUS 时，停止：列出检查结果，并在提交或推送前询问 Ane，origin/main 领先的每个提交是否都是她创建的。如果脚本不存在（大多数仓库都没有），则静默跳过这一步。报告：

BRANCH INTEGRITY
  ✅ Branch matches + commits ahead of origin/main verified
  OR  ⚠️  SUSPICIOUS — [findings]; commit/push held pending Ane's confirmation

SUSPICIOUS 不是定论——在重复脚本的建议前，先进行检查。 脚本给出的恢复文本（cherry-pick、reset --hard、push --force-with-lease）是针对循环劫持编写的，而且具有破坏性。它的三种症状中有两种，在第二个 Claude Code 会话提交仓库自身的工作时也同样容易触发；仓库按设计直接提交到 main 时也会触发，而这个仓库正是如此。因此，在报告任何结果前，对脚本标记的每个提交运行 git show --stat <sha>，并明确说明该提交内容是否是本会话认可的工作。除非脚本报告了循环标记，否则绝不要把重置建议作为推荐方案转述给 Ane。证据（2026-07-31）：提交 29d2a31 在收尾过程中途进入了 main，并非本会话创建；它恰好包含几分钟前尚未提交的六个文件，因此这是另一个并行会话的提交，而 reset --hard 会毁掉一晚上的真实工作——这些工作当时根本没有受到威胁。

如果两项检查都通过，说明即将提交到的分支，然后继续。

门槛 3 — 敏感文件扫描（先检查文件名，再检查内容）。

*3a — 文件名扫描。*暂存前，对未提交文件列表进行不区分大小写的模式匹配：.env、.env.*、*credentials*、*secret*、*token*、*.key、*.pem、*.pfx、*api_key*。可能会匹配到无害的名称（例如 token_utils.py），因此应将匹配项视为需要确认的问题，而非定论：列出匹配项，并明确询问 Ane 哪些（如果有）要纳入提交。

*3b — 约定与内容扫描。*文件名扫描只读取名称，而个人数据恰恰会隐藏在普通名称背后。2026-07-03，在 Personal-project-a 仓库中，六份文档包含两人的国家登记号码、身份证号码和 IBAN，另有三张身份证扫描件；这些文件通过了文件名扫描，却被暂存到了一个公开的 GitHub 远程仓库。所有文件名看起来都很普通。只有人工判断发现了问题，而这并不算有效的防护措施。

因此，完成 3a 后，对实际已暂存的内容运行内容扫描：

python <skill-dir>/scripts/scan_staged_privacy.py --repo .

它会检查两类文件名扫描无法发现的问题。首先是仓库自身的约定：如果 .gitignore 声明了隐私文件族（*.local.*、**/*private*），那么任何包含个人数据却没有标记的已暂存文件，都违反了仓库已经设定的规则。建议重命名，而非提交——重命名为 *.local.* 不只是给文件加上标记，还会将其从提交中排除，因为仓库已经忽略了这类文件。其次是内容：罗马尼亚 CNP、比利时 rijksregister 和 IBAN，均通过各自的校验和确认，而非仅凭数字位数判断；此外还会检查看起来像身份证件的图片文件名。

查看退出码，而非说明文字：

退出码	含义	处理方式
0	未匹配到任何内容	静默继续——不作说明
1	ADVISORY：存在个人数据，但远程仓库为私有，或不属于公共代码托管平台	在收尾报告中说明发现的问题，然后继续提交
2	HOLD：存在个人数据，且远程仓库属于公共代码托管平台	不要提交或推送；列出发现的问题，并请 Ane 确认或重命名
此检查会刻意优先避免阻塞。 如果检查门会打断干净的会话，用户就会直接点过，检查门也就起不到任何保护作用。只有个人数据与可公开访问的远程服务同时出现时，才值得阻止操作——这是唯一一种出错后无法挽回的组合，因为内容一旦推送到公开代码托管平台，就会立即公开；即使之后删除，也仍会留存在克隆副本和缓存中。其他情况都只需在报告中注明。

在相信或质疑结果之前，有两点需要了解。扫描器的发现结果会按设计进行掩码处理：它只输出文件、行号和类型，绝不输出具体数值，因为其输出会进入会话记录，进而进入交接文件。它还会通过校验和验证，因此 13 位的 Unix 毫秒时间戳或 11 位的订单 ID 都不会匹配——在 Ane 工作语料库的 3,546 个文件中进行测量，匹配次数为 0。因此，出现匹配就说明确实有情况。如果脚本缺失（旧版安装），请在报告中说明，并仅回退到 3a，不要悄悄跳过检查门。这仅涵盖已暂存的内容；/li lint 会检查 wiki。

检查门 4——排除 WIP。 如果任何未提交文件与当前会话的工作无关，而且看起来仍处于编辑中（例如，用户显然在另一个窗口中开发的单个文件，其中行内新增了 TODO 标记或 None 占位符），请将其排除在提交之外。在报告中列出排除的文件，让 Ane 知道有哪些内容被留下。

副作用写入——QA 驳回日志（按项目处理）。 仅在所有检查门通过后、暂存之前运行。如果本次会话运行了 Ann/Vi 编排（生成了任何 qa_block），并且 agent-improvements/qa-rejection-log.md 存在，则每次编排运行追加一行：日期、任务 slug、overall_verdict、重新委派次数、驳回/标记原因（每条 ≤15 个词，以分号分隔；如果 verdict 是干净的 PASS，则填写 —）。/improve-system 会读取此日志，以检测反复出现的失败模式并追踪驳回率趋势。将刚写入的文件与其他内容一并暂存。如果没有生成 qa_block 或日志文件不存在，则静默跳过。

明确暂存。 按文件名添加文件（git add path/to/file path/to/other），如果刚刚写入了 QA 日志，也要一并添加。绝不要使用 git add -A 或 git add .——这会把被 gitignore 忽略的运行时状态、操作系统元数据和无关的 WIP 一并纳入提交。

起草提交消息。 遵循近期风格：运行 git log --oneline -10，并使用相同的 Conventional Commits 前缀方案（feat:、fix:、docs:、chore:、refactor:，可选范围，例如 docs(overlay):）。单行标题不超过 72 个字符；仅当原因不明显时，添加一到两句正文。只有当前生效的 CLAUDE.md 或运行框架要求时，才添加 Co-Authored-By 页脚。

提交。 通过单引号 HEREDOC 传入提交消息，这样 PowerShell/bash 就不会展开 $ 或反引号：

git commit -m "$(cat <<'EOF'
<title>

<optional body>
EOF
)"

推送。 运行 git push。如果分支没有上游分支，则设置上游：git push -u origin <branch>。如果因远程分支领先而被拒绝推送，则运行 git pull --rebase，然后运行 git push——此技能中绝不使用 --force。如果推送卡住（超时）或因凭据／身份验证提示而失败——Git Credential Manager 无法在 Claude Code 会话中显示提示——则通过 GitHub CLI 存储的令牌重试——但要先重置凭据助手链：git -c "credential.helper=" -c "credential.helper=!gh auth git-credential" push。空的 credential.helper= 至关重要。-c 会将配置追加到继承的助手链，而不是替换它，因此简单的 git -c "credential.helper=!gh auth git-credential" push 会让 Git Credential Manager 仍排在首位，并像未经修改的推送一样卡在 GCM 上（已观察到两次，2026-07-27，每次卡住超过 2-3 分钟的超时时间；重置后则在几秒内完成推送）。在归咎于网络之前，先确认令牌存在：gh auth status 应显示一个带有 repo 范围的 gho_ 令牌。快速诊断，不要等超时：GIT_TERMINAL_PROMPT=0 git -c credential.interactive=never push 会在凭据是问题根源时立即报错 "cannot prompt"。推送超时不会导致提交丢失；重新提交前检查 git log "@{u}.."（参见 reference_git_push_credential_hang 记忆，2026-07-16）。超时后重试前，先终止超时操作留下的陈旧 git.exe 进程——这些进程会占用连接／锁，若不清理，所有重试都会被阻塞（已于 2026-07-16/17 验证 3 次）：for pid in $(tasklist //FI "IMAGENAME eq git.exe" //FO CSV | tail -n +2 | cut -d',' -f2 | tr -d '"'); do taskkill //PID $pid //F; done，然后重新推送。

在报告中确认。 追加：

COMMIT & PUSH
  ✅ Committed <short-SHA> "<title>" to <branch>
  ✅ Pushed to <remote>/<branch>

或者，如果某个关卡阻止了提交：

COMMIT & PUSH
  ⚠️  Skipped — <reason>: [files]

如果工作区原本就干净，且没有尚未推送的提交，则完全省略本节。

阶段 5 — 可选后续操作（选择加入）

提交后可以运行四个相互独立的循环。这些循环都不会阻止提交。逐一检查下方各循环的触发条件；对于确实触发的每个循环，将它们合并到一个提示词中，这样 Ane 只需回答一次：

Optional follow-ups (enter to skip all):
  [1] Skill improvement — <skill>: <one-line change>
  [2] Save skill idea to backlog — <NEW|ENHANCE> <skill>
  [3] 3-line learning capture → journal
  [4] Log token cost actual → cost-calibration-log
Reply with the numbers to run, or enter to skip.

如果只有一个循环触发，则直接单独提出其一行提示词。如果都未触发，则不做说明，结束收尾。按顺序 1、2、4、3 运行已接受的循环。循环 3 按设计最后运行（知识库可能无法访问，而且它最不重要）；循环 4 只写入工作文件夹中的仓库，因此可以安全地在循环 3 之前运行。

循环 1 — 技能改进记录（内联修复，本次会话）

记录本次会话实际使用的技能的一项单次会话、可泛化的改进：会反复出现的问题、导致返工的遗漏步骤，或技能尚未记录的新近验证能力。

触发条件。 本次会话运行了某项技能，且对该技能做出具体、可泛化的更改，本可节省时间或避免本次会话中的错误。不要因项目专属信息（应写入自动记忆，而非技能）、琐事或跨会话反复出现的模式触发（这是 /improve-system 的职责）。

接受后，对每项已确认的技能：

1. 编辑技能的仓库克隆，绝不要编辑在线的 ~/.claude/skills/<name> junction（SessionStart 的 npx skills add 会用仓库内容覆盖该 junction）。对于 Ane 的技能，克隆位于 ~/OneDrive/GitHub/personal-skills/skills/<name>/SKILL.md；第三方技能位于其各自的仓库中。
2. 应用 edit-preservation：限定修改范围，只增不改；更改范围之外的每一行都必须保持字节级一致。
3. 提交并推送该仓库（提交说明使用单引号 heredoc、采用 Conventional Commits 前缀，并按照 CLAUDE.md 添加 Co-Authored-By 页脚）。
4. 同步工作文件夹镜像（如果存在于 .claude/skills/<name>/SKILL.md）：将新内容复制到镜像中，并在工作文件夹仓库中提交，以免网页会话使用过时版本。
5. 正式生效。 所有技能（无论是否为核心技能）都不需要重新生成锁文件，也不需要在仓库内安装（2026-10-13 已改写：.agents/skills 存储目录已停用，运行环境不再读取它们；工作文件夹提交 432f2d82）。check_skill_repo_chain 现在会将每项第一方技能的在线 ~/.claude/skills/<name>/SKILL.md 与克隆进行比较；步骤 3 已提交并推送克隆后，如果在线副本滞后，会报告为通过并附带自我修复说明，下次 SessionStart 刷新时会使其生效。只有当本次会话稍后还会再次调用已编辑的技能时，才在会话中刷新：npx -y skills add gasserane/personal-skills --global --agent claude-code -y（SessionStart hook 使用的命令）。绝不要使用 --all —— 它会安装到所有已知 Agent，并重新创建已停用的 .agents/skills 存储目录。绝不要从仓库根目录执行项目模式安装 —— 经 2026-10-13 验证：不带 --global 的 --agent claude-code 会在当前目录写入 .claude/skills/ 副本和 skills-lock.json，导致克隆仓库出现未提交更改。
6. 更改将在下次会话开始时生效（--global 安装会拉取仓库）。请说明这一点。

确认。 如果更新了任何技能，请在报告末尾追加：

SKILL IMPROVEMENTS
  ✅ <skill> — <one-line change> (committed <sha>, live next session)

Loop 2 — 技能适配扫描（这项工作是否应该由技能完成？）

查看会话中工作的类型，将其归为三种结果之一，并为 Ane 提供对应的后续内容。除了可选的待办列表条目外，不写入任何内容。

触发条件。 会话中包含一项结构化的多步骤工作，并且 Ane 很可能会重复进行。一次性的定制工作、琐事、纯对话、调试或系统基础设施工作均跳过。首先，对照已安装的技能列表和项目 CLAUDE.md 中的路由路径（§ 技能路由）检查这项工作。然后准确归入以下一类：

• 已有覆盖 — 现有技能已经能完成这项工作，而 Ane 没有调用该技能，手动完成了工作。收益是她下次能节省时间。这是重要信号，而非附带信息：即使没有任何内容需要构建，也要指出。
• 新建 — 没有现有技能针对这项工作；Ane 临时处理、手动完成，或借助通用编排完成，而专用技能可以简化流程。
• 增强 — 现有技能适用于这项工作，但要在本次会话中完美完成，还需要改进：缺少一种模式、一种输出类型、一条逻辑分支，或存在迫使人手动返工的缺口。

倾向于不提出。 技能泛滥会带来真实成本——项目 CLAUDE.md 提醒要避免相互竞争的技能和术语表。只指出价值最高的一项；只有在第二项与第一项明显不同且同样重要时才指出第二项。如有疑问，就什么也不说。如果增强缺口很小，且 Ane 已在 Loop 1 中接受了行内修正，则不要在此重复提出——Loop 2 中的增强应当是她更愿意另开一个会话来规划的改进。

需要提供的内容。

• 对于已有覆盖：只提供指引——技能名称、触发短语，以及 Ane 下次应输入的那一行。不提供计划或提示词。到此为止。
• 对于新建和增强，提供以下全部内容：
  1. 信号：一行格式为 [NEW: <建议的技能名称> | ENHANCE: <现有技能>] — <会重复进行的工作> — <技能或改进为何优于手动完成>。对于增强，还要说明具体缺口：技能目前会做什么、本次会话中未能完成什么，以及怎样才算“完美适配”。
  2. 计划：3 到 6 步：范围和触发短语（新建），或确切的改动及其在技能文件中的位置（增强）；列出会与之组合或并行的现有技能或 Agent 名称，以证明它并非重复；构建路径（专注型技能或改动使用 skill-creator，较大型构建使用 superpowers:brainstorming → writing-plans → writing-skills）；克隆路径 ~/OneDrive/GitHub/personal-skills/skills/<name>/；以及收尾事项（运行 /test，提交并推送克隆副本，将工作文件夹镜像同步到 .claude/skills/<name>/，下次会话即可使用）。
  3. 开始提示词——一段可粘贴到新会话中的自包含提示词，并用代码围栏括起。提示词需说明技能名称及其唯一任务（新建）或唯一改进（增强），说明首先要调用的构建技能，提供克隆路径，明确说明它与最相近的现有技能有何不同，以免新会话重新构建或重复造轮子，并以“运行 /test，然后提交并推送两个位置”结束。

可选暂存（仅新建和增强）。 这是 Loop 2 中唯一一次写入，并且发生在 Phase 4 提交之后，因此必须自行提交，不能留下未提交的文件。只询问一次，默认否：Save this to the skill-ideas backlog? (y/n)。如果选择是：将信号、计划和开始提示词追加到 agent-improvements/skill-ideas-backlog.md（应用 edit-preservation；如果文件不存在，则以 # Skill ideas backlog 标题创建），然后暂存、提交并推送工作文件夹仓库中的这一个文件。不要留下未提交的更改。

确认。 只将适用的行追加到报告中：

SKILL OPPORTUNITY
  💡 ALREADY COVERED: /<skill> does this — trigger "<phrase>"; use it next time
  💡 NEW <proposed-name>: <one-line opportunity> — plan + start prompt below
  💡 ENHANCE <skill>: <gap in one line> — improvement + plan + start prompt below

对于新建和增强，在报告下方输出计划和开始提示词。

循环 3 — 交付后学习记录（供人学习，最后运行）

为 Ane 提供素材，而非系统。之所以最后运行，是因为知识库可能无法访问，而且这是最不关键的循环；跳过此循环或知识库无法访问，绝不能影响安全关键的提交，因为该提交已在阶段 4 完成。

触发条件。 本次会话产出了实质性成果（Ane 将使用或发送的分析、评估、知识、SRHR 或结构化输出），并且可访问位于 OBSIDIAN_VAULT_ROOT（C:/Users/AGasser/OneDrive/Ane Obsidian Vault）的 Obsidian 知识库。纯维护、调试或系统底层工作会话应跳过；在未配置该知识库的网页端／非设备端也应跳过。

接受后。 运行 journal-reflection 的 Post-deliverable capture 模式（回答三个问题：这项工作让你学到了什么；你会做哪些不同的事；有什么值得继续坚持），并按照该技能的 File-placement 规则，将答案追加到 5 JURNAL/Learning/deliverable-learning-log.md（持续记录、保留现有编辑内容；若文件不存在，则创建并添加 frontmatter）。不要代答提示词；原样记录她的回答。

确认。 如果已写入记录，请在报告中追加：

LEARNING CAPTURE
  ✅ Appended to 5 JURNAL/Learning/deliverable-learning-log.md

循环 4 — 记录实际 Token 成本（补上校准缺口）

将本次会话在 cost-calibration-log.md 中的记录从估算值更新为确定的实际值。Agent 无法读取自身的 Token 数量（Claude Code 不会向 Agent 暴露每次运行的 Token 数），因此唯一的记录方式是由 Ane 粘贴数据，而且必须在终端关闭前完成；否则，14 天后该记录将被标记为 not observed。

触发条件。 本次会话已在 agent-improvements/cost-calibration-log.md 中追加，或本应追加一行：复杂的 /ann 运行，或系统改进会话（/grade-system、/system-audit、wiki 扩展、专用 Agent 部署、harness 或 P1/P2 预算工作）。对话、趣闻、轻量编辑，以及没有校准记录的会话均应跳过。

记录位置。 日志的表格特意设为最后一节（于 2026-08-05 重新整理）：在文件末尾追加新行，便会自动落入表格。不要在叙述性章节上方插入记录。

每次收尾时都会重新触发，而非只触发一次。 会话中途粘贴的数据会在工作继续后立即过时。2026-07-29，记录先写入 210k，随后会话又因一次分支迁移、一次脚本修复和第二次收尾继续运行至 269k，因此日志低估了该次运行约四分之一，而且没有任何提示。若本次会话已有一行确定的实际值，切勿将此循环视为已完成：再次提出请求，说明已记录的数值以及之后完成的工作；若接受，则就地覆盖该行的 Actual 和 Variance。切勿为同一次运行追加第二行。终端关闭前最后一次粘贴的数值才是真实值。

日期为今天的记录不一定属于本次会话。 Ane 会并行运行多个会话，每个会话各自收尾，因此同一天的记录可能完全属于另一段工作。更新任何记录前，请先阅读其 Notes 单元格，确认其中描述的是本次会话实际完成的工作。2026-07-31，某个并行会话为一段较短的尾续会话追加了一行，其备注说明该记录只涵盖 /clear 之后的尾续部分；若用本次会话大得多的数值覆盖，就会抹掉一项真实测量，并错误描述另一项。判断依据是工作片段，而不是日期。 同一片段：就地更新。不同片段：追加新行，并在两行的 Notes 单元格中都注明它们来自并行会话。无法判断时，先询问 Ane，不要猜测——事实可靠性规则同样适用于成本数据。 接受时。 请 Ane 粘贴 /cost 区块（已使用的上下文令牌、$ 成本、缓存百分比、耗时）。然后：

1. 找出本次会话新增的成本校准行，按任务 slug 和今天的日期匹配。同一会话中较早的收尾已记录确切实际值的行应更新，而不是重复添加。
2. 只有一行： 将粘贴的数值写入该行的 Actual，然后根据 Estimated band 计算 Variance（实际值 ≥ 上限的 1.5 倍时标记 ⚠️ over-band）。使用 Edit 原地更新该行（应用 edit-preservation；只修改该行）。
3. 多于一行： /cost 总计是整个会话的总和，不是每项任务的费用。请 Ane 粗略拆分。如果她给出拆分，就分别写入各行。如果没有，则将总计记在范围最大的那一行，并在其他行标注 [shared session total — see <slug>]，绝不要捏造每行的数值（事实可靠性规则）。
4. 如果文件维护方差摘要计数，则更新日志中的计数（总行数、确切观测值数量、超出区间数量）。
5. 在工作文件夹仓库中暂存、提交并推送这个文件。它会在 Phase 4 提交之后落地，因此单独提交（使用单引号 heredoc 提交消息、常规前缀，并按 CLAUDE.md 添加 Co-Authored-By 页脚）。

归因说明（测量于 2026-08-04）。 /cost 面板会在 /clear 后重置（在一个终端中观察到：/clear 后，下一个线程的总计从零重新开始）。因此，粘贴的数值仅涵盖当前线程，即自上次 /clear 或终端启动以来的费用。

跳过时。 将各行保留为 [pending — Ane: paste from terminal]；14 天规则会在下一次 Li CURATE 时将其转为 not observed。

确认。 如果写入了实际值，请在报告中追加：

COST ACTUAL
  ✅ <task-slug> — actual <Nk> vs est <band> (<variance>); committed <sha>

Phase 6 — 后续交接（自动）

编写用于启动下一次会话的提示词。最后运行此阶段，因为其中必须描述最终状态，包括 Phase 4 提交的内容以及 Phase 5 循环中仍未完成的事项。

存在的原因。 新会话会加载 Ane 的常驻文件和记忆索引，但没有任何对话内容。remember:remember 会记录发生情况的日志，并在 SessionStart 时注入为背景上下文；但它不会生成用于指定新会话任务的指令。因此，拆分长会话一直意味着手动重建上下文，这也是 ~/.claude/CLAUDE.md 第 8 项范围门槛一直未能通过的部分原因：该门槛要求 Ane 拆分会话，而拆分成本很高。现在拆分的成本很低。

触发条件 — 自动执行，不要询问。 符合以下任一条件时运行：

• Phase 2 检查 4 发现仍未完成的已命名工作流——一项有名称、有下一步，并且有对应文件的工作。零散待办、将来或许会做的事，以及“我应该看看这个”都不符合条件。
• Ane 调用了 /wrap-up continue。

会话已完成时保持静默。描述已完成工作的交接会造成过时指令风险，下一次会话可能会据此采取行动。

如果下一次会话要进行 BUILD，就编写规格说明，而不是状态说明。 描述状态的交接会让下一次会话还得自行探索。明确指定构建内容的交接则能免去这一过程。证据：有一次技能构建的费用约为同一周两个可比构建的三分之一；唯一明确的差异是，前一次会话编写了完整、可直接粘贴的规格说明并完成交接，而不是就地构建。因此，当未完成的工作流是一个形态已明确的构建任务时，交接应列出要读取的文件、每个文件中的确切更改、验收测试和收尾步骤。然后在报告中告诉 Ane 执行 /clear 并粘贴交接内容，而不是在此继续。高上下文下进行构建的成本约为三倍。

存储 — 每个工作流一个文件。 写入 agent-improvements/handoffs/<workstream-slug>.md。如果目录不存在，就创建它。 不是每个会话一个文件，也不是覆盖同一个文件。Ane 会并行运行多个会话（本地加网页端，或两个终端）。共用一个文件意味着后结束的会话会悄无声息地毁掉先结束会话的交接内容——没有任何警告；这是最糟糕的一类丢失。

Slug 稳定性。 写入前，先列出 handoffs/ 中已有的文件，并复用匹配的 slug，而不是另起一个相近的名称（例如，在 prompt-routing.md 旁边新建 routing-layer.md）。继续进行中的工作必须覆盖自己的交接文件，而不是不断积累近似重复的文件。

同一工作流的竞态保护。 如果目标文件已存在，且其修改时间晚于本会话的开始时间，说明另一个会话已先写入。不要覆盖。改为写入 <slug>-2.md（.remember/ 归档轮换已采用的 -2 约定），并标记：

⚠️  handoffs/<slug>.md was updated by another session at <time>.
    Yours written to <slug>-2.md — reconcile before continuing.

内容。 填写本会话涉及的所有章节。只有在某章节确实没有内容时，才省略该章节。

## NEXT SESSION — paste this to continue


Workstream: <name>. Status: <one line>.

Where it stands
  Done      : <what shipped, with commit sha>
  In flight : <the half-built thing, and which file holds it>
  Not started: <the rest>

Decisions already locked — do not reopen
  1. <decision> — because <reason> — recorded in <file or file#section>

Files, and how to treat them
  <path> — Ane hand-edited. Edit in place, never regenerate.
  <path> — generated by <script>. Safe to rerun.

Next step
  <one concrete action>

Open questions for Ane — ask before building
  1. <question>

Not yet specified — coming, but not yet sharp enough to ticket or ask
  1. <the suspected question or area, as loosely as the view allows>

Start in: <mode>. Lane: <Claude directly | /ann | /skill-name>.

决策章节最有价值。 Ane 的会话效率协议将重新推导已定决策列为主要浪费之一；新会话默认会重新推导，因为它看不到之前的对话。明确写出每项已敲定的决策及其理由：没有理由的决策，一旦看起来不方便，就会立刻遭到重新讨论。recorded in 指针要注明决策实际存放的位置（路线图文件、决策日志、wiki 章节），这样下个会话就能直接查看一手来源，而不必相信这份摘要——交接摘要从结构上说必然有损（2026-08-05 采纳，wayfinder 扫描）。

例外——有 wayfinder 地图的工作流：只指向地图，绝不重述。 如果决策已记录在 wayfinder 地图的工单中（.scratch/<effort>/map.md 加上 issues/*.md），就将整个 Decisions already locked 章节替换为一行：Decisions live in <map path> (Decisions so far) and its tickets; not restated here. 地图是索引，每张工单的 ## Answer 是唯一记录，因此交接中列出相同决策，就会形成措辞不同的第二份记录。证据（2026-10-04，wayfinder 试点结论，agent-improvements/wayfinder-pilot-verdict-2026-10-04.md § 3）：决策可追溯性测试在 4 项中有 2 项未通过。两项失败都是 /wrap-up 交接重述了地图决策，而仅记录在 wayfinder 中的每项决策都能顺利追溯。

描述外部实时状态的状态行，必须重新核查，不能沿用。 如果交接的状态声称了只有外部世界才能确认的信息——例如发布的是哪个版本、个人资料上显示哪个横幅、远程服务提供什么内容、部署了什么——不要将先前的状态原样复制到更新后的交接中。打开记录该状态的权威文件并核实。沿用旧状态，会把过时说法包装成新信息，因为更新日期让人以为整行都经过核查，但实际上只看了文件的修改时间。证据（2026-09-11）：一份写于 2026-08-05 的交接将某个已发布资源的版本标为当前版本；之后又发布了三个更新版本；2026-09-08 的待办清理更新了状态行，却没有打开权威文件，而该文件早在 2026-08-18 就记录了更新的当前版本。五周后，会话相信了这份交接，导致来回核实，还尝试读取实时页面但失败（该网站对未认证的抓取请求返回 HTTP 999）。最省事的核查方法，是对每项外部声明在权威文件中执行一次 grep；这比交接内容出错的代价低。

用名称引用，绝不只写 id。 每一行供人阅读的内容中，文件、工单或决策都要写出名称（wayfinder scan，agent-improvements/wayfinder-scan-2026-08-05.md），绝不只写一个数字，也不要写缺少上下文的“昨天那个文件”。名称一目了然；id 则需要额外查找（2026-08-05 采纳，wayfinder 扫描）。 “尚未明确”仍在试行中（新增于 2026-08-05；是否保留尚待决定——参见 agent-improvements/wayfinder-scan-2026-08-05.md）。它用于记录迷雾：会话能够预见、但还无法准确表述的问题。它不同于“给 Ane 的开放问题”，后者记录等待她回答的明确问题。没有迷雾时，省略此部分；如果它在多次交接中持续单调增长，那就是扫描中指出的警示信号。

**带日期的 HTML 注释至关重要。**后续会话要靠它检测内容是否过时。请保留。

**脱敏——与任何连续性记录遵循相同规则。**绝不以可识别的方式引用或转述任何 5 JURNAL 日志内容。绝不在交接记录中写入 SOGIESC、GBV 或 SRH 服务对象的身份信息。提及敏感材料时只引用路径，不描述内容。

**退役——运行扫描，不要依赖记忆。**如果仓库中存在 python scripts/handoff_status.py，请运行。它会从目录中实时读取数据，并打印每份交接记录的存续时间、状态和过时标记。即使你认为自己知道其中有什么，也不要跳过。

之所以将此步骤编写为脚本，原因与 cap_status_hook.py 的存在相同。“工作流结束时删除交接记录”这类指令依赖模型记住，而正是这种失误导致项目 8 的范围关卡两次失守。此外，它也会漏掉被放弃的工作流：它们永远不会结束，因此也永远不会触发删除。只有扫描才能发现这些情况。 通过两种方式处理输出：

1. 本次会话已完成。 如果本次会话结束了一个有交接文件的工作流，请删除该文件（git rm）并报告。已完成工作的交接文件会带来过时指令风险。例外——如果文件记录了其他地方没有的决策，就保留它。 删除前，检查文件是否有 Decisions already locked 部分，其中的条目是否没有指向交接文件以外位置的 recorded in 指针。如果有，删除就会摧毁已敲定决策背后的推理。这是 Ane 自己的会话效率协议中最浪费时间的情况：没有理由的决策，一旦看起来不方便，就会被重新争论。保留文件并将其解除指令效力，这需要三处修改：在状态行中加上 CLOSED <date>，在其下添加一行说明该文件是记录而非指令，并删除 Next step 下的每个条目。该标记只能放在 Workstream: ... Status: 行中，不能放在其他地方。 handoff_status.py 只从这一行读取关闭状态，不会查看标题；因此，即使标题写着 ## DONE 或 ## CLOSED，文件仍会被报告为未关闭，并在每次扫描时继续触发过时提示。证据（2026-09-08，交接文件积压清理）：有个交接文件标题写着 ## DONE - <date>. Kept for the decision record; nothing here is outstanding.，但在第 32 天时仍被列为 OPEN，因为文件中第一条 Workstream: ... Status: 行位于保留的原始交接内容下方，仍写着 fully specified, not started。如果文件原样保留了原始交接内容，应在其上方添加一条新的 Workstream: ... Status: CLOSED <date> 行，而不是修改历史记录：扫描会采用第一个匹配项，这样既能保留历史，也能让扫描结果反映真实状态。这既消除了删除规则旨在防止的过时指令风险，也保留了只有该文件才知道的信息。报告为 kept — carries N locked decisions，而不是报告为已删除。证据（2026-08-15，连续两次会话）：system-audit-follow-ups.md 关闭时保留了 16 条已敲定决策，wiki-routing-and-lint-followups.md 保留了 5 条；两次会话都基于相同理由覆盖了删除规则。一次覆盖被重复两次却没有记录下来，第三次会话就会忘记。
2. 标记为过时（7 天或更久，且无活动）。 不要删除。向 Ane 显示该行并询问一次：close it? (y/n)。回答 yes 时，用 git rm 删除。回答 no 或未回答时，保留并继续处理。状态以 CLOSED 开头的交接文件不属于过时文件，不会触发此提示——handoff_status.py 会将其列入 CLOSED — kept as a record, no action。分类器推出前，这两个已关闭文件都在未关闭列表中，系统还会询问是否关闭已经关闭的内容。这种提示最容易让读者不看内容就直接作答。

关闭时更新日期，否则扫描无法识别。 handoff_status.py 根据交接文件中第一条 written by /wrap-up on <date> 注释计算文件时长，而不是根据修改时间，因为 OneDrive 和 git 都会在文件内容未变时重写修改时间。因此，只修改正文的关闭操作会让文件继续显示原始时长：2026-08-15，有个当天下午关闭的交接文件仍显示 12 days ⚠️ no activity。每次修改交接文件时，都要将该注释更新为今天的日期，并在注释正文中保留原始创建日期。

绝不要根据文件时长自动删除。 这是 Ane 在 2026-07-30 作出的决定。时长规则无法区分已放弃的工作流和正在等待合作方的工作流，而她的几个实际工作流确实会间隔数周。误删文件会丢失无法重建的上下文，而无声丢失正是这个系统已经付出过两次代价的故障类型。

列表每次运行时都会根据目录生成，绝不会存储为索引文件。这个系统曾两次遭遇索引与实际情况不符的问题——固定的测试框架计数两次都在几小时内过时了——而直接从目录读取的列表不会出现偏差。 提交。 这会在 Phase 4 提交之后落地，因此它会提交自身，方式与 Loop 2 暂存和 Loop 4 成本行相同。暂存交接文件（以及任何删除），提交并推送，提交说明使用单引号 heredoc，并遵循 CLAUDE.md 中的约定前缀。

确认。 在报告下方以围栏代码块打印交接内容，以便 Ane 无需打开文件即可复制，然后追加：

CONTINUATION HANDOFF
  ✅ handoffs/<slug>.md written (committed <sha>) — next session: "continue from the handoff"
  🗑  handoffs/<finished-slug>.md removed — workstream closed

恢复。 当 Ane 开启会话并说“从交接内容继续”或类似的话时：如果只有一个打开的文件，就读取并继续。如果有多个，就显示列表并询问要选哪一个。如果文件超过 7 天，请在据此采取行动前说明这一点，因为其中的决策可能已经变化。