菜单
Dibuja en ASCII el diagrama de secuencia y el diagrama de flujo de una parte del código que ya existe, para entender cómo funciona antes de modificarla. Úsala cuando el usuario quiera entender un flujo, función o feature existente, o antes de hacer scope sobre código heredado.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Revisa los cambios (el diff) como un ingeniero senior contra la spec, mirando alcance, correctitud, simplicidad y consistencia. Úsala antes de commitear o mergear, cuando se pida revisar el código o el diff.
Reviews the changes (the diff) as a senior engineer against the spec, looking at scope, correctness, simplicity and consistency. Use it before committing or merging, when a review of the code or the diff is requested.
Implements ONE single task from an existing spec, without touching anything else. Use it when a spec file exists in the specs folder and the user asks to run or implement a concrete task (for example T1 or T2).
Verifies that a task is actually done by running its Verify step and showing the real output, no self-reporting. Use it after implementing a task, when you want to confirm it truly works and not just that the agent claims so.
Turns a vague idea or feature into an executable spec using the 5 questions (context, goal, constraints, tasks and verification) before writing any code. Use it when the user describes something they want to build and asks for a spec, or to plan the work before implementing.
Writes the commit message for the staged changes, in conventional commits format and explaining the why. Use it when you want to commit or generate the commit message.
基于 SOC 职业分类
| name | trace |
| description | Dibuja en ASCII el diagrama de secuencia y el diagrama de flujo de una parte del código que ya existe, para entender cómo funciona antes de modificarla. Úsala cuando el usuario quiera entender un flujo, función o feature existente, o antes de hacer scope sobre código heredado. |
Lees el código que el usuario señala (una función, un endpoint, un feature) y reconstruyes su comportamiento real en dos diagramas ASCII. No inventas: lo que dibujas tiene que estar en el código. Si algo no se ve en el código (una rama que nunca se ejecuta, un caso que no se maneja), lo dices en vez de adivinarlo.
Pasos:
SECUENCIA. Por defecto la versión comprimida (lista ordenada); la completa con lifelines solo si el usuario la pide.
Comprimida (default):
SECUENCIA (orden temporal ↓)
1. Entrada → ComponenteA: llamada()
2. ComponenteA → ComponenteB: otra()
3. ComponenteB → ComponenteA: dato
4. ComponenteA → Entrada: respuesta
Completa (solo si la piden) — un lifeline vertical (│) por participante real, tiempo hacia ABAJO; llamadas flecha sólida (──▶), retornos punteada (◀ ─ ─):
Entrada ComponenteA ComponenteB
│ │ │
│ llamada() │ │
│─────────────▶│ │
│ │ otra() │
│ │─────────────▶│
│ │◀ ─ dato ─ ─ │
│◀─ respuesta ─│ │
▼ ▼ ▼
FLUJO (las decisiones y ramas reales del código):
entrada
│
▼
¿condición real? ──no──▶ rama que toma
│ sí
▼
acción ──▶ resultado
Cierra preguntando si el flujo dibujado es el que el usuario esperaba. Si no coincide, ya tienes el insumo para un scope de la corrección.