Work Timeline Planner 是一个将证据转化为时间线报告的工具。可用输入包括：git 历史、项目文档、用户描述、聊天记录。输出可以是 Markdown、独立 HTML，或两者兼具。
用途
- 回溯性复盘：过去一段时间完成了什么，可覆盖单个项目或多个项目。
- 前瞻性规划：接下来应做什么、何时做、以什么顺序做。
技能目录结构 <installed-skill-dir>/ ├── SKILL.md ├── references/ │ ├── evidence-model.md │ ├── output-formats.md │ └── report-modes.md └── templates/ ├── timeline-report.html └── timeline-report.md
渐进式加载
- 始终读取 references/evidence-model.md。
- 在个人复盘、导师报告、规划报告或混合模式之间选择时，读取 references/report-modes.md。
- 在 Markdown、HTML 或两者之间选择，或在 Mermaid、Frappe Gantt、Plotly 之间选择时，读取 references/output-formats.md。
- 使用 templates/timeline-report.md 和 templates/timeline-report.html 作为输出骨架。
核心原则
- 时间线块应有证据支撑，而非仅靠提交数量。
- 提交是信号，不是完整故事；需与文档、笔记、用户上下文结合。
- 倾向少量有意义的工作块，而非逐次提交的噪声图表。
- 区分已观察事实与推断出的日期范围。
- 考虑受众：个人多项目复盘范围更广；面向导师的单项目报告应更紧凑、更具解释性。
- 规划时，把已承诺工作与可选或拉伸工作分开。
- 选择最轻量且仍适合用户用例的图表技术。
第 1 步 — 对请求分类 先确定主要模式：
- personal-review：复盘过去工作，常跨多个项目。
- mentor-report：为单个项目、单一受众总结过去工作。
- next-phase-plan：为即将开展的工作规划里程碑与依赖。
- hybrid：总结近期工作，再提出下一阶段。 同时确定：时间窗口、项目范围、受众、期望粒度、输出格式（markdown、html 或两者）、图表引擎（mermaid、frappe-gantt 或 plotly）。 若用户未指定时间窗口，从上下文推断一个合理窗口，并在报告中明确说明。 默认输出策略：
- Markdown + Mermaid：适合可分享、仓库原生的报告。
- HTML + Frappe Gantt：适合更丰富的交互式复盘。
- 两者：当用户既想要可归档报告，又想要更好的本地可视化。
第 2 步 — 收集证据 优先使用一手证据。对每个范围内的仓库收集： git rev-parse --show-toplevel git log --date=short --stat --reverse --since="<start-date>" --until="<end-date>" git log --date=short --pretty=format:"%ad%x09%h%x09%s" --since="<start-date>" --until="<end-date>" 然后叠加：项目文档（如 README.md、docs/、PROJECT.md、decision-log、experiment logs 或进度笔记）；用户提供的笔记或描述；用户提供的聊天摘录或会议记录。 若用户需要多项目复盘，按项目分别收集证据并保持项目边界清晰。 若一个或多个仓库或笔记缺失，只询问避免虚构时间线所需的最少缺失输入。
第 3 步 — 构建工作块 将原始证据转化为少量工作块。每个块应包含：项目、标题、日期范围、类型（implementation、experiment、debugging、writing、infra、planning、reporting 或 review）、证据依据、简短结果。 除非用户明确要求逐次提交的粒度，否则不要把一次提交映射为一个甘特任务。应合并相关提交为一个连贯块；当目标明显变化时拆分块；用文档或笔记解释提交稀疏但确有工作的时期。当日期范围是推断而非明确时，在文字总结中说明。
第 4 步 — 选择报告形态 遵循 references/report-modes.md。默认：personal-review 按项目分组、再按工作流分组；mentor-report 按项目阶段或交付物分组，而非按每个技术分支；next-phase-plan 按里程碑与依赖分组。 最终输出通常应包含：简短的范围摘要、证据说明、图表或时间线可视化、关键块的简明叙述总结、可选的下一阶段行动。
第 5 步 — 撰写输出报告 遵循 references/output-formats.md。Markdown 输出以 templates/timeline-report.md 为基础结构；HTML 输出以 templates/timeline-report.html 为基础结构。 图表引擎通常这样选：
- mermaid：默认用于保留在仓库或聊天中分享的轻量 Markdown 报告。
- frappe-gantt：默认用于用户想本地查看、UI 更好的独立 HTML。
- plotly：仅当已有干净结构化任务数据并想要交互式时间线时使用，尤其是 Python 驱动的工作流。 Markdown 的默认甘特图应使用 Mermaid：
gantt
title Example
dateFormat YYYY-MM-DD
section Project A
Baseline experiments :done, a1, 2026-04-01, 5d
Model fixes :done, a2, after a1, 4d
Next ablation :active, a3, 2026-04-12, 6d
指南：每个项目或里程碑组用一个 section；任务名保持简短；优先可读块而非精确但杂乱细节；有用时用 done 标记已完成的回溯性工作；仅在时间合理时用 active 或普通未来任务标记当前或计划工作；HTML 输出优先单个自包含文件，而非多文件迷你应用，除非用户明确想要更大工件。
第 6 步 — 在需要时加入规划 若用户需要前瞻规划：分开已完成工作与计划工作；识别依赖与阻塞项；提出里程碑大小的块，而非伪精确的逐日虚构；明确标记不确定性。规划时应包含优先级、依赖、预期结果、相关时包含负责人。
第 7 步 — 定稿前自检 展示报告前检查：所有主要块都有实际证据支撑；时间窗口已明确说明；多项目报告不模糊项目归属；面向导师的报告解释结果而非仅罗列活动；计划工作不与已完成工作混在一起；所选图表语法或嵌入数据结构有效。
输出预期 最终输出通常是用户可保留或分享的文档。若要求保存到仓库，可使用匹配用户目的的路径，例如： docs/reports/work_timeline_YYYY_MM.md docs/reports/mentor_update_YYYY_MM.md docs/plans/next_phase_timeline.md docs/reports/work_timeline_YYYY_MM.html docs/reports/mentor_update_YYYY_MM.html 若用户只想要聊天中的草稿，仍应结构化，使其可直接保存为文件。