code996

code996 — 团队工作强度 / 996 分析报告

根据用户请求，调用 code996 采集结构化数据，结合 git log 语义分析和用户口述背景，生成一份面向管理者/团队的叙事化工作强度报告。

从用户请求中提取可选参数，包括仓库路径、时间范围和输出格式。

---

执行与交互原则

• 根据宿主环境选择可用的命令执行方式，不假设存在 find、sed、awk、head 等 POSIX 工具。
• 将每个仓库路径作为独立参数传递，并使用当前 shell 对应的安全引用方式。不要按空格拆分路径，也不要把未经转义的路径拼接进命令字符串。
• 命令本身必须是非交互式的；需要用户选择时，通过 AI 对话询问，不要启动等待终端输入的脚本。
• 先从用户请求中一次性提取仓库、时间范围、团队背景和输出格式。只有分析目标存在歧义时才追问，并把所有必要问题合并到一条消息中。
• 单仓库未指定时间范围时使用 code996 默认区间；多仓库未指定时间范围时先计算共享区间；未提供团队背景时继续分析并注明校准信息不足；未指定输出格式时直接在对话中展示报告。

---

步骤 1 — 确认分析目标

1a. 检测当前目录环境

若用户已明确提供一个或多个仓库路径，直接逐个验证。始终引用完整路径：

git -C "<path>" rev-parse --show-toplevel

若用户未指定路径，运行 git rev-parse --show-toplevel 检测当前目录：

• 成功：直接以返回的仓库根目录作为唯一分析目标，不再询问确认。
• 失败：使用宿主提供的文件搜索能力扫描当前目录向下最多两层的 Git 仓库，同时识别目录或文件形式的 .git，并排除 node_modules 等依赖目录。

根据扫描结果处理：

• 仅找到一个仓库：直接使用，不再询问确认。
• 找到多个仓库：列出带编号的候选项，请用户选择一个、多个或全部。
• 未找到仓库：请用户提供路径；多个路径要求每行一个，不要要求用空格分隔。

需要询问时只发送一条消息，并在其中同时收集必要的仓库选择和可选的团队背景。若宿主不支持连续对话且目标存在歧义，列出候选项并明确说明用户需要在下一次请求中指定目标，不要自行猜测或让命令等待输入。

示例询问：

在当前目录下发现多个 Git 仓库，请选择要分析的仓库（可多选或选择全部）：

1. ./repo-a
2. ./repo-b
3. ./repo-c

如方便，也可以补充团队规模、是否弹性工作制和约定的每日工时；这些信息可跳过。

用户回复后，保留每个路径的完整文本并逐个验证。选择一个仓库时使用单仓库模式，选择多个或全部时使用多仓库聚合模式。

---

1b. 识别时间范围

从用户请求或对话中提取，支持口述转换：

• 「2025 年」→ -y 2025
• 「最近半年」→ -s <6个月前的 YYYY-MM-DD>
• 单仓库未指定 → 不传参，使用 code996 默认（最后提交回溯 365 天）。
• 多仓库未指定 → 对每个仓库分别执行以下非交互式命令，取所有成功结果中最新的日期作为 <shared-until>，再用宿主的日期能力向前推 365 天得到 <shared-since>：

git -C "<path>" log --no-merges --format="%cd" --date=format:%Y-%m-%d --max-count=1

多仓库的每次 code996 调用都必须传入相同的 -s <shared-since> -u <shared-until>。若某个仓库无法取得最后提交日期，记录原因并继续用其他仓库计算；全部失败时才告知用户无法确定共享区间。

1c. 提取团队背景

从用户请求和既有对话中提取团队规模、是否弹性工作制、约定或法定的每日工时。这些信息用于校准结论，但不是执行分析的必要条件。

• 已提供：纳入报告分析。
• 未提供且无需询问仓库：不要单独追问，继续分析并在报告中说明未结合团队制度校准。
• 未提供且必须询问仓库：在同一条仓库选择消息中作为可选问题一次性收集，用户可跳过。

---

步骤 2 — 采集结构化数据

优先使用环境中已有且支持 --json 的 code996 命令；若命令不可用、不支持 --json、执行时拒绝该参数或 stdout 不是可解析的 JSON，则使用 npx --yes code996@latest 重新执行。不要把可执行命令和参数保存为依赖 shell 字符串拆分的变量。

根据对话语言直接传递 locale：中文使用 --lang zh-CN，英文使用 --lang en。下面以 npx 后备方式为例：

# 单仓库
npx --yes code996@latest "<path>" --json --lang zh-CN

多仓库时，每条命令必须单独执行并立即解析该次 stdout，不要在同一个 shell 调用中连续执行而得到拼接的 JSON：

# 未指定时间时，第一次调用
npx --yes code996@latest "<path1>" --json --lang zh-CN -s "<shared-since>" -u "<shared-until>"

# 未指定时间时，第二次调用
npx --yes code996@latest "<path2>" --json --lang zh-CN -s "<shared-since>" -u "<shared-until>"

# 指定年份
npx --yes code996@latest "<path>" --json --lang zh-CN -y 2025

若使用全局命令，将示例中的 npx --yes code996@latest 替换为 code996。其他时间范围按步骤 1b 添加 -s、-u 或 -y 参数。

多仓库模式下不要在同一次 code996 调用中传入多个路径：当前 CLI 会进入交互式仓库选择并混入进度文本，不适合 Agent 的非交互式 JSON 采集。应为每个仓库分别执行单仓库命令、独立解析 JSON，再基于各仓库结果进行聚合比较。若某个仓库失败，记录失败原因并继续处理其他仓库。

解析 JSON 输出，提取以下字段用于后续分析：

使用全局 code996 失败时，先按上述规则使用 npx --yes code996@latest 重试。只有最新版后备命令仍执行失败（如提交数不足）时，才告知用户原因并停止；多仓库模式则记录该仓库的失败原因并继续其他仓库。

---

步骤 3 — 加班时段语义分析

基于步骤 2 的 JSON 数据，识别加班高峰窗口，对同一仓库执行 git log 获取实际 commit message，归纳「加班都在干什么」。

对每个仓库获取带 ISO 时间的 commit message。执行前必须从该仓库对应的 JSON 中读取 meta.since 和 meta.until，作为 code996 实际采用的有效区间；不要继续使用用户原始口述值或未赋值的占位符。

正常默认区间和自定义区间使用：

git -C "<path>" log --no-merges --after="<meta.since>" --before="<meta.until>" --format="%cI|||%s" --max-count=500

若用户使用 --all-time，JSON 中的 meta.since 和 meta.until 会缺失，此时必须同时省略 --after、--before，不能传空字符串或保留字面占位符：

git -C "<path>" log --no-merges --format="%cI|||%s" --max-count=500

始终引用仓库路径，不依赖 POSIX 管道。

--no-merges 必须保留，使定性样本与 code996 定量分析默认排除合并提交的口径一致。

根据 %cI 中保留的提交本地日期、时间和时区进行筛选。先判断本次分析是否启用了中国节假日模式：显式使用 --cn 时直接视为启用；否则按分析区间内的非合并提交统计时区，将 %cI 的 +08:00 等偏移统一规范化为 +0800 格式，当 +0800 占比不低于 50% 时视为自动启用，与 code996 的判断保持一致。

• 未启用中国节假日模式：周一至周五视为工作日，周六、周日视为休息日。
• 启用中国节假日模式：使用宿主可用的可靠中国工作日日历（优先采用与 code996 相同的 holiday-calendar 数据）逐日判断；法定节假日视为休息日，调休周六或周日视为工作日，不再仅按星期判断。
• 若已启用中国节假日模式但宿主无法可靠取得日历结果：仍可分析不依赖日期类型的 23:00–05:59 样本；跳过工作日/休息日日间语义归因，并在报告中明确说明该限制。不得把调休工作日当作周末加班，或声称已覆盖法定节假日样本。

按上述日期类型筛选，使语义样本与 code996 使用的提交时间口径保持一致：

• 工作日晚间提交：日期被判定为工作日，本地时间从 ceil(workTime.endHour) 起至 22:59，最多取最近 50 条。
• 休息日提交：日期被判定为休息日，最多取最近 50 条。
• 深夜及凌晨提交：本地时间为 23:00–05:59，最多取最近 50 条。
• 合并以上样本时按 commit 去重，避免同一条休息日深夜提交被重复计入。
• 若最近 500 条提交不足以覆盖分析区间中的加班样本，可按时间窗口分段查询；避免一次输出完整大型仓库历史。

多仓库时对每个仓库分别执行，再合并归纳。

根据 commit message 将加班内容分类（可能重叠）：

• 赶需求 / 功能开发：含 feat / add / implement / 新增 等
• 修线上 Bug：含 fix / hotfix / bug / 修复 / 紧急 等
• 重构 / 技术债：含 refactor / chore / clean / 优化 等
• CI/CD / 发版：含 release / deploy / ci / build 等
• 其他：不归入以上分类的

给出各类占比估算（基于 message 数量），并列举 2-3 个典型 commit message 作为例证。

---

步骤 4 — 综合解读，生成报告

参照 references/report-template.md 的章节骨架，将以下数据整合为叙事化报告：

• 定量数据：code996 JSON 中的所有指标
• 定性数据：步骤 3 的加班语义分类
• 人均/贡献者对比：team.contributors[] 中各人加班占比，判断是否存在个别人被迫加班
• 用户口述背景：团队规模、是否弹性制、约定工时——用于校准「这算不算过度加班」的基准
• 多仓库视图：基于每个仓库独立 JSON 的 core、team 等字段进行横向对比（若适用）

报告风格：有结论（先给定性判断）、有数据支撑（引用具体数字）、有建议（可操作的改进方向）。

---

步骤 5 — 选择输出形态

若用户已在请求或对话中指明输出格式，直接执行；否则默认在对话中展示完整报告，不再追问。

• 直接展示：在对话中输出完整报告。
• 保存为 Markdown：将报告写入 ./code996-report-<日期>.md，日期格式 YYYY-MM-DD。
• 保存为 HTML：生成自包含 HTML（内联 CSS，无外部依赖）并写入 ./code996-report-<日期>.html。建议样式：白色背景、系统字体、最大宽度 800px、关键数字高亮显示。

---

注意事项

• 仅当 lateNight.midnightRate 为 0、weekdayOvertime 周一至周五的提交数合计为 0，且 weekendOvertime.realOvertimeDays 为 0 时，才跳过加班语义分析步骤，说明「未发现明显加班痕迹」。
• 若 team 字段为 null（如开源项目或 --skip-user-analysis），跳过贡献者对比章节。
• 仅分析一个仓库时跳过多仓库视图；分析多个仓库时使用各自的独立 JSON 聚合，不依赖 multiRepo 字段。
• 报告语言始终与对话语言一致，--lang 参数确保 code996 数据标签语言对齐。
• 不要把 schemaVersion 暴露给用户——这是供报告渲染器校验兼容性的内部版本标识。