Stats
Actions
Tags
From team-standards
Records daily work log entries after source code edits, merging multiple changes for the same bug or feature into single entries with cumulative time estimates.
How this skill is triggered — by the user, by Claude, or both
Slash command
/team-standards:daily-work-logThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**每次对业务项目源码有实质改动（Edit/Write），就在用户文档目录 `{USER_DOCUMENTS}/ai-docs/{project}/work-log/{YYYY-MM-DD}.md` 追加或合并一条记录。**
每次对业务项目源码有实质改动（Edit/Write），就在用户文档目录 {USER_DOCUMENTS}/ai-docs/{project}/work-log/{YYYY-MM-DD}.md 追加或合并一条记录。
工作日志记录的是个人工时与改动流水，属于个人工作记录，与 bug-doc-required / design-doc-required 等 AI 起草文档一样默认写入用户文档目录，不写入项目仓库，与项目代码、设计文档、bug 文档物理隔离。
不是记录 AI 对话内容；不是记录流水账；是把"今天做了什么可以上交日报的工作"按 bug / 功能 分类沉淀。
批处理模式（默认）：本 skill 在编码中不主动打断——改一次代码就跳出来登记日志会破坏主流程。默认采用会话末批处理：编码过程中只在内部跟踪改动列表，会话结束前一次性写入当天日志文件。详见下方「批处理模式约束」。
| 场景 | 触发 |
|---|---|
本会话完成了至少一次源码 Edit/Write（.dart / .java / .kt / .ts / .py / .go 等），且尚未登记 | ✅ 必须触发（会话末批处理，不在改动当时立即写入） |
| 用户说"记一下工作日志"/"写个日志"/"更新工作日志"/"记到日志"/"记录一下" | ✅ 必须触发（用户主动要求 → 立即执行） |
| 用户说"今天做了什么" / "回顾一下" | ✅ 必须触发（查询模式） |
| 会话结束前（收尾阶段）若本会话有源码改动未登记 | ✅ 强制回补 |
| 本会话只改了文档 / 配置 / 未动业务源码 | ❌ 不触发（交由 dev-log） |
改的是 team-standards/ 自身 | ❌ 不触发（交由 dev-log） |
与 CLAUDE.md § 改动规模 → 链路档位 配套使用。S 档(小改)仍可不写日志或一行带过;M / L 档启用本批处理模式。
| 时机 | 行为 |
|---|---|
| 编码中: 每次源码 Edit/Write 完成 | 不立即跳出来写日志, 改动累积在内部上下文(记录: 时间 / 文件 / 类型: bug 修复 vs 功能开发 / 一句话动作描述) |
| 编码中: 用户主动说"记一下"/"写个日志" | 立即执行登记, 这是用户主动要求 |
| 改完代码后 / 会话结束前 | 一次性写入当天日志: 读 {YYYY-MM-DD}.md → 合并同 bug / 同功能多次改动 → 累计工时 → 写入磁盘 |
| 用户说"提交"/"commit" | 在 commit 前完成日志批处理(与 git-commit-standards 协同) |
批处理的好处：
{USER_DOCUMENTS}/ai-docs/{project}/work-log/{YYYY-MM-DD}.md
%USERPROFILE%\Documents\ai-docs\{project}\work-log\{YYYY-MM-DD}.md~/Documents/ai-docs/{project}/work-log/{YYYY-MM-DD}.md~/ai-docs/{project}/work-log/{YYYY-MM-DD}.md{project} 取当前业务项目目录名（避免多个项目工作日志混在一起）HH:MM 用 24 小时制本地时间{USER_DOCUMENTS}/ai-docs/{project}/work-log/与 doc-index-required 一致，写日志文件前向用户回显一行：
工作日志输出路径：{用户目录默认 / 用户指定路径} -> {目标路径}
工作日志属个人工作记录，绝不写入业务项目 docs/，不入仓。原 docs/work-log/ 历史目录由用户决定如何处理（保留本地、迁移到用户目录、或删除），本 skill 不做自动迁移。
仅当用户明确说「写到项目 docs/work-log/」/「上传到仓库」时，才允许落项目目录，且此时必须主动检查 .gitignore 是否已忽略 docs/work-log/，未忽略则按"用户指定项目路径"流程交由 doc-index-required 走 Phase-A/B（这是非默认路径）。
# 工作日志 · {YYYY-MM-DD}
> 按条目合并：同一 bug 多次修复追加到同一条目；同一功能多轮开发追加到同一条目；工时累计估算。
## 🐛 Bug 修复
（暂无）
## ✨ 功能开发
（暂无）
## 🐛 Bug 修复 / ## ✨ 功能开发### [B{n}] 或 ### [F{n}] 作为条目标题### [B{n}] {bug 简要标题，≤ 30 字}
- **预估工时**：{累计 h}h
- **关联文档**：[docs/bug/{模块}/{bug 名}/{bug 名}.md](相对路径)
- **涉及文件**：
- `lib/path/to/file1.dart`
- `lib/path/to/file2.dart`
- **修改明细**：
- `HH:MM` {一句话改动摘要，≤ 50 字}
- `HH:MM` {一句话改动摘要}
### [F{n}] {功能简要标题，≤ 30 字}
- **预估工时**：{累计 h}h
- **关联文档**：[docs/design/{需求}/{需求}-{YYYYMMDD}-v{N}.md](相对路径)
- **涉及文件**：
- `lib/path/to/file1.dart`
- **修改明细**：
- `HH:MM` {摘要}
...等 N 个文件**每次触发时，Step 0 必须 Read 当天的日志文件，**提取所有已存在条目的 ### [Bx]/[Fx] 标题，再决定本次是合并还是新建。
flowchart TD
START(["本次改动待登记"]) --> R["Read 今日 work-log\n提取所有条目标题"]
R --> Q1{"本次会话是否\n触发过 bug-doc-required?"}
Q1 -->|"是"| B1["用 bug 文档的标题\n查已有 Bx 条目"]
Q1 -->|"否"| Q2{"本次会话是否\n触发过 design-doc-required?"}
Q2 -->|"是"| F1["用设计文档标题\n查已有 Fx 条目"]
Q2 -->|"否"| Q3{"用户给出主题名?"}
Q3 -->|"是"| ASK["按用户主题名\n模糊匹配已有条目"]
Q3 -->|"否"| Q4{"是 bug 还是功能?\n(看改动上下文)"}
Q4 -->|"bug"| NEWB["新建 [B{next}] 条目"]
Q4 -->|"功能"| NEWF["新建 [F{next}] 条目"]
B1 --> MATCH{"命中?"}
F1 --> MATCH
ASK --> MATCH
MATCH -->|"是"| APPEND["在已有条目\n修改明细追加一行\n更新累计工时"]
MATCH -->|"否"| CREATE["新建条目\n写入初始工时"]
NEWB --> CREATE
NEWF --> CREATE
APPEND --> DONE(["报告用户"])
CREATE --> DONE
同名合并：标题含义相同（允许用词小差异）就合并；完全相同更要合并。不确定时询问用户，不要盲建两条。
| 信号 | 分类 |
|---|---|
本会话触发过 bug-doc-required | 🐛 Bug 修复 |
有 docs/bug/{...}/{bug 名}.md 新建 / 编辑 | 🐛 Bug 修复 |
| 用户说「修复」「fix」「bug」「报错」「异常」「空列表」「不对」「有问题」 | 🐛 Bug 修复 |
| 改动主要是"让原本该工作的代码真正工作" | 🐛 Bug 修复 |
本会话触发过 design-doc-required 且是新需求/新接口 | ✨ 功能开发 |
| 用户说「加个」「新增」「实现」「做一个」「feature」 | ✨ 功能开发 |
| 改动主要是"引入原本不存在的能力" | ✨ 功能开发 |
| 混合（既是 bug 也引入新字段）→ 主诉为准 | 按主诉分类 |
重构/迁移：默认归到 ✨ 功能开发，标题注明 [重构] 或 [迁移] 前缀。
累加式估算：每次追加时，基于本轮改动规模再加一份，累计写到"预估工时"字段。
| 本轮改动规模 | 基础工时 |
|---|---|
| 1 文件、改 1-5 行（纯 typo / 小改参数） | 0.25h |
| 1-2 文件、改 ≤ 20 行 | 0.5h |
| 3-5 文件、单模块内 | 1h |
| 6-10 文件 / 跨层（service + dao + dto） | 2h |
| > 10 文件 / 跨模块 / 含 freezed 新字段（需 build_runner） | 3h |
| 跨项目（korepos + 云端 + team-standards 等 ≥ 2 个项目） | 4h |
| 条件 | 附加 |
|---|---|
| 本次还编写了设计文档 | +1h |
| 本次还编写了 bug 分析文档 | +1h |
| 本次还改了 skill 规范 | +0.5h |
| 本次包含 Rust FFI / 云端对齐核查 | +1h |
| 本次包含 UI 对接手册同步 | +0.5h |
| 方案迭代（先改一版、再换方案 A/B） | +0.5h × 迭代轮数 |
新条目：本轮工时（基础 + 叠加）
追加：原累计 + 本轮工时（基础 + 叠加）
工时取整到 0.5h；单条目累计上限 8h，超过说明应拆成多条目（bug 太大应分子 bug，功能太大应分子任务）。
1h + 1h + 1h = 3h3h + 1h + 0.5h = 4.5h@JsonKey 注解 → 4.5h + 0.25h ≈ 5h- 列表项）HH:MM（本地时间，24 小时制）- `14:32` 修 refund_confirm_service.dart:142 过滤条件从 paymentType==4 切到 pay_channel_code
- `15:05` 加 RefundTransactionAllocation.originalPayChannelCode 字段（L1 ACL 注解）
- `15:40` 删 _inferPosRefundType（pay_method 白名单不再需要）
- `16:10` 方案 A 迭代：RefundTransactionResult 加 originalPayChannelCode 透传
- `16:30` 补 @JsonKey 注解，avoid 泄漏到 /v2/refund/write wire
❌ - 根据用户要求，分析了当前代码，发现存在多处问题，然后依次进行修改，首先改了 A 文件，然后...
（叙述体、跨多句）
❌ - 修了一些东西
（没具体对象）
❌ - 改代码
（没动词对象，废话）
flowchart TD
T(["触发时机命中"]) --> S1["Step 1\n确定今日日期 YYYY-MM-DD"]
S1 --> S2["Step 2\nRead 用户目录今日 work-log\n不存在则初始化骨架"]
S2 --> S3["Step 3\n判断 bug vs 功能"]
S3 --> S4["Step 4\n合并判定：命中已有条目 or 新建"]
S4 --> S5["Step 5\n本轮工时估算"]
S5 --> S6{"命中已有?"}
S6 -->|"是"| S7A["在已有条目\n追加明细行\n更新累计工时"]
S6 -->|"否"| S7B["新建条目\n分配 [B{n+1}] / [F{n+1}] ID\n写入初始工时"]
S7A --> S8["Step 8\nEdit 文件（注意保留排序）"]
S7B --> S8
S8 --> S9["Step 9\n回报用户：登记了哪条、累计工时多少"]
S9 --> END(["完成"])
在会话明显进入收尾阶段（用户说"可以了"、"就这样"、"完成了"、"结束"等）时：
这是最后一次补登的机会。会话一旦结束就无法追溯。
design-doc-required / bug-doc-required
↓
pre-implementation-code-orientation
↓
{代码实际 Edit/Write}
↓
daily-work-log ← 本 skill（每轮 Edit 后 或 会话结束前）
↓
git-commit-standards（可选，提交时）
↓
dev-log（仅 team-standards 项目：会话结束前）
dev-log 是 team-standards 自身的变更日志，作用在 插件仓库daily-work-log 是业务项目的工作日志，作用在 业务项目不是写入，是读取回报。
| 行为 | 为什么禁止 |
|---|---|
| 不读直接写，导致同一 bug 写了多条 | 违反"同主题合并"核心规则 |
| 记录"用户问了什么 AI 答了什么"的对话流水 | 本 skill 不是对话存档，是工作沉淀 |
| 记录失败尝试 / 废弃分支（除非本身是新 bug） | 工作日志不是 AI 调试记录 |
| 预估工时超过 8h / 单条目 | 说明主题太大，应拆子条目 |
| 修改明细跨行 / 段落叙述 | 违反"一行一条" |
| 为每次 Edit 新建条目（即使是同一 bug） | 违反"同 bug 合并" |
把工作日志写到业务项目 docs/ 下（除非用户明确要求） | 与 bug/design 文档默认路径一致：AI 起草个人记录走用户文档目录，不入仓 |
| 把 skill/文档修改记到 daily-work-log | 错位；应走 dev-log |
| 未经用户明确指定却把日志落到项目内 | 个人工时记录不属于项目资产；必须默认走 {USER_DOCUMENTS}/ai-docs/ |
{USER_DOCUMENTS}/ai-docs/{project}/work-log/{YYYY-MM-DD}.md（用户文档目录、个人记录），不是项目仓库npx claudepluginhub exception-coder/team-standards --plugin team-standardsProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.