gener8v/gener8v.claude-skills.engineering

Comandos de desarrollo

1. Encontrar los comandos

Usa la primera fuente que responda. Indica el comando antes de ejecutarlo.

1. Instrucciones del repositorio: CLAUDE.md, CONTRIBUTING.md, README.md. En un repositorio de pipeline gener8v, .gener8v/context.md lista los comandos de verificación para cada repositorio.
2. Ejecutor de tareas: Makefile, justfile, Taskfile.yml, scripts de package.json, secciones de herramientas de pyproject.toml, tox.ini, noxfile.py.
3. Flujo de CI: .github/workflows/*.yml. Lo que ejecuta el CI define "las pruebas pasan".
4. Valor por defecto del ecosistema: resources/ecosystems.md.

Si el proyecto se ejecuta en contenedores (compose.yaml, docker-compose.yml, un dev container), ejecuta los comandos dentro del contenedor de la forma en que el proyecto lo documenta. Consulta resources/ecosystems.md.

2. Ejecutar

• Empieza de forma reducida: un archivo de prueba o un paquete. Luego ejecuta la suite completa antes de informar.
• No inicies el modo de observación. Muchos ejecutores de pruebas observan por defecto. Usa la forma de "ejecutar una vez" (resources/ecosystems.md).
• Conserva el código de salida cuando acortes la salida:

  set -o pipefail
  <comando> 2>&1 | tail -n 60
  echo "exit=$?"
  

• Inicia un servidor de desarrollo en segundo plano. Espera hasta que su URL responda. Detenlo cuando hayas terminado.

3. Leer el resultado

• El código de salida decide. Texto como "done" no significa éxito.
• Cuenta. Informa el número de pruebas pasadas, fallidas y omitidas. Las omitidas, las que se espera que fallen y "no se recogieron pruebas" no cuentan como pases.
• Pruebas inestables. Vuelve a ejecutar una prueba fallida una vez más, en solitario. Si pasa, repórtala como inestable. No la ocultes.
• Fallos que ya estaban antes. Verifica la rama base: la última ejecución de CI (gh run list --branch <base> --limit 3) o una ejecución en un árbol de trabajo separado. Informa estos fallos como "ya fallando en <base>". No los uses para excusar tus propios fallos.
• No debilites una prueba para que pase. Si la prueba es incorrecta, di por qué y cámbiala en un commit separado y visible.

4. Datos para trabajo de interfaz de usuario

Cuando la UI necesite datos realistas, sigue resources/throwaway-data.md. La regla breve: siembra solo una base de datos que hayas creado para este propósito. Nunca siembres la base de datos real, por defecto o compartida del proyecto.

5. Informar

Indica el comando, el código de salida, los conteos y el primer error real de cada fallo. Si no ejecutaste algo (por ejemplo, pruebas de extremo a extremo que necesitan credenciales), dilo.

Habilidades relacionadas

• engineering:github-pr-merge y engineering:github-issue-workflow llaman a esta habilidad antes de un PR.
• engineering:documentation-bootstrap la usa para encontrar los comandos que la documentación debe listar.