基于Git历史的个人代码行为自查与团队复盘工具，强调知情同意与非惩罚性使用，禁止用于绩效评估或员工监控。
说明：
## 核心用法
**Git-History Reflection Skill** 是一款专注于Git提交历史描述性分析的本地化工具，支持开发者进行个人代码行为反思或经全员知情同意的团队复盘。
### 主要功能维度
– **提交模式分析**：频率、消息长度、合并比例、Conventional Commits合规性
– **工作时间分布**：活跃时段、周末/深夜提交比例、连续提交 streak
– **变更指标**：代码流失率、返工比例、单次提交行数、代码所有权
– **代码质量痕迹**：Bug修复比例、回退比例、测试文件变更、复杂度（Python）
– **节奏密度信号**：活动集中程度描述（非评分）
### 强制安全机制
1. **硬门槛验证**：必须显式传入 `–i-have-consent` 或 `acknowledge_usage_policy: true`，无环境变量绕过
2. **默认自分析**：仅分析当前本地Git用户，分析他人需双重确认（`–multi-author-team-retro` + `–consented-author NAME`）
3. **输出限制**：禁止生成排行榜、交叉对比表、0-100综合评分、字母等级或”判决书”式结论
### 输出格式
支持 Markdown / HTML / JSON / PDF，每份报告开头附带使用声明，强调”数字描述Git历史而非个人”。
—
## 显著优点
| 优势 | 说明 |
|——|——|
| **伦理设计优先** | 从架构层面禁止常见的滥用场景（绩效评估、排名、监控），而非仅靠文档约束 |
| **强同意机制** | 多作者分析需逐个列明同意人员，无法泛化授权 |
| **本地化执行** | 零网络传输，敏感数据不出本地环境 |
| **去评分化输出** | 仅提供描述性指标与反思提示，拒绝简化为单一数字 |
| **多维度反思框架** | 区分”可见的Git活动”与”不可见的贡献”（评审、设计、值班等） |
—
## 潜在缺点与局限性
| 局限 | 影响 |
|——|——|
| **数据盲区严重** | 代码评审、架构设计、技术辅导、运维值班等关键贡献完全不可见 |
| **时间指标易失真** | 时区差异、批量推送、squash合并、定时任务均会扭曲”工作时间”读数 |
| **仅支持Python复杂度** | 依赖 `radon`，其他语言无原生代码质量指标 |
| **大型仓库性能** | 10万+提交仓库分析耗时较长，需手动限定日期范围 |
| **主观解读风险** | 即使工具禁止评分，用户仍可能将”稀疏节奏”误解为”懈怠” |
| **依赖用户自律** | 技术机制无法完全阻止用户截图传播或人工制作排名表 |
—
## 适合人群
– **个人开发者**：希望系统性回顾自己的编码习惯与提交模式
– **技术团队Leader**：在全员自愿前提下，组织季度代码实践复盘
– **开源维护者**：分析公共仓库的贡献分布（已公开数据）
– **研究人员**：在符合数据保护条款下研究开源协作模式
—
## 常规风险
| 风险场景 | 防护措施 |
|———-|———-|
| 未经同意分析同事 | 硬门槛拒绝执行，需显式列明每位同意者 |
| 用于绩效/晋升决策 | 文档明确禁止，输出格式不支持生成”成绩单” |
| 员工 surveillance | 默认自分析模式，多作者模式需双重确认 |
| 数据泄露 | 本地执行无网络传输，但用户需自行保管生成的PDF/HTML报告 |
| GDPR/劳动法合规 | 用户责任自负，工具提供合规检查清单但未内置法务验证 |
### 关键使用原则
> “稀疏的节奏不代表懈怠，密集的活动不代表高效——Git历史只是开发工作的一个狭窄、有偏的切片。”
会员专属
