name: SpecStory 跑题分析器 description: 分析您的SpecStory AI编码会话在.specstory/history中的跑题行为 - 当您的初始目标被带偏到兔子洞时。当用户说“分析我的跑题”、“检查兔子洞”、“我有多分心”或“跑题得分”时运行。 license: Apache-2.0 metadata: author: specstory version: “1.0.0” argument-hint: “[天数|日期范围]”
SpecStory 跑题分析器
分析您的.specstory/history以检测编码会话是否从原始目标偏离。为每个会话生成“跑题得分”。
工作原理
- 解析 来自日期范围（或所有最近会话）的specstory历史文件
- 提取 第一条消息中的初始用户意图
- 跟踪 领域转移：文件引用、工具调用模式、目标变化
- 评分 每个会话从0（高度专注）到100（最大跑题）
- 总结 您最严重的跑题会话和模式
什么是跑题行为？
“我需要部署我的应用，但首先我需要修复CI，但首先我需要更新Node，但首先我需要修复我的shell配置…”
跑题行为是当您从目标A开始，但最终陷入不相关的任务Z。此技能在您的AI编码会话中检测该模式。
用法
斜杠命令
当通过/specstory-yak调用时，解释用户的自然语言：
| 用户说 | 脚本参数 |
|---|---|
/specstory-yak |
--days 7（默认） |
/specstory-yak last 30 days |
--days 30 |
/specstory-yak this week |
--days 7 |
/specstory-yak top 10 |
--top 10 |
/specstory-yak january |
--from 2026-01-01 --to 2026-01-31 |
/specstory-yak from jan 15 to jan 20 |
--from 2026-01-15 --to 2026-01-20 |
/specstory-yak by modification time |
--by-mtime |
/specstory-yak last 14 days as json |
--days 14 --json |
/specstory-yak save to yak-report.md |
-o yak-report.md |
/specstory-yak last 90 days output to report |
--days 90 -o report.md |
直接脚本使用
python /path/to/skills/specstory-yak/scripts/analyze.py [选项]
参数：
--days N- 分析最近N天（默认：7）--from 日期- 开始日期（YYYY-MM-DD）--to 日期- 结束日期（YYYY-MM-DD）--path 路径- .specstory/history的路径（如果未指定则自动检测）--top N- 显示前N个最严重的跑题会话（默认：5）--json- 输出为JSON--verbose- 显示详细分析--by-mtime- 按文件修改时间过滤而非文件名日期-o, --output 文件- 将报告写入文件（自动添加.md或.json扩展名）
示例：
# 分析最近7天
python scripts/analyze.py
# 分析最近30天，显示前10个
python scripts/analyze.py --days 30 --top 10
# 分析特定日期范围
python scripts/analyze.py --from 2026-01-01 --to 2026-01-28
# 按文件修改时间过滤（非会话开始时间）
python scripts/analyze.py --days 7 --by-mtime
# JSON输出以便进一步处理
python scripts/analyze.py --days 14 --json
# 将报告保存到Markdown文件
python scripts/analyze.py --days 90 -o yak-report.md
# 将JSON保存到文件
python scripts/analyze.py --days 30 --json -o yak-data.json
输出
跑题报告（2026-01-21 至 2026-01-28）
==========================================
分析的会话：23
平均跑题得分：34/100
最严重的跑题会话：
---------------
1. [87/100] “修复按钮对齐”（2026-01-25）
开始：CSS修复按钮
结束：重写整个构建系统
领域转移：4（ui -> build -> docker -> k8s）
2. [72/100] “添加注销功能”（2026-01-23）
开始：添加注销按钮
结束：重构认证系统 + 会话管理
领域转移：3（ui -> auth -> database）
3. [65/100] “更新readme”（2026-01-22）
开始：文档更新
结束：CI管道大修
领域转移：2（docs -> ci -> testing）
最专注的会话：
----------------------
1. [5/100] “解释认证流程”（2026-01-26） - 纯分析，无偏离
2. [8/100] “修复配置中的拼写错误”（2026-01-24） - 快速外科式修复
检测到的模式：
------------------
- 您最常跑题的任务：UI任务（平均58/100）
- 最安全的任务类型：代码审查/解释（平均12/100）
- 跑题高峰时段：晚上11点至凌晨2点（平均71/100）
评分方法
跑题得分（0-100）计算自：
| 因素 | 权重 | 描述 |
|---|---|---|
| 领域转移 | 40% | 文件引用跳转领域的次数 |
| 目标完成 | 25% | 原始陈述的目标是否完成？ |
| 会话长度比率 | 20% | 长度与原始请求复杂度的比例 |
| 工具类型级联 | 15% | 读->搜索->编辑->创建->部署的升级 |
得分解释：
- 0-20：高度专注
- 21-40：轻微偏离
- 41-60：适度偏离
- 61-80：显著跑题
- 81-100：史诗级兔子洞
向用户呈现结果
重要：运行分析器脚本后，您必须在响应最顶部添加个性化的LLM生成摘要，然后显示原始报告输出。
LLM摘要指南
生成3-5句个性化评论：
-
以裁决开头 - 关于整体状态的机智一句话（例如，“您本周的编码会话……是一次冒险。”或“非常自律！有人一直在服用专注维生素。”）
-
突出亮点 - 具体引用最显著的会话：
- 如果跑题严重：“那个1月25日的按钮修复，如何变成了Kubernetes迁移？厨师之吻的范围蔓延。”
- 如果跑题轻微：“您1月26日的认证流程解释非常精准 - 进进出出，无偏离。”
-
识别模式 - 注意任何重复主题：
- “您似乎从UI任务开始时最常跑题”
- “深夜会话是您的危险区域”
- “您的重构会话往往保持专注”
-
以可操作建议或玩笑结束 - 要么：
- 实用提示：“考虑时间盒那些‘快速CSS修复’ - 它们有73%的跑题率”
- 或玩笑：“以这个速度，您下一个拼写错误修复将导致Linux内核的完全重写”
LLM摘要示例
## 🐃 您的跑题分析
好吧，好吧，好吧。您来修复按钮，离开时却重写了半数基础设施。您的平均跑题得分47/100，使您牢牢处于“经典开发者行为”领域。
亮点？那个1月25日的会话，CSS对齐修复如何演变成完整的Kubernetes部署大修。四次领域转移后，您可能都忘了按钮长什么样了。
我注意到的模式：您的UI任务跑题率比代码审查会话高58%。也许在日历中将那些‘快速UI修复’标记为‘潜在的3小时冒险’。
以下是完整细分：
然后在摘要下方显示原始报告输出。
突出显示内容
在摘要之后，呈现原始结果时：
- 最严重的跑题会话，带有前后对比
- 模式在何时/什么导致跑题
- 可操作洞察 - 需要注意的任务类型