原帖：【SOLO 技能创作赛】what-did-i-get-done 总结你的工作成果，为汇报提供材料
作者： 博士哥
Phase A：材料
| 项目 | 内容 |
|---|---|
| 来源 | GitHub 仓库 skills/what-did-i-get-done at main · Master-Frank/skills · GitHub |
| 文件结构 | 仅包含 SKILL.md（1012 bytes），无 scripts/、references/、dist/ 等目录 |
| Frontmatter | name: what-did-i-get-done，description: Summarize authored commits over a user-specified time period into a concise update |
Phase B：结构扫描
2.1 Frontmatter 字段
| 字段 | 值 | 评估 |
|---|---|---|
| name | what-did-i-get-done |  清晰、可识别 |
| description | Summarize authored commits… | 功能明确，但略显技术化 |
| allowed-tools | 缺失 |  未声明依赖的工具（如 RunCommand、Read） |
| dependencies | 缺失 | 未声明依赖 git 环境 |
2.2 触发信号
原文 Trigger：
Need a short, high-signal summary of work completed in a specific time range (for example: yesterday, last 3 days, or last week).
触发信号提取：
- 场景明确：需要工作总结/状态更新
- 时间范围关键词：yesterday、last N days、last week
- 缺少自然语言触发示例（如"我昨天做了什么"、“总结一下本周工作”）
2.3 工作流
| 步骤 | 描述 | 依赖 |
|---|---|---|
| 1 | 解析时间窗口为具体日期 | 无 |
| 2 | 读取当前 git 用户在该范围内的 authored commits | git log 命令 |
| 3 | 排除 merge commits 和未提交变更 | git 过滤参数 |
| 4 | 合成重要变更为简洁状态更新 | 无 |
| 5 | 在最终摘要中包含实际日期范围 | 无 |
2.4 约束（Guardrails）
| 约束类型 | 内容 |
|---|---|
| 风格 | 极简洁、信息密集 |
| 优先级 | 优先实质性行为/架构变更 |
| 排除 | 仅格式化、import、轻微重命名的变更 |
| 描述原则 | 不推断意图或动机，功能性描述变更 |
2.5 输出契约
| 输出项 | 规格 |
|---|---|
| 摘要 | 一段简短的状态更新 |
| 日期范围 | 实际使用的日期范围 |
| 可选要点 | 2-5 条主要变更 |
Phase C：类型与分层
3.1 Skill 类型判定
| 类型 | 判定 | 说明 |
|---|---|---|
| knowledge |  |
不存储知识 |
| router | |
不做分发/路由 |
| workflow | 主类型 |
定义了明确的执行流程 |
| executor | |
无独立执行脚本 |
| hybrid | |
无混合特征 |
结论： 这是一个纯 Workflow 型 Skill，依赖 Agent 执行 git 命令并合成摘要。
3.2 三层拆解
| 层级 | 内容 | 存在性 |
|---|---|---|
| 判断层 | 时间窗口解析、commit 筛选判断 | 隐含在 Workflow 步骤 1-3 |
| Workflow 层 | 5 步流程定义 | 明确声明 |
| 执行层 | git 命令执行、文本合成 | 未声明具体工具/命令 |
Phase D：能力树
4.1 用户可感知能力
| 能力 | 描述 | 用户价值 |
|---|---|---|
| 工作总结生成 | 将 git commits 转化为简洁状态更新 | 快速汇报、减少手动整理 |
| 时间范围筛选 | 支持 yesterday/last N days/last week | 灵活的时间窗口 |
| 变更优先级过滤 | 自动排除低价值变更 | 高信噪比输出 |
4.2 执行层能力
| 能力 | 依赖 | 状态 |
|---|---|---|
| git log 查询 | RunCommand + git 环境 | 未声明工具依赖 |
| 日期解析 | Agent 内置能力 | |
| 文本合成 | Agent LLM 能力 | |
4.3 输入/输出契约
输入：
- 时间范围描述（自然语言）
- 当前 git 用户 email（隐式获取）
输出：
- 状态更新摘要（一段文字）
- 实际日期范围
- 可选：2-5 条主要变更要点
4.4 关键路径
用户请求 → 时间解析 → git log --author=<email> --since=<start> --until=<end>
→ 过滤 merge commits → 提取关键变更 → 合成摘要 → 输出
Phase E：边界与风险
5.1 不做什么
| 边界 | 说明 |
|---|---|
|
不分析未提交变更（明确排除） |
|
不推断意图/动机（功能性描述原则） |
|
不包含 cosmetic 变更（仅格式化/import/重命名排除） |
|
不跨仓库分析（仅当前 git 环境） |
5.2 误用场景
| 场景 | 风险 |
|---|---|
| 非 git 项目 | 无法执行，缺少前置检查 |
| 多人协作仓库 | 可能遗漏非 authored 的相关变更 |
| 无 commit 历史 | 输出为空，缺少 fallback 提示 |
| 时间范围过大 | 输出可能过长，缺少长度限制 |
5.3 风险点清单
| 风险 | 等级 | 说明 |
|---|---|---|
| 工具依赖未声明 |  高 |
Agent 可能不知道需要 RunCommand |
| 环境依赖未声明 | 高 |
缺少 git 环境检查机制 |
| 输出长度无限制 |  中 |
大时间范围可能导致输出过长 |
| 无错误处理 | 中 |
git 命令失败时无 fallback |
Phase F：改造建议
按收益优先级排序，改动克制：
建议 1：补充工具与环境依赖声明 高优先级
| 项目 | 内容 |
|---|---|
| 目标 | 让 Agent 明确知道需要哪些工具和环境 |
| 变更点 | 在 frontmatter 添加 allowed-tools 和 dependencies |
| 示例 | 见下方代码块 |
| 风险 | 无 |
| 验收 | Agent 在无 git 环境时能正确报错 |
---
name: what-did-i-get-done
description: Summarize authored commits...
allowed-tools:
- RunCommand
dependencies:
- git (必须存在于当前工作目录)
---
建议 2：增强触发信号 中优先级
| 项目 | 内容 |
|---|---|
| 目标 | 提高自然语言触发命中率 |
| 变更点 | 在 Trigger 部分添加更多自然语言示例 |
| 风险 | 无 |
| 验收 | 用户自然语言请求能正确触发 |
## Trigger
**Invoke when user says:**
- "我昨天做了什么"
- "总结一下本周工作"
- "生成最近3天的状态更新"
- "What did I get done yesterday"
建议 3：添加前置检查与错误处理 中优先级
| 项目 | 内容 |
|---|---|
| 目标 | 避免在无 git 环境时执行失败 |
| 变更点 | 在 Workflow 步骤 0 添加环境检查 |
| 风险 | 低 - 增加一步但不改变核心逻辑 |
| 验收 | 非 git 目录时能给出友好提示 |
## Workflow
0. **Pre-check**: Verify git is available and current directory is a git repository.
- If not, inform user and exit gracefully.
1. Resolve the requested time window...
建议 4：明确 git 命令模板 
低优先级
| 项目 | 内容 |
|---|---|
| 目标 | 减少 Agent 执行歧义 |
| 变更点 | 在 Workflow 或新增 Execution 部分提供命令示例 |
| 风险 | 低 - 仅作为参考，不强制 |
| 验收 | Agent 能正确构造 git 命令 |
# Get authored commits:
git log --author=$(git config user.email) --since=<start> --until=<end> --no-merges --oneline
# For detailed changes:
git log --author=<email> --since=<start> --until=<end> --no-merges --stat
建议 5：输出长度约束 低优先级
| 项目 | 内容 |
|---|---|
| 目标 | 防止大时间范围输出过长 |
| 变更点 | 在 Guardrails 或 Output 添加长度限制 |
| 风险 | 低 |
| 验收 | 大时间范围输出保持简洁 |
## Guardrails (补充)
- If time range exceeds 7 days, limit output to top 10 most significant changes.
- Maximum 5 bullets in optional list.
总结评估
| 维度 | 评分 | 说明 |
|---|---|---|
| 可触发性 |  (3/5) |
Trigger 场景明确，但缺少自然语言示例 |
| 可交付性 | (4/5) |
输出契约清晰，格式明确 |
| 可执行性 | (2/5) |
工具/环境依赖未声明，执行层模糊 |
| 结构完整性 | (3/5) |
有 Workflow/Guardrails/Output，缺依赖声明 |
| 边界清晰度 | (4/5) |
不做什么明确，风险点可预见 |
整体评价： 这是一个设计简洁、目标明确的 Workflow 型 Skill，核心逻辑清晰。主要问题在于执行层依赖未声明，可能导致 Agent 在无 git 环境或缺少工具权限时执行失败。建议优先实施建议 1-3，可显著提升可执行性和健壮性。
