⚡

会话上下文总结Skill ctx-wrap-up

会话上下文总结技能是一个用于软件开发协作流程的仪式性工具，旨在高效捕获和持久化项目会话中的关键信息。其主要功能包括：自动扫描Git变更记录和对话历史，智能识别并分类有价值的学习成果、技术决策、团队约定和待办任务，通过结构化命令将信息保存到项目上下文库中。该技能是知识管理、团队协作、DevOps流程和敏捷开发的重要辅助工具，帮助团队积累项目知识、避免重复错误、保持决策透明，并确保工作连续性。

DevOps 0 次安装 0 次浏览 更新于 2/27/2026

name: ctx-wrap-up description: “会话结束时的上下文持久化仪式。在结束会话时使用，用于捕获学习成果、决策、约定和任务。” allowed-tools: Bash(ctx:), Bash(git diff:), Bash(git log:*), Bash(git status), Read

指导会话结束时的上下文持久化。从会话中收集信号，提出值得持久化的候选项，并通过 ctx add 命令持久化已批准的项。

这是一个仪式性技能——在会话结束时明确调用 /ctx-wrap-up，而不是在对话中调用。它与会话开始时使用的 /ctx-remember 配对使用。

开始前

检查 .context/ 目录是否存在。如果不存在，请告知用户： “未找到上下文目录。请运行 ctx init 来设置上下文跟踪，然后才有内容可以总结。”

使用时机

  • 在会话结束时，用户退出之前
  • 当用户说“让我们总结一下”、“保存上下文”、“会话结束”时
  • 当 check-persistence 钩子建议时

不应使用的时机

  • 没有发生有意义的事情（仅读取文件、快速查找）
  • 用户已使用 ctx add 手动持久化了所有内容
  • 会话中途，用户仍在流程中——此时应使用 /ctx-reflect 进行中途检查点

流程

第一阶段：收集信号

静默执行此操作——不要叙述步骤：

  1. 检查工作树中的更改：
    git diff --stat
  2. 检查本次会话中提交的提交：
    git log --oneline @{upstream}..HEAD 2>/dev/null || git log --oneline -5
  3. 扫描对话历史记录，查找：
    • 讨论的架构选择或设计权衡
    • 遇到的陷阱、错误或意外行为
    • 建立或约定的模式或惯例
    • 已识别但尚未开始的后续工作
    • 已完成或取得进展的任务

第二阶段：提出候选项

逐步思考哪些内容值得持久化。对于每个潜在的候选项，问自己：

  • 这是项目特定的还是一般知识？（仅持久化项目特定的见解）
  • 未来的会话是否会从了解此信息中受益？
  • 此信息是否已捕获在上下文文件中？
  • 此信息是否足够重要值得记录，还是微不足道？

以结构化列表呈现候选项，按类型分组。 跳过没有候选项的类别——不要显示空的部分。

## 会话总结

### 学习成果（N 个候选项）
1. **学习成果标题**
   - 背景：是什么促成了这一点
   - 经验教训：关键见解
   - 应用：如何向前应用

### 决策（N 个候选项）
1. **决策标题**
   - 背景：是什么促成了这一点
   - 理由：为什么做出这个选择
   - 后果：因此产生了什么变化

### 约定（N 个候选项）
1. **约定描述**

### 任务（N 个候选项）
1. **任务描述**（新 | 已完成 | 已更新）

持久化所有？还是选择要保留的项？

第三阶段：持久化已批准的候选项

等待用户批准、选择或修改候选项。 未经明确批准，切勿持久化任何内容。

对于每个已批准的候选项，运行相应的命令：

类型 命令
学习成果 ctx add learning "标题" --context "..." --lesson "..." --application "..."
决策 ctx add decision "标题" --context "..." --rationale "..." --consequences "..."
约定 ctx add convention "描述"
任务（新） ctx add task "描述"
任务（完成） 编辑 .context/TASKS.md 以标记为完成

报告每个命令的结果。如果任何命令失败，报告错误并继续处理剩余项。

第四阶段：提交（可选）

持久化后，检查是否有未提交的更改：

git status --short

如果有未提交的更改，提供以下选项：

存在未提交的更改。您希望我运行 /ctx-commit 来提交并捕获上下文吗？

不要自动提交。由用户决定。

候选项质量指南

好的候选项

  • “PyMdownx details 扩展将内容包装在 <details> 标签中，破坏了 MkDocs 中的 <pre><code> 渲染”——特定的陷阱，对未来会话具有可操作性
  • “决策：使用基于文件的冷却令牌而不是环境变量，因为钩子在子进程中运行”——具有理由的真实权衡
  • “约定：所有技能描述都使用祈使语气”——为了一致性而编纂的模式

弱的候选项（不要提出）

  • “Go 有良好的错误处理”——一般知识，非项目特定
  • “我们编辑了 main.go”——从差异中显而易见，不是见解
  • “提交前测试应该通过”——过于通用，没有用处
  • 任何已存在于 LEARNINGS.md 或 DECISIONS.md 中的内容

与 /ctx-reflect 的关系

/ctx-reflect 用于在自然断点处进行中途检查点。/ctx-wrap-up 用于会话结束——它更彻底，涵盖整个会话过程，并包括提交提议。如果用户最近已经运行过 /ctx-reflect，请避免再次提出相同的候选项。

质量检查清单

在呈现候选项之前，请验证：

  • [ ] 已收集信号（git diff, git log, 对话扫描）
  • [ ] 每个候选项都有完整的字段（不仅仅是标题）
  • [ ] 候选项是项目特定的，不是一般知识
  • [ ] 与现有上下文文件没有重复
  • [ ] 空类别被省略，不显示为“（无）”
  • [ ] 在持久化任何内容之前询问用户

持久化之后，请验证：

  • [ ] 每个 ctx add 命令都成功执行
  • [ ] 未提交的更改已浮出水面（如果有）
  • [ ] 已向用户提供 /ctx-commit 选项（如果适用）