Una tabla README debe ayudar a responder una pregunta concreta: ¿qué paquete instalo?, ¿qué función está disponible?, ¿qué entorno pasó las pruebas? Resulta contraproducente cuando sustituye al diseño de toda la página o contiene párrafos que no caben en una pantalla pequeña.
Asigna una función a cada columna
Usa encabezados breves y concretos:
| Paquete | Entorno | Estado |
| :--- | :---: | :---: |
| `core` | Node 22 | Estable |
| `cli` | Node 22 | Beta |Los nombres se alinean a la izquierda, los campos compactos pueden centrarse y los resultados numéricos suelen alinearse a la derecha. Deja fuera de la tabla las descripciones que necesiten varias frases.
Prefiere enlaces con etiquetas significativas
Evita URL largas dentro de las celdas. [Referencia de API](./docs/api.md) mantiene la columna compacta y describe el destino a usuarios de lectores de pantalla. Las insignias son imágenes y generan ruido visual; resérvalas para unas pocas señales actualizadas continuamente y proporciona texto alternativo útil.
Optimiza para la revisión del código
Quien revisa un pull request observa tanto la tabla renderizada como el diff. Mantén un registro por línea y evita alinear manualmente cientos de espacios. Si la matriz se genera, incluye el script o archivo fuente para poder rastrear los valores.
Comprueba pantallas estrechas
Una tabla ancha puede desplazarse horizontalmente, pero el lector pierde el contexto de la fila. Coloca primero la columna identificadora, limita el número de columnas y separa dimensiones no relacionadas. Una fila mucho más larga que las demás probablemente merece una sección propia.
Mantén las afirmaciones actualizadas
Las matrices de funciones envejecen rápido. Actualiza el README en el mismo pull request que cambia la compatibilidad, no en una futura revisión documental.
Crea y alinea el código con el generador de tablas Markdown y verifica el resultado final en una rama antes de fusionar.