name: specstory-session-summary description: 以站立会议格式总结最近的SpecStory AI编码会话。当用户想要从.specstory/history查看会话、准备站立会议、跟踪工作进度或了解完成内容时使用。 license: MIT metadata: author: SpecStory version: “1.0”

上下文

你将分析最近的SpecStory会话历史文件以提供站立会议风格的摘要。

提供的参数：$ARGUMENTS（默认：5个会话，或“today”仅用于今天的会话）

你的任务

步骤1：查找最近会话

首先，检查SpecStory历史文件夹是否存在，并列出最近的会话文件：

ls -t .specstory/history/*.md 2>/dev/null | head -20

如果不存在.specstory/history文件夹或为空，响应：

在此目录中未找到SpecStory会话历史。

SpecStory自动保存你的AI编码会话以供后续参考。要开始录制会话，请从https://specstory.com安装SpecStory。

然后停止 - 不要继续其余步骤。

如果找到会话，继续分析。如果参数是“today”，过滤到今天的日期。否则使用提供的数字（默认5）。

步骤2：读取和分析每个会话

会话文件可能非常大，可能包含多个用户请求。使用以下分块阅读策略：

步骤2a：理解会话结构

首先，grep所有用户消息标记以查看会话范围：

grep -n "_**User**_" <file> | head -10

这显示用户消息的行号，帮助你理解：

发出了多少个不同的请求
在哪里阅读每个请求的上下文

步骤2b：根据结构进行战略性阅读

开头（前500行） - 用offset=0, limit=500阅读
- 捕获初始请求，即使它包括粘贴的代码/日志
- 可能包括早期助手响应显示采取的方法
结尾（最后300行） - 使用tail -300 <file> via Bash
- 包含最终结果和结论
- 显示任务是否完成或待处理
文件操作 - Grep修改：
```
grep -E "(Edit|Write)\(" <file>
```

步骤2c：对于多请求会话

如果在2a中的grep显示多个用户消息在遥远的行号（例如，行50, 800, 1500），这表明多个不同的任务。对于这些会话：

围绕每个用户消息行号阅读（例如，offset=795, limit=100）
总结2-3个主要任务，而不是仅第一个

提取此信息：

目标：来自_**User**_块的用户请求
- 对于单任务会话：一个主要目标
- 对于多任务会话：列出2-3个主要任务
结果：从对话结尾确定：
- ✅ 完成 - 任务成功完成
- 📚 研究 - 信息收集，无代码更改
- 🔧 进行中 - 工作开始但会话中途结束
- ❌ 放弃 - 用户改变方向或放弃
- 🚧 阻塞 - 以未解决错误或阻塞结束
文件：从编辑/写入工具使用的修改文件（仅提取文件名）
关键决策：在对话中查找：
- 明确选择（“决定”、“选择”、“而不是”）
- 权衡讨论
- 架构或设计结论

步骤3：格式化输出

呈现每个会话为：

### {YYYY-MM-DD HH:MM} - {从主要目标中提取的简短标题}
**目标**：{1句话总结用户想要什么}
**结果**：{emoji} {简短结果描述}
**文件**：{逗号分隔的列表，或如果仅研究则为“无”}
**关键洞察**：{如果有任何显著决策或学习}

对于多任务会话，调整格式：

### {YYYY-MM-DD HH:MM} - {整体主题或主要任务}
**任务**：
  1. {第一个任务} - {结果emoji}
  2. {第二个任务} - {结果emoji}
**文件**：{逗号分隔的列表}
**关键洞察**：{如果有任何显著决策或学习}

步骤4：摘要部分

在所有会话后添加：

---
**模式**：{注意任何重复的主题、多次触及的文件、进行中的工作}
**未完成**：{任何以TODO、阻塞或未完成工作结束的会话}

指南

保持每个会话摘要最多5-6行（多任务会话稍多）
从用户目标推断标题，而不是文件名
对于文件，更喜欢仅显示文件名，而不是完整路径
跳过仅是快速问题且无实际工作的会话
对于多任务会话，总结最多3个主要任务；将次要任务分组为“各种小修复”
简洁 - 用于快速日常回顾，而非详细文档
如果文件读取失败或太大，使用可以提取的内容；不要完全跳过会话

示例输出

## 会话摘要（最近3个会话）

### 2025-10-18 11:42 - 调查聊天CRDT存储
**目标**：理解为什么聊天索引CRDT不包含线程
**结果**：📚 解释了离线/在线同步的双存储设计
**文件**：threads.json, crdt-debug/4X/, crdt-debug/aT/
**关键洞察**：两个存储层（CRDT + JSON）服务不同的同步场景

### 2025-10-18 11:09 - 解决代码审查评论
**目标**：修复代码审查中的清晰问题
**结果**：✅ 重构了normalizeChatIndexDoc函数
**文件**：chat.go, automerge-bridge.js
**关键洞察**：用toPlainString助手替换了复杂的归一化

### 2025-10-11 14:30 - Automerge架构深度探讨
**目标**：记录Automerge文档是如何临时构建的
**结果**：📚 研究完成，提供了逐步说明
**文件**：automerge-bridge.js, document.go（只读）

---
**模式**：3个会话专注于CRDT/聊天子系统；automerge-bridge.js反复触及
**未完成**：未检测到