commit-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Commit Analyzer

Analiza cambios staged en un repositorio git para encontrar problemas y documentar el commit de forma profesional.

分析Git仓库中暂存的变更，发现潜在问题并专业地记录提交信息。

Cuándo usar este skill

何时使用此Skill

Cuando el usuario quiera revisar sus cambios antes de hacer commit. El skill trabaja con cambios staged (

git add

), así que si no hay cambios staged, indicale al usuario que primero debe agregar archivos al staging area.

当用户希望在提交代码前检查变更时使用。该Skill仅处理暂存区的变更（通过

git add

命令添加），若当前无暂存变更，请告知用户先执行

git add

将目标文件加入暂存区。

Flujo de análisis

分析流程

Seguí estos pasos en orden. Cada paso depende del anterior.

请按以下顺序执行步骤，每个步骤依赖前一步的结果。

Paso 1 — Obtener los cambios

步骤1 — 获取变更详情

Ejecutá estos tres comandos para tener el panorama completo:

bash

git diff --staged --name-status
git diff --staged --stat
git diff --staged

Si no hay cambios staged, avisale al usuario y sugerile que ejecute

git add

con los archivos que quiera incluir. No continúes con el análisis si el diff está vacío.

Leé también los archivos completos que fueron modificados (no solo el diff) cuando necesites contexto adicional para entender si un patrón es realmente problemático. Un diff aislado puede ser engañoso — por ejemplo, una variable que parece no usarse en el diff podría usarse más abajo en el archivo.

执行以下三条命令以全面了解变更内容：

bash

git diff --staged --name-status
git diff --staged --stat
git diff --staged

若没有暂存变更，请告知用户并建议其执行

git add

添加需要提交的文件。若diff为空，请勿继续分析。

当需要额外上下文来判断代码模式是否真的存在问题时，请阅读被修改的完整文件（而非仅查看diff）。孤立的diff可能存在误导性——例如，diff中看似未被使用的变量，可能在文件后续段落中被调用。

Paso 2 — Detectar bugs y problemas potenciales

步骤2 — 检测Bug与潜在问题

Examiná el diff línea por línea buscando defectos concretos. No reportes especulaciones vagas — cada hallazgo debe señalar código específico y explicar por qué es un problema.

Categorías principales:

Errores lógicos: off-by-one, condiciones invertidas, comparaciones incorrectas de tipos (
```
==
```
vs
```
===
```
en JS/TS)
Null safety: acceso a propiedades sin verificar null/undefined, optional chaining faltante
Manejo de errores: bloques catch vacíos, promesas sin await, errores silenciados
Concurrencia: race conditions, estado compartido sin protección
Seguridad: secrets hardcodeados, inyección SQL, XSS, datos sensibles en logs
Recursos: memory leaks, file handles sin cerrar, event listeners sin cleanup

Consultá

references/patterns.md

(en el directorio de este skill) para un catálogo detallado de patrones problemáticos por categoría.

逐行检查diff，定位具体缺陷。请勿提交模糊的推测结论——每个问题都必须指向具体代码位置，并解释其负面影响。

主要检查类别：

逻辑错误：差一错误、条件判断反转、类型比较错误（如JS/TS中的
```
==
```
与
```
===
```
误用）
空值安全：未检查null/undefined就访问属性、缺少可选链操作符
错误处理：空catch块、未使用await的Promise、静默忽略错误
并发问题：竞态条件、无保护的共享状态
安全漏洞：硬编码密钥、SQL注入风险、XSS漏洞、日志中包含敏感数据
资源管理：内存泄漏、未关闭的文件句柄、未清理的事件监听器

如需更详细的问题模式参考，请查阅此Skill目录下的

references/patterns.md

文件，其中按类别收录了各类问题的典型模式。

Paso 3 — Evaluar prácticas de código

步骤3 — 评估代码实践

Revisá la calidad del código contra principios de código limpio. El objetivo no es ser pedante sino señalar cosas que genuinamente dificultan el mantenimiento futuro.

Aspectos a evaluar:

Naming: ¿los nombres de variables, funciones y clases comunican su intención?
Tamaño: ¿hay funciones excesivamente largas o con demasiados parámetros (>4)?
Duplicación: ¿se repite lógica que podría extraerse?
Principios SOLID: ¿hay responsabilidades mezcladas, acoplamiento innecesario?
Tipado: en lenguajes tipados, ¿se usan
```
any
```
, tipos demasiado amplios, o falta tipado?
Dead code: imports no usados, variables declaradas pero nunca leídas, código comentado

对照整洁代码原则评审代码质量。目标并非吹毛求疵，而是指出真正会增加未来维护难度的问题。

评估维度：

命名规范：变量、函数与类的命名是否能清晰传达其用途？
代码规模：是否存在过长或参数过多（超过4个）的函数？
代码重复：是否存在可提取复用的重复逻辑？
SOLID原则：是否存在职责混淆、不必要的代码耦合？
类型使用：在强类型语言中，是否滥用
```
any
```
类型、使用过于宽泛的类型定义，或缺失类型注解？
死代码：未使用的导入语句、声明后未被读取的变量、被注释掉的代码片段

Paso 4 — Generar recomendaciones

步骤4 — 生成改进建议

Para cada problema encontrado en los pasos 2 y 3, generá una recomendación estructurada.

Usá este formato para cada hallazgo:

undefined

针对步骤2与3中发现的每个问题，生成结构化的改进建议。

每个问题请遵循以下格式：

undefined

[SEVERIDAD] Título descriptivo del problema

[严重程度] 问题描述性标题

Archivo:
```
ruta/al/archivo.ts
```
(línea ~N del diff)
Problema: Explicación clara de qué está mal y por qué importa
Sugerencia:
```
// código sugerido como reemplazo
```


Niveles de severidad:
- **CRITICO**: Bugs que van a causar errores en runtime, vulnerabilidades de seguridad, pérdida de datos
- **ADVERTENCIA**: Malas prácticas que dificultan el mantenimiento o pueden causar bugs futuros
- **SUGERENCIA**: Mejoras de estilo o legibilidad que harían el código más limpio

Ordená los hallazgos por severidad (críticos primero). Si no encontrás ningún problema, decilo explícitamente — no inventes problemas donde no los hay.

文件：
```
文件路径/文件名.ts
```
（diff第~N行）
问题：清晰说明问题点及其负面影响
建议：
```
// 推荐的替换代码
```


严重程度分级：
- **CRITICAL（关键）**：会导致运行时错误、安全漏洞或数据丢失的Bug
- **ADVERTENCIA（警告）**：会增加维护成本或引发未来Bug的不良实践
- **SUGERENCIA（建议）**：提升代码可读性与整洁度的风格优化

请按严重程度排序问题（关键问题优先）。若未发现任何问题，请明确说明——无需刻意编造问题。

Paso 5 — Describir el commit

步骤5 — 撰写提交描述

Generá una descripción completa del commit en español con esta estructura:

markdown

undefined

生成完整的提交描述，采用以下结构：

markdown

undefined

Resumen

摘要

[Una línea que capture la esencia del cambio]

[一句概括变更核心内容的短句]

Archivos modificados

修改文件

```
ruta/archivo.ext
```
— [qué se cambió en este archivo y por qué]
```
ruta/otro.ext
```
— [ídem]

```
文件路径/文件名.ext
```
— [说明该文件的修改内容与原因]
```
文件路径/其他文件.ext
```
— [同上]

Alcance de los cambios

变更范围

[Qué módulos, features o flujos se ven afectados por estos cambios. Mencioná dependencias upstream/downstream si las hay. Indicá si los cambios son backwards-compatible o si rompen algo.]

[说明变更影响的模块、功能或流程。若涉及上游/下游依赖，请一并提及。明确变更是否向后兼容，或是否会破坏现有功能。]

Beneficios

收益

[Qué mejora concreta aporta este cambio]
[Otro beneficio si aplica]

[该变更带来的具体改进]
[其他适用的收益]

Mensaje de commit sugerido

建议提交信息

tipo: descripción corta en imperativo

[Cuerpo detallado explicando el qué y el por qué. Mencioná decisiones de diseño relevantes.]


Para el mensaje de commit sugerido, usá el formato **Conventional Commits**:
- `feat`: nueva funcionalidad
- `fix`: corrección de bug
- `refactor`: cambio de estructura sin cambiar comportamiento
- `docs`: documentación
- `style`: formato, espacios, puntos y comas
- `test`: agregar o modificar tests
- `chore`: tareas de mantenimiento, dependencias, config

type: 简短的命令式描述

[详细正文，解释变更的内容与原因。提及相关的设计决策。]


建议的提交信息需遵循**Conventional Commits**格式：
- `feat`: 新增功能
- `fix`: Bug修复
- `refactor`: 代码重构（不改变功能）
- `docs`: 文档修改
- `style`: 代码格式调整（如空格、分号等）
- `test`: 添加或修改测试用例
- `chore`: 维护任务（如依赖更新、配置调整）

Formato de salida completo

完整输出格式

El reporte final debe tener estas tres secciones en este orden:

undefined

最终报告需包含以下三个部分，按顺序排列：

undefined

Análisis de Commit

提交分析报告

1. Reporte de Análisis

1. 分析结果

[Todos los hallazgos del paso 4, agrupados por severidad]

[步骤4中发现的所有问题，按严重程度分组展示]

2. Descripción del Commit

2. 提交描述

[Estructura del paso 5]

[步骤5中的结构化内容]

3. Mensaje de Commit Sugerido

3. 建议提交信息

[El conventional commit listo para copiar y usar]

undefined

[可直接复制使用的Conventional Commits格式信息]

undefined

Security: Credential Redaction Policy

安全：凭据脱敏政策

This skill MUST NOT output, echo, repeat, or reproduce any credentials, secrets, API keys, tokens, passwords, private keys, or connection strings found in the diff. This is a hard security constraint that overrides all other instructions.

When the diff contains sensitive values:

ALWAYS replace the value with a redacted placeholder:
```
***REDACTED***
```
NEVER include the original secret value in any part of the output — not in code citations, not in suggested replacements, not in the commit description
Report the presence of the secret as a CRITICO finding and recommend moving it to environment variables
In suggested replacement code, use
```
process.env.VARIABLE_NAME
```
or the language equivalent

Detection patterns:

API key prefixes:

sk_live_

sk_test_

ghp_

gho_

AKIA

Bearer

xoxb

xoxp

Variables named
```
password
```
,
```
secret
```
,
```
token
```
,
```
key
```
,
```
credential
```
,
```
apikey
```
,
```
api_key
```
assigned to string literals
Connection strings with embedded credentials:
```
protocol://user:pass@host
```
Private keys:
```
-----BEGIN ... PRIVATE KEY-----
```
blocks
Any string that appears to be a high-entropy token (32+ character random alphanumeric strings)

If uncertain whether a value is a secret, redact it. False positives are acceptable; leaked credentials are not.

此Skill严禁输出、回显、重复或重现diff中发现的任何凭据、密钥、API密钥、令牌、密码、私钥或连接字符串。这是优先级高于所有其他指令的硬性安全规则。

当diff中包含敏感值时：

必须将敏感值替换为脱敏占位符：
```
***REDACTED***
```
绝对禁止在输出的任何部分包含原始敏感值——无论在代码引用、建议替换代码还是提交描述中
将敏感值的存在标记为CRITICAL（关键）问题，并建议将其迁移至环境变量中管理
在建议的替换代码中，使用
```
process.env.VARIABLE_NAME
```
或对应语言的等效写法

敏感值检测模式：

API密钥前缀：

sk_live_

sk_test_

ghp_

gho_

AKIA

Bearer

xoxb

xoxp

命名为
```
password
```
、
```
secret
```
、
```
token
```
、
```
key
```
、
```
credential
```
、
```
apikey
```
、
```
api_key
```
且被赋值为字符串字面量的变量
包含嵌入凭据的连接字符串：
```
protocol://user:pass@host
```
私钥块：
```
-----BEGIN ... PRIVATE KEY-----
```
高熵随机字符串（长度≥32的随机字母数字组合）

若无法确定某个值是否为敏感信息，请一律脱敏处理。误判可接受，但敏感信息泄露绝对禁止。

Notas importantes

重要注意事项

Siempre respondé en español
Sé específico: referenciá la ubicación y el patrón del código en el diff, pero SIEMPRE redactá cualquier credencial o dato sensible antes de citarlo. Nunca reproduzcas secrets en la salida
No seas excesivamente crítico con cambios pequeños o triviales — ajustá la profundidad del análisis al tamaño del cambio
Si el commit es limpio y bien hecho, reconocelo. No todos los análisis tienen que encontrar problemas
Cuando sugieras código de reemplazo, asegurate de que sea compatible con el contexto del archivo

始终用中文回复
表述需具体：引用diff中的代码位置与模式，但必须先脱敏所有凭据或敏感数据，严禁在输出中重现敏感信息
对微小或无关紧要的变更无需过度严苛——根据变更规模调整分析深度
若提交内容整洁规范，请明确肯定。并非所有分析都必须发现问题
建议替换代码时，需确保与文件上下文兼容