Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计通过

specstory-session-summary光谱故事会议摘要

Agent Skill

specstory-session-summary 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

4,492

周安装

191

GitHub Stars

24

下载量

1,574
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:specstory-session-summary(光谱故事会议摘要)
来源仓库:https://github.com/specstoryai/agent-skills
仓库路径:skills/specstory-session-summary
安装命令:
npx skills add https://github.com/specstoryai/agent-skills --skill specstory-session-summary
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/specstoryai/agent-skills --skill specstory-session-summary

简介

specstory-session-summary 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中快速定位候选结果。

  • 适用于基于关键词或任务场景的信息检索需求。
  • 可通过安装命令或访问原始 README 核验具体用法。
  • 安装前应确认是否会触发联网、命令执行或文件读写操作。
  • 建议评估项目维护状态后再决定是否集成到工作流中。

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

  1. End (last 300 lines) - Use tail -300 <file> via Bash

- Contains the final outcome and conclusion - Shows whether tasks were completed or left pending

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

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

  1. Files: Modified files from Edit/Write tool uses (extract filenames only)
  2. 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

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.32%
按下载量换算572

Claude

30.11%
按下载量换算474

Cursor

20.23%
按下载量换算318

Gemini CLI

9.44%
按下载量换算149

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills