Back to Details

specstory-session-summary

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Context

背景

You will analyze recent SpecStory session history files to provide a standup-style summary.
Argument provided: 
$ARGUMENTS
(default: 5 sessions, or "today" for today's sessions only)
你将分析近期SpecStory会话历史文件，以站会风格提供总结。
提供的参数：
$ARGUMENTS
（默认：5个会话，或传入"today"仅查看今日会话）

Your Task

你的任务

Step 1: Find Recent Sessions

步骤1：查找近期会话

First, check if the SpecStory history folder exists and list recent session files:
zsh
ls -t .specstory/history/*.md 2>/dev/null | head -20
If no 
.specstory/history
folder exists or it's empty, respond with:
No SpecStory session history found in this directory.
SpecStory automatically saves your AI coding sessions for later reference. To start recording your sessions, install SpecStory from https://specstory.com
Then stop - do not proceed with the remaining steps.
If sessions are found, continue with the analysis. If the argument is "today", filter to today's date. Otherwise use the number provided (default 5).
首先，检查SpecStory历史文件夹是否存在，并列出近期会话文件：
zsh
ls -t .specstory/history/*.md 2>/dev/null | head -20
如果不存在.specstory/history文件夹或文件夹为空，请回复：
此目录下未找到SpecStory会话历史。
SpecStory会自动保存你的AI编码会话，供后续查阅。如需开始记录会话，请从https://specstory.com安装SpecStory
之后停止操作——无需执行后续步骤。
如果找到会话，继续进行分析。若参数为"today"，则筛选出今日的会话；否则使用提供的数字（默认5个）。

Step 2: Read and Analyze Each Session

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

Session files can be very large and may contain multiple user requests. Use this chunked reading strategy:
Step 2a: Understand the session structure
First, grep for all user message markers to see the session's scope:
grep -n "_\*\*User\*\*_" <file> | head -10
This shows line numbers of user messages, helping you understand:
  • How many distinct requests were made
  • Where to read for each request's context
Step 2b: Read strategically based on structure
  1. Beginning (first 500 lines) - Read with 
    offset=0, limit=500
    • Captures the initial request even if it includes pasted code/logs
    • May include early assistant responses showing the approach taken
  2. End (last 300 lines) - Use 
    tail -300 <file>
    via Bash
    • Contains the final outcome and conclusion
    • Shows whether tasks were completed or left pending
  3. File operations - Grep for modifications:
    grep -E "(Edit|Write)\(" <file>
Step 2c: For multi-request sessions
If the grep in 2a shows multiple user messages at distant line numbers (e.g., lines 50, 800, 1500), this indicates multiple distinct tasks. For these sessions:
  • Read around each user message line number (e.g., 
    offset=795, limit=100
    )
  • Summarize the 2-3 main tasks rather than just the first one
Extract this information:
  1. Goal(s): The user's request(s) from 
    _**User**_
    blocks
    • For single-task sessions: one main goal
    • For multi-task sessions: list the 2-3 primary tasks
  2. Outcome: Determine from the end of the conversation:
    • ✅ Completed - task was finished successfully
    • 📚 Research - information gathering, no code changes
    • 🔧 In Progress - work started but session ended mid-task
    • ❌ Abandoned - user changed direction or gave up
    • 🚧 Blocked - ended with unresolved error or blocker
  3. Files: Modified files from Edit/Write tool uses (extract filenames only)
  4. Key decisions: Look in the conversation for:
    • Explicit choices ("decided to", "chose", "instead of")
    • Trade-off discussions
    • Architecture or design conclusions
会话文件可能非常大，且可能包含多个用户请求。请使用以下分块读取策略：
步骤2a：理解会话结构
首先，使用grep查找所有用户消息标记，以了解会话范围：
grep -n "_**User**_" <file> | head -10
这会显示用户消息的行号，帮助你了解：
  • 提出了多少个不同的请求
  • 每个请求的上下文位置
步骤2b：根据结构策略性读取
  1. 开头（前500行） - 使用
    offset=0, limit=500
    读取
    • 捕获初始请求，即使其中包含粘贴的代码/日志
    • 可能包含助手的早期回复，展示所采用的方法
  2. 结尾（最后300行） - 通过Bash使用
    tail -300 <file>
    • 包含最终结果和结论
    • 显示任务是否完成或中途终止
  3. 文件操作 - 查找修改记录：
    grep -E "(Edit|Write)\(" <file>
步骤2c：多请求会话处理
如果步骤2a中的grep结果显示多个用户消息位于相差较大的行号（例如：第50行、第800行、第1500行），则表明会话包含多个独立任务。对于此类会话：
  • 读取每个用户消息行号附近的内容（例如：
    offset=795, limit=100
    ）
  • 总结2-3个主要任务，而非仅第一个任务
提取以下信息：
  1. 目标：来自
    _**User**_
    块的用户请求
    • 单任务会话：一个主要目标
    • 多任务会话：列出2-3个主要任务
  2. 结果：从对话结尾判断：
    • ✅ 已完成 - 任务成功完成
    • 📚 调研 - 仅收集信息，无代码变更
    • 🔧 进行中 - 已开始工作但会话中途结束
    • ❌ 已放弃 - 用户改变方向或终止任务
    • 🚧 受阻 - 因未解决的错误或障碍而结束
  3. 文件：通过Edit/Write工具修改的文件（仅提取文件名）
  4. 关键决策：在对话中查找：
    • 明确的选择（“决定”、“选择”、“而非”）
    • 权衡讨论
    • 架构或设计结论

Step 3: Format Output

步骤3：格式化输出

Present each session as:
undefined
每个会话按以下格式呈现：
undefined

{YYYY-MM-DD HH:MM} - {Brief Title from Main Goal}

{YYYY-MM-DD HH:MM} - {来自主要目标的简短标题}

Goal: {1 sentence summarizing what user wanted} Outcome: {emoji} {Brief result description} Files: {comma-separated list, or "None" if research only} Key insight: {Notable decision or learning, if any}

For multi-task sessions, adjust the format:
目标：{一句话总结用户需求} 结果：{emoji} {简短结果描述} 文件：{逗号分隔的列表，若仅为调研则填“无”} 关键见解：{若有，记录重要决策或收获}

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

{YYYY-MM-DD HH:MM} - {Overall Theme or Primary Task}

{YYYY-MM-DD HH:MM} - {整体主题或主要任务}

Tasks:
  1. {First task} - {outcome emoji}
  2. {Second task} - {outcome emoji} Files: {comma-separated list} Key insight: {Notable decision or learning, if any}
undefined
任务:
  1. {第一个任务} - {结果emoji}
  2. {第二个任务} - {结果emoji} 文件：{逗号分隔的列表} 关键见解：{若有，记录重要决策或收获}
undefined

Step 4: Summary Section

步骤4：总结部分

After all sessions, add:
---
**Patterns**: {Note any recurring themes, files touched multiple times, ongoing work}
**Unfinished**: {Any sessions that ended with TODOs, blockers, or incomplete work}
在所有会话之后，添加：
---
**模式**：{记录任何重复出现的主题、多次涉及的文件、正在进行的工作}
**未完成项**：{任何以待办事项、障碍或未完成工作结束的会话}

Guidelines

指南

  • Keep each session summary to 5-6 lines maximum (slightly more for multi-task sessions)
  • Infer the title from the user's goal, not the filename
  • For files, prefer showing just the filename, not full paths
  • Skip sessions that are just quick questions with no real work
  • For multi-task sessions, summarize up to 3 main tasks; group minor tasks as "various small fixes"
  • Be concise - this is for quick daily review, not detailed documentation
  • If a file read fails or is too large, work with what you can extract; don't skip the session entirely
  • 每个会话总结最多5-6行（多任务会话可略多）
  • 从用户目标推断标题，而非使用文件名
  • 文件仅显示文件名，不显示完整路径
  • 跳过仅包含快速问题、无实际工作的会话
  • 多任务会话最多总结3个主要任务；次要任务归为“多项小修复”
  • 保持简洁——此总结用于快速每日回顾，而非详细文档
  • 若文件读取失败或过大，尽可能提取可用信息；不要完全跳过该会话

Example Output

示例输出

undefined
undefined

Session Summary (Last 3 Sessions)

会话总结（最近3个会话）

2025-10-18 11:42 - Investigate Chat CRDT Storage

2025-10-18 11:42 - 调研Chat CRDT存储

Goal: Understand why chat index CRDT doesn't contain the thread Outcome: 📚 Explained dual storage design for offline/online sync Files: threads.json, crdt-debug/4X/, crdt-debug/aT/ Key insight: Two storage layers (CRDT + JSON) serve different sync scenarios
目标：了解为何聊天索引CRDT不包含线程 结果：📚 解释了用于离线/在线同步的双重存储设计 文件：threads.json, crdt-debug/4X/, crdt-debug/aT/ 关键见解：两层存储（CRDT + JSON）服务于不同的同步场景

2025-10-18 11:09 - Address Code Review Comments

2025-10-18 11:09 - 处理代码评审意见

Goal: Fix clarity issues from code review Outcome: ✅ Refactored normalizeChatIndexDoc function Files: chat.go, automerge-bridge.js Key insight: Replaced complex normalization with toPlainString helper
目标：修复代码评审中指出的清晰度问题 结果：✅ 重构了normalizeChatIndexDoc函数 文件：chat.go, automerge-bridge.js 关键见解：使用toPlainString助手替换了复杂的归一化逻辑

2025-10-11 14:30 - Automerge Architecture Deep Dive

2025-10-11 14:30 - Automerge架构深入分析

Goal: Document how Automerge docs are constructed temporally Outcome: 📚 Research complete, walkthrough provided Files: automerge-bridge.js, document.go (read only)
Patterns: 3 sessions focused on CRDT/chat subsystem; automerge-bridge.js touched repeatedly Unfinished: None detected
undefined
目标：记录Automerge文档的时间构造方式 结果：📚 调研完成，提供了 walkthrough 说明 文件：automerge-bridge.js, document.go（仅读取）
模式：3个会话聚焦于CRDT/聊天子系统；automerge-bridge.js被多次涉及 未完成项：未检测到
undefined