AGENT SKILL

specstory-session-summary

Summarize recent SpecStory AI coding sessions in standup format. Use when the user wants to review sessions from .specstory/history, prepare for standups, track work progress, or understand what was accomplished.

License 许可
MIT
最近更新
2026-05-06
Stars
★ 14
Forks
1

01 前言 Front Matter

name
specstory-session-summary
license
MIT
metadata
{ "author": "SpecStory", "version": "1.0" }
triggers
[ "command:session-summary", "user-asks-about-sessions" ]
description
Summarize recent SpecStory AI coding sessions in standup format. Use when the user wants to review sessions from .specstory/history, prepare for standups, track work progress, or understand what was accomplished.
organ_affinity
[ "organ-iv" ]
governance_phases
[ "prove" ]

02 资源文件 3

03 SKILL.md 正文

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)

Your Task

Step 1: Find Recent Sessions

First, check if the SpecStory history folder exists and list recent session files:

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).

Step 2: Read and Analyze Each Session

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

Step 3: Format Output

Present each session as:

### {YYYY-MM-DD HH:MM} - {Brief Title from Main Goal}
**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:

### {YYYY-MM-DD HH:MM} - {Overall Theme or Primary Task}
**Tasks**:
  1. {First task} - {outcome emoji}
  2. {Second task} - {outcome emoji}
**Files**: {comma-separated list}
**Key insight**: {Notable decision or learning, if any}

Step 4: Summary Section

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

Example Output

## Session Summary (Last 3 Sessions)

### 2025-10-18 11:42 - Investigate Chat CRDT Storage
**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

### 2025-10-18 11:09 - Address Code Review Comments
**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

### 2025-10-11 14:30 - Automerge Architecture Deep Dive
**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

04 同仓库更多 Skills

luokai0
luokai0/ai-agent-skills-by-luo-kai

write-contracts

Generates secure Aptos Move V2 smart contracts with Object model, Digital Asset integration, security patterns, and storage type guidance. Includes comprehensive storage decision framework for optimal data structure selection. Triggers on: 'write contract', 'create NFT collection', 'build marketplace', 'implement minting', 'generate Move module', 'create token contract', 'build DAO', 'implement staking'. Ask storage questions when: 'store', 'track', 'registry', 'mapping', 'list', 'collection'.

★ 14
luokai0
luokai0/ai-agent-skills-by-luo-kai

web-search

通用网络搜索技能,支持多引擎搜索(百度、必应、DuckDuckGo),无需API密钥即可获取实时信息

★ 14
luokai0
luokai0/ai-agent-skills-by-luo-kai

solo-build

Execute implementation plan tasks with TDD workflow, auto-commit, and phase gates. Use when user says "build it", "start building", "execute plan", "implement tasks", "ship it", or references a track ID. Do NOT use for planning (use /plan) or scaffolding (use /scaffold).

Skill与智能体开发
★ 14
luokai0
luokai0/ai-agent-skills-by-luo-kai

react-email

Use when building HTML email templates with React components, adding a visual email editor to an application using the React Email visual editor, rendering emails to HTML, or sending emails with Resend. Covers welcome emails, password resets, notifications, order confirmations, newsletters, transactional emails, and the embeddable email editor component.

邮件与沟通前端开发
★ 14
luokai0
luokai0/ai-agent-skills-by-luo-kai

APITester Agent-Driven API Testing

Test API endpoints and document responses. Define tests in plain English, run them, get formatted results. Agent-driven Postman alternative.

开发工程师测试与质量后端与接口
★ 14
luokai0
luokai0/ai-agent-skills-by-luo-kai

hubspot-implementation-plan

Generate a phased implementation plan from a HubSpot audit report. Creates prioritized, sequenced cleanup processes with effort estimates, dependencies, and automation feasibility. Use after running /hubspot-audit.

★ 14