Aither (Español)

Primeros pasos con Astro-Theme-Aither

Sat, 14 Mar 2026 08:00:00 GMT

Esta guía te lleva desde cero hasta un blog multilingüe desplegado. Puedes leerla completa o saltar directamente a la sección que necesites. ## Requisitos previos - [Node.js](https://nodejs.org/) 22 LTS o superior - [pnpm](https://pnpm.io/) 10 o superior - Una cuenta de GitHub - Una cuenta de [Cloudflare](https://cloudflare.com/) para el despliegue ## Instalación ```bash git clone https://github.com/YOUR_USERNAME/YOUR_REPO.git cd YOUR_REPO corepack enable pnpm install pnpm validate pnpm dev ``` Luego abre `http://localhost:4321` en tu navegador. ## Estructura del proyecto ```text src/ ├── components/ # Componentes Astro y React ├── config/site.ts # Nombre del sitio, navegación, pie de página y redes ├── content/posts/ # Artículos organizados por locale ├── i18n/ # Traducciones de la interfaz ├── layouts/ # Layouts ├── lib/ # Utilidades ├── pages/ # Rutas y páginas └── styles/global.css # Tokens de tema en Tailwind v4 ``` ## Configuración ### Site Config `src/config/site.ts` es la fuente única de configuración del sitio: ```typescript export const siteConfig = { name: 'El nombre de tu blog', title: 'Tu eslogan', description: 'Tu descripción SEO', author: { name: 'Tu nombre', avatar: '', }, }; ``` Elementos clave: | Sección | Qué controla | |--------|---------------| | `name` | Título del sitio en navbar y footer | | `social` | Enlaces sociales del footer | | `nav` | Elementos de la navegación principal | | `footer.sections` | Columnas de enlaces en el pie | | `ui.defaultMode` | Modo por defecto: `light`, `dark` o `system` | | `ui.defaultStyle` | Estilo por defecto como `default` o `evolution` | | `ui.showMoreThemesMenu` | Muestra u oculta `More Themes` | | `blog.paginationSize` | Artículos por página | | `sections` | Colecciones de contenido personalizadas | ### Variables de entorno ```bash cp .env.example .env ``` Si una variable queda vacía, esa integración se desactiva sin tocar código. ### URL del sitio La URL de producción se configura en `astro.config.mjs`: ```javascript import { defineConfig } from 'astro/config'; import aither from '@aither/astro'; export default defineConfig({ site: 'https://your-domain.pages.dev', integrations: [aither()], }); ``` ## Escribir artículos Crea un archivo `.mdx` en `src/content/posts/en/`: ```markdown --- title: Mi primer artículo date: "2026-03-14T16:00:00+08:00" category: General description: Resumen breve para SEO y vistas previas sociales. tags: [Topic, Another] pinned: false --- Tu contenido empieza aquí. ``` ### Referencia de frontmatter | Campo | Tipo | Requerido | Descripción | |------|------|-----------|-------------| | `title` | string | Sí | Título del artículo | | `date` | date | Sí | Fecha y hora de publicación (ej. `2026-03-14T16:00:00+08:00`) | | `category` | string | No | Categoría | | `description` | string | No | Descripción SEO | | `tags` | string[] | No | Lista de etiquetas | | `pinned` | boolean | No | Fijar al principio | | `image` | string | No | Imagen de portada | ### Componentes MDX Puedes importar componentes dentro del contenido: ```mdx import MyChart from '@/components/MyChart' ``` ## Internacionalización El tema soporta 11 idiomas listos para usar. Para traducir un artículo, crea el mismo nombre de archivo en otra carpeta de locale: ```text src/content/posts/en/my-post.mdx src/content/posts/es/my-post.mdx src/content/posts/zh-hans/my-post.mdx ``` Los textos de la interfaz están en `src/i18n/messages/`. ## Secciones de contenido personalizadas Puedes añadir colecciones como traducciones, notas o tutoriales registrándolas en `src/content.config.ts` y `src/config/site.ts`. Después, las páginas de listado y detalle se generan automáticamente. ## Theming El sistema se divide en dos capas: - Modo de color: `light`, `dark`, `system` - Estilo del tema: `default` o estilos integrados como `evolution` Configuración en `src/config/site.ts`: ```typescript ui: { defaultMode: 'system', defaultStyle: 'default', showMoreThemesMenu: true, }, ``` Los colores viven en `src/styles/global.css`. La tipografía base usa una pila sans-serif del sistema; las zonas de código usan una fuente monoespaciada. ## SEO y AI Cada página ya expone estas salidas útiles: - `/sitemap-index.xml` - `/rss.xml` - `/robots.txt` - `/llms.txt` - `/llms-full.txt` - `/posts/slug.md` - JSON-LD y Open Graph ## Despliegue ### Cloudflare Pages Como buena práctica, crea primero el proyecto de Pages. El flujo usa el nombre del repositorio por defecto, o `CLOUDFLARE_PAGES_PROJECT_NAME` si necesitas sobrescribirlo. Configura estos secretos en GitHub: - `CLOUDFLARE_API_TOKEN` - `CLOUDFLARE_ACCOUNT_ID` Después ejecuta `pnpm validate` y haz push a `main`. ## Comandos útiles | Comando | Descripción | |--------|-------------| | `pnpm dev` | Inicia el servidor de desarrollo | | `pnpm validate` | Ejecuta la validación completa antes de hacer push | | `pnpm build` | Genera la build de producción | | `pnpm preview` | Previsualiza la build localmente | ## Esquema de versiones Los tags de release públicos siguen nombres estilo CalVer, por ejemplo `v2026.04.08`.

Buenas prácticas para agentes de IA en proyectos reales (Ejemplo)

Sat, 10 Jan 2026 08:00:00 GMT

Los agentes de IA son más útiles cuando dejan de sentirse mágicos y empiezan a comportarse como una herramienta operativa. Los equipos que obtienen mejores resultados no le piden a un agente que "se encargue de todo". Definen el trabajo, proporcionan el contexto correcto y hacen que el resultado sea fácil de verificar. Suena sencillo, pero cambia por completo la calidad del resultado. Un agente bien guiado puede avanzar rápido y producir trabajo sorprendentemente sólido. Un agente mal acotado desperdicia contexto, toma desvíos innecesarios y devuelve algo que suena seguro, pero no resuelve la tarea real. ## Empieza con una tarea acotada Las mejores tareas para un agente son concretas y limitadas. En lugar de decir "mejora esta aplicación", di "corrige la superposición de la navegación móvil en la página del blog" o "añade una prueba rápida para el feed RSS". Una tarea estrecha le da al agente un objetivo estable y reduce la probabilidad de que modifique partes no relacionadas del sistema. Eso también facilita la revisión. Cuando la tarea es pequeña, es más evidente qué cambió, qué debe probarse y si el resultado es realmente correcto. ## Haz explícito el contexto Los agentes trabajan mejor cuando el contexto importante está escrito y no solo implícito. Un buen encargo inicial suele incluir: - el objetivo exacto - los archivos o directorios relevantes - las restricciones y lo que no debe cambiar - el resultado esperado o definición de hecho - el comando de validación que debe ejecutarse al final Las personas pueden inferir mucho a partir de instrucciones incompletas. Los agentes son más literales. Si un detalle importa, escríbelo. ## Mejor herramientas que adivinanzas Un agente debería inspeccionar el sistema actual antes de proponer cambios. Eso significa leer los archivos relevantes, revisar la configuración de build y entender las convenciones existentes, en lugar de apoyarse solo en conocimiento genérico. La misma regla aplica a sistemas externos. Si la respuesta depende de documentación actual, configuración de despliegue o comportamiento real en producción, el agente debería usar herramientas para verificar el estado real, no adivinar desde memoria. Por eso importan tanto las interfaces legibles por máquina. Una estructura de archivos clara, scripts de validación, esquemas tipados y configuración explícita hacen a los agentes más fiables porque el entorno se explica a sí mismo. ## Haz que el resultado sea verificable Un buen flujo de trabajo con agentes no termina con "aquí está la respuesta". Termina con evidencia. Pídele al agente que informe qué cambió, qué probó y qué no pudo verificar. Prefiere resultados que se puedan comprobar rápidamente: - un diff pequeño - un comando de validación que pase - una captura o vista previa reproducible - una nota breve sobre riesgos o supuestos La verificación convierte un resultado plausible en uno confiable. ## Diseña para recuperarte rápido Incluso los buenos agentes toman caminos equivocados. La respuesta correcta no es evitarlos, sino hacer barata la recuperación. Usa tareas pequeñas, scripts estables y puntos de control. Mantén las operaciones idempotentes siempre que sea posible. Evita flujos de trabajo en los que un solo paso erróneo deje un gran desastre detrás. Si una tarea puede dividirse en leer, planificar, implementar y verificar, hazlo. Los agentes rinden mejor en sistemas que son fáciles de inspeccionar, fáciles de probar y fáciles de seguir mejorando. ## La revision humana sigue importando Los agentes son excelentes para velocidad, cobertura y repetición. Las personas siguen siendo responsables del juicio. Las decisiones de producto, los límites de seguridad, el tono, la marca y la mantenibilidad a largo plazo deberían seguir siendo revisados por alguien que entienda el contexto completo. El objetivo no es sacar a los humanos del circuito. El objetivo es que dediquen menos tiempo al trabajo mecánico y más a las decisiones que realmente requieren criterio y responsabilidad. ## Un modelo mental útil Piensa en un agente de IA como en un operador capaz, rápido, incansable y literal. Dale una tarea clara. Dale las herramientas adecuadas. Pídele que muestre su trabajo. Después revisa el resultado con la misma disciplina que aplicarías a cualquier cambio importante. Ahí es donde aparece el verdadero apalancamiento.

Agentes de IA y uso de herramientas (Ejemplo)

Fri, 09 Jan 2026 08:00:00 GMT

Un agente de IA es un modelo de lenguaje que puede realizar acciones, no solo generar texto. Puede buscar en la web, ejecutar codigo, llamar APIs, leer archivos y tomar decisiones sobre que hacer a continuacion. Este cambio de la generacion pasiva de texto a la resolucion activa de problemas representa uno de los desarrollos mas significativos en la IA aplicada. ## Del chat a la accion Un chatbot responde preguntas. Un agente resuelve problemas. La diferencia es la autonomia: los agentes deciden que herramientas usar, en que orden y como manejar los errores. Consideremos la diferencia en la practica. Le preguntas a un chatbot: "Como esta el clima en Tokio?" Podria responder basandose en sus datos de entrenamiento, que tienen meses o anios de antiguedad y casi con seguridad estan equivocados. Le haces la misma pregunta a un agente, y este llama a una API meteorologica, obtiene los datos actuales y devuelve una respuesta precisa y actualizada. El chatbot genera texto plausible. El agente interactua con el mundo. ### El espectro de la autonomia No todos los agentes son igualmente autonomos. Existe un espectro: 1. **Chat asistida por herramientas** — el modelo puede llamar herramientas, pero solo en respuesta directa a solicitudes del usuario. Una llamada de herramienta por turno. 2. **Agentes multi-paso** — el modelo puede encadenar multiples llamadas de herramientas para cumplir una tarea, decidiendo la secuencia por si mismo. 3. **Agentes completamente autonomos** — el modelo opera independientemente durante periodos prolongados, tomando decisiones, manejando errores y persiguiendo objetivos con minima supervision humana. La mayoria de los sistemas en produccion hoy se encuentran en los niveles 1-2. Los agentes completamente autonomos son un area de investigacion activa con desafios de seguridad significativos aun por resolver. ## Uso de herramientas El uso de herramientas permite que un modelo de IA llame funciones externas. El modelo decide cuando una herramienta es necesaria, genera los parametros correctos e incorpora el resultado en su respuesta. Esto convierte un generador de texto en un asistente capaz. ### Como funciona el uso de herramientas La mecanica es directa: 1. **Definicion de herramienta** — describes las herramientas disponibles al modelo, incluyendo sus nombres, parametros y lo que hacen. Tipicamente se proporciona como JSON estructurado en el prompt del sistema o mediante un campo API dedicado. 2. **Decision** — al procesar una solicitud del usuario, el modelo decide si una herramienta seria util. De ser asi, genera una llamada con los parametros apropiados. 3. **Ejecucion** — tu aplicacion ejecuta la llamada (el modelo no la ejecuta directamente) y devuelve el resultado. 4. **Integracion** — el modelo incorpora el resultado de la herramienta en su respuesta al usuario. ### Ejemplo de definicion de herramienta ```json { "name": "search_documentation", "description": "Search the product documentation for relevant articles", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "The search query" }, "max_results": { "type": "integer", "description": "Maximum number of results to return", "default": 5 } }, "required": ["query"] } } ``` El modelo ve esta definicion y sabe que puede buscar en la documentacion. Cuando un usuario hace una pregunta sobre el producto, el modelo genera una llamada como `search_documentation(query="como restablecer la contrasenia")`, tu sistema ejecuta la busqueda y el modelo usa los resultados para componer una respuesta precisa. ### Categorias comunes de herramientas Los sistemas de agentes en produccion tipicamente ofrecen herramientas en varias categorias: - **Recuperacion de informacion** — busqueda web, consultas a bases de datos, lectura de archivos, llamadas API - **Ejecucion de codigo** — ejecutar Python, JavaScript o comandos shell en un entorno sandbox - **Comunicacion** — enviar correos, publicar mensajes, crear tickets - **Manipulacion de archivos** — crear, editar y organizar archivos - **Operaciones del sistema** — desplegar codigo, gestionar infraestructura, ejecutar pipelines de CI Las herramientas que proporcionas definen los limites de lo que el agente puede hacer. Un conjunto de herramientas bien disenado le da al agente suficiente capacidad para ser util sin suficiente poder para ser peligroso. ## Loops agentivos El patron mas poderoso es el loop agentivo: el modelo planifica un paso, lo ejecuta, observa el resultado y decide el siguiente paso. Este ciclo continua hasta que la tarea se completa o el modelo determina que no puede continuar. ### El loop en la practica Consideremos un agente encargado de depurar un test que falla: 1. **Planifica** — "Deberia primero leer el archivo de test para entender que esta probando" 2. **Ejecuta** — llama a `read_file("tests/auth.test.ts")` 3. **Observa** — ve que el test espera un estado 200 pero recibe 401 4. **Planifica** — "Deberia revisar el middleware de autenticacion para ver que devuelve 401" 5. **Ejecuta** — llama a `read_file("src/middleware/auth.ts")` 6. **Observa** — encuentra que la logica de validacion del token tiene un bug en la verificacion de expiracion 7. **Planifica** — "Deberia corregir la comparacion de expiracion" 8. **Ejecuta** — llama a `edit_file(...)` con la correccion 9. **Observa** — confirma que la edicion fue realizada 10. **Planifica** — "Deberia ejecutar el test para verificar la correccion" 11. **Ejecuta** — llama a `run_command("pnpm test tests/auth.test.ts")` 12. **Observa** — el test pasa 13. **Completa** — reporta la correccion al usuario Cada paso implica que el modelo razona sobre el estado actual, decide que hacer a continuacion y se adapta segun lo que descubre. Esto es fundamentalmente diferente de un script lineal: el agente maneja descubrimientos inesperados y cambia de rumbo cuando es necesario. ### Manejo de errores en el loop Los agentes robustos deben manejar los fallos con elegancia. Una herramienta podria devolver un error, un archivo podria no existir o una API podria estar limitada por tasa. Un buen diseno de agentes incluye: - **Logica de reintento** — reintentar fallos transitorios con backoff - **Estrategias alternativas** — si un enfoque falla, intentar otro - **Degradacion gradual** — si la tarea no puede completarse totalmente, completar lo mas posible y explicar que queda pendiente - **Limites del loop** — establecer un numero maximo de iteraciones para prevenir loops infinitos cuando el agente se queda atascado ## Disenando herramientas efectivas La calidad de un sistema de agentes depende en gran medida de la calidad de sus herramientas. Herramientas mal disenadas llevan a agentes confundidos y resultados incorrectos. ### Principios de diseno de herramientas - **Nombres claros** — `search_users` es mejor que `query_db_1`. El modelo usa el nombre para decidir cuando llamar a la herramienta. - **Parametros descriptivos** — incluir descripciones para cada parametro. El modelo lee estas descripciones para determinar que valores pasar. - **Alcance enfocado** — cada herramienta deberia hacer una cosa bien. Una herramienta `read_file` y una `write_file` son mejores que una herramienta `file_operations` con un parametro de modo. - **Errores utiles** — devolver mensajes de error claros que ayuden al modelo a entender que salio mal y que intentar en su lugar. - **Idempotentes cuando sea posible** — herramientas que pueden reintentarse de forma segura simplifican el manejo de errores. ## Riesgos Los agentes que pueden tomar acciones pueden tomar acciones equivocadas. El sandboxing, los pasos de confirmacion y las revisiones human-in-the-loop son medidas de seguridad esenciales para cualquier sistema de agentes en produccion. ### Categorias de riesgo - **Acciones destructivas** — un agente con acceso al sistema de archivos podria eliminar archivos importantes. Un agente con acceso a la base de datos podria eliminar tablas. Los entornos sandbox y los limites de permisos son esenciales. - **Exfiltracion de datos** — un agente que puede leer datos sensibles y hacer solicitudes de red podria inadvertidamente (o mediante inyeccion de prompt) filtrar informacion. - **Costos desbocados** — un agente en un loop llamando APIs costosas puede acumular costos significativos rapidamente. Los limites de presupuesto y el rate limiting son necesidades practicas. - **Acciones incorrectas tomadas con confianza** — el agente podria malinterpretar una solicitud y tomar una accion irreversible. Para operaciones de alto riesgo, siempre requiere confirmacion humana. ### Patrones de seguridad Los sistemas de agentes en produccion deberian implementar varios patrones de seguridad: 1. **Privilegio minimo** — dar al agente solo las herramientas que necesita para su tarea especifica, nada mas 2. **Sandboxing** — ejecutar codigo y operaciones de archivos en entornos aislados 3. **Puertas de confirmacion** — requerir aprobacion humana para acciones destructivas o irreversibles 4. **Registro de auditoria** — registrar cada llamada de herramienta y su resultado para revision 5. **Interruptores de emergencia** — proporcionar mecanismos para detener inmediatamente un agente en ejecucion 6. **Limites de presupuesto** — establecer topes estrictos en llamadas API, uso de tokens y tiempo de computo El objetivo no es impedir que los agentes sean utiles, sino asegurar que sean utiles dentro de limites bien definidos.

✨ Por que Astro-Theme-Aither

Sat, 03 Jan 2026 08:00:00 GMT

Un tema Astro nativo para IA que cree que el texto en si mismo es hermoso. Astro-Theme-Aither esta construido para lectores que vienen por las palabras, no por la decoracion. ## Filosofia de diseno La mayoria de los temas de blog compiten por atencion con imagenes destacadas, animaciones, barras laterales y ventanas emergentes. Ninguno de estos ayuda a leer — ayudan a mirar, que es una actividad completamente diferente. Astro-Theme-Aither toma el enfoque opuesto: diseno minimal, no ingenieria minimal. Cuando no hay visuales llamativos que distraigan de los problemas, cada defecto tipografico, cada retraso de carga, cada tropiezo en la interaccion se amplifica. El diseno minimal exige mayor calidad de ingenieria, no menor. ## Tipografia La tipografia es la identidad visual. Cada pagina usa un stack de fuentes sans-serif de sistema unificado — limpio, rapido y consistente en todas las plataformas. Los parametros tipograficos siguen las Apple Human Interface Guidelines: - **Tamano de fuente** — 17px base, el punto ideal para lectura comoda en pantalla - **Altura de linea** — 1.47, dando a cada linea espacio para respirar sin romper el flujo de lectura - **Espaciado de letras** — -0.022em, ajuste sutil que hace el texto del cuerpo mas pulido - **Escala de encabezados** — 31px → 22px → 19px → 17px, jerarquia clara sin extremos de tamano - **Ancho de lectura** — restringido a 65-75 caracteres por linea, donde el ojo sigue con mayor comodidad Estas son practicas basadas en evidencia extraidas de decadas de investigacion sobre legibilidad en pantalla y los estandares tipograficos de Apple. ## Construido sobre Astro Astro es el mejor framework para sitios orientados al contenido hoy. Produce HTML estatico por defecto — sin JavaScript del lado del cliente a menos que optes explicitamente. La arquitectura de islas significa que los componentes interactivos se hidratan independientemente mientras el resto de la pagina permanece estatico. En Astro-Theme-Aither, las islas interactivas son minimas: - **Selector de tema** — toggle Claro / Oscuro / Sistema con animacion de revelacion circular via View Transitions API - **Selector de idioma** — cambio de locale sin interrupciones con persistencia localStorage - **Deteccion de locale** — detecta automaticamente el idioma del navegador y sugiere el cambio - **Navegacion movil** — menu hamburguesa responsive Todo lo demas es HTML y CSS puro, cargado instantaneamente. ## Caracteristicas - **Tailwind CSS v4** — tokens de diseno `@theme` con personalizacion completa de paleta claro/oscuro - **Tipografia Apple HIG** — parametros de texto del cuerpo 17px / 1.47 / -0.022em - **View Transitions API** — animacion de revelacion circular para cambio de tema - **i18n** — soporte multilingue con deteccion automatica del idioma del navegador - **Fijado de posts** — fija posts importantes en la parte superior de la lista - **Content Collections** — Markdown type-safe con validacion de frontmatter en tiempo de build - **Modo oscuro** — Claro / Oscuro / Sistema con persistencia localStorage - **SEO** — Open Graph, URLs canonicas, meta descriptions por post - **RSS + Sitemap** — auto-generados, cero configuracion - **Google Analytics** — opcional, ejecutado en un Partytown Web Worker - **Testing** — tests unitarios Vitest + E2E Playwright, integrados en CI - **Cloudflare Pages** — flujo de despliegue con URLs de vista previa para PRs ## Para quien es esto Si crees que la buena escritura habla por si misma y quieres un tema que respete esa creencia: - **Bloggers personales** que quieren su escritura en primer plano - **Escritores tecnicos** que necesitan excelente renderizado de bloques de codigo y formato claro de prosa - **Autores multilingues** que necesitan i18n integrado con deteccion automatica del idioma del navegador - **Desarrolladores** que aprecian un codebase bien disenado que pueden extender con confianza Escribe sobre cualquier cosa — la tipografia lo hara lucir bien.

📝 Guia de estilo Markdown

Fri, 02 Jan 2026 08:00:00 GMT

Este post demuestra cada funcionalidad Markdown soportada por Astro-Theme-Aither. Usalo como referencia cuando escribas tus propios posts. Guarda esta pagina en favoritos — cubre la gama completa de opciones de formato disponibles. ## Encabezados Usa `##` para encabezados de seccion, `###` para subsecciones y `####` para sub-subsecciones. Evita `#` en el contenido del post — el titulo del post ya se renderiza como el encabezado de nivel superior. ### Encabezado de tercer nivel Los encabezados de tercer nivel son ideales para dividir una seccion en temas distintos. Crean jerarquia visual sin ser demasiado prominentes. #### Encabezado de cuarto nivel Los encabezados de cuarto nivel funcionan para subsecciones detalladas. Usalos con moderacion — si tu esquema va mas alla de cuatro niveles, considera reestructurar tu contenido. ### Mejores practicas para encabezados Algunas pautas para el uso efectivo de encabezados: - **No saltes niveles** — ve de `##` a `###`, nunca de `##` directamente a `####`. Saltar niveles rompe el esquema del documento y puede confundir a los lectores de pantalla. - **Manten los encabezados descriptivos** — "Configuracion" es mejor que "Cosas de setup." Los lectores escanean los encabezados antes de decidir si leer una seccion. - **Usa sentence case** — capitaliza solo la primera palabra y los nombres propios. ## Parrafos y saltos de linea El texto de los parrafos regulares fluye naturalmente. Deja una linea en blanco entre parrafos para separarlos. Este es un segundo parrafo. Manten los parrafos enfocados en una idea para la mejor experiencia de lectura. Cuando escribes para la web, parrafos mas cortos tienden a funcionar mejor que bloques largos de texto. Un parrafo de tres a cinco oraciones es una unidad de lectura comoda en pantallas. Si un parrafo supera las seis o siete oraciones, considera dividirlo. Los saltos de linea simples dentro de un parrafo (sin linea en blanco) se trataran como un espacio, no como una nueva linea. Si necesitas un salto de linea forzado sin iniciar un nuevo parrafo, termina la linea con dos espacios o usa una etiqueta `
` — aunque en la practica rara vez es necesario. ## Enfasis - **Texto en negrita** con `**dobles asteriscos**` - *Texto en cursiva* con `*asteriscos simples*` - ***Negrita y cursiva*** con `***triples asteriscos***` - ~~Tachado~~ con `~~dobles tildes~~` ### Cuando usar cada estilo La **negrita** funciona mejor para terminos clave, advertencias importantes o definiciones — cualquier cosa que el lector no deberia perderse al escanear. Usala para la frase mas importante de un parrafo, no para oraciones completas. La *cursiva* es para enfasis dentro de una oracion, titulos de libros y publicaciones, terminos tecnicos en su primer uso y frases extranjeras. Proporciona un enfasis mas ligero que la negrita. El ~~tachado~~ es util para mostrar correcciones, informacion obsoleta o elementos completados en un changelog. Tiene un conjunto mas reducido de casos de uso pero es valioso cuando lo necesitas. ## Enlaces [Enlace inline](https://astro.build) con sintaxis `[texto](url)`. Los enlaces tambien pueden referenciar otros posts en tu sitio usando rutas relativas. Usa texto descriptivo para el enlace — "lee la guia de markdown" es mejor que "haz clic aqui." Un buen texto de enlace ayuda tanto a lectores como a motores de busqueda a entender adonde lleva el enlace. Tambien puedes crear enlaces que funcionan en contexto escribiendo texto anchor descriptivo que se lea naturalmente dentro de la oracion. Por ejemplo: la [documentacion de Astro](https://docs.astro.build) cubre cada funcionalidad en detalle. ## Listas Lista desordenada: - Primer elemento - Segundo elemento - Elemento anidado - Otro elemento anidado - Tercer elemento Lista ordenada: 1. Primer paso 2. Segundo paso 1. Sub-paso uno 2. Sub-paso dos 3. Tercer paso Lista de tareas: - [x] Configurar el proyecto - [x] Escribir tu primer post - [ ] Desplegar a produccion ### Consejos de formato para listas Las listas son una de las herramientas mas efectivas en la escritura web. Dividen el texto denso, hacen la informacion escaneable y comunican claramente secuencias o colecciones de elementos. **Usa listas desordenadas** cuando los elementos no tienen una secuencia inherente — funcionalidades, requisitos, opciones o ejemplos. **Usa listas ordenadas** cuando la secuencia importa — pasos de un proceso, elementos clasificados o instrucciones que deben seguirse en orden. **Usa listas de tareas** para seguimiento de progreso, checklists de proyecto o elementos pendientes. Se renderizan como checkboxes interactivos en muchos visores Markdown, aunque en un blog estatico aparecen como indicadores visuales. Manten los elementos de la lista paralelos en estructura. Si el primer elemento comienza con un verbo, todos los elementos deberian comenzar con un verbo. ## Citas > El proposito de la abstraccion no es ser vago, sino crear un nuevo nivel semantico en el que se pueda ser absolutamente preciso. > > — Edsger W. Dijkstra Citas anidadas: > Primer nivel > > > Segundo nivel > > > > > Tercer nivel ### Uso de citas Las citas sirven varios propositos mas alla de citar personas famosas: - **Citar fuentes** — cuando se hace referencia a otro articulo, libro o documento - **Llamadas de atencion** — resaltar informacion importante o advertencias - **Cita estilo email** — mostrar lo que alguien dijo en una conversacion a la que estas respondiendo - **Citas destacadas** — llamar la atencion sobre un pasaje clave de tu propio articulo Cuando uses citas para atribucion, coloca el nombre del autor en una linea separada precedida por un guion largo, como se muestra en el ejemplo de Dijkstra arriba. ## Codigo Codigo `inline` con backticks. Usa codigo inline para nombres de funcion como `getPublishedPosts()`, rutas de archivo como `src/content/posts/`, instrucciones de linea de comandos como `pnpm dev` y cualquier valor literal en el texto. Bloque de codigo con resaltado de sintaxis: ```typescript interface Post { title: string; date: Date; description?: string; tags?: string[]; draft?: boolean; } function getPublishedPosts(posts: Post[]): Post[] { return posts .filter((post) => !post.draft) .sort((a, b) => b.date.getTime() - a.date.getTime()); } ``` ```css @theme { --font-sans: 'system-ui', sans-serif; --font-serif: 'ui-serif', 'Georgia', serif; } ``` ### Consejos para bloques de codigo Siempre especifica el identificador del lenguaje despues de los triples backticks de apertura. Esto habilita el resaltado de sintaxis, que mejora dramaticamente la legibilidad. Identificadores comunes incluyen `typescript`, `javascript`, `css`, `html`, `bash`, `json`, `python` y `markdown`. Para comandos shell, usa `bash` o `sh`: ```bash # Instalar dependencias pnpm install # Iniciar el servidor de desarrollo pnpm dev # Construir para produccion pnpm build ``` Para archivos de configuracion JSON: ```json { "name": "my-blog", "version": "1.0.0", "scripts": { "dev": "astro dev", "build": "astro build" } } ``` Manten los bloques de codigo enfocados. Muestra solo las lineas relevantes en lugar de pegar un archivo completo. Si se necesita contexto, agrega un comentario indicando donde se encuentra el codigo. ## Tablas | Funcionalidad | Estado | Notas | |---|---|---| | Modo oscuro | Soportado | Claro / Oscuro / Sistema | | Feed RSS | Integrado | `/rss.xml` | | Sitemap | Auto-generado | Via `@astrojs/sitemap` | | SEO | Integrado | Open Graph + canonico | Columnas alineadas a la derecha y centradas: | Izquierda | Centro | Derecha | |:---|:---:|---:| | Texto | Texto | Texto | | Texto mas largo | Texto mas largo | Texto mas largo | ### Pautas para tablas Las tablas funcionan mejor para datos estructurados con columnas y filas claras. Son ideales para comparaciones de funcionalidades, opciones de configuracion, parametros de API y datos de referencia. Manten las tablas simples. Si una tabla tiene mas de cinco o seis columnas, se vuelve dificil de leer en dispositivos moviles. Considera dividir tablas complejas en varias mas pequenas, o usa un formato de lista. La alineacion de columnas se controla con dos puntos en la fila separadora: - `:---` para alineacion a la izquierda (predeterminado) - `:---:` para alineacion al centro - `---:` para alineacion a la derecha Usa la alineacion a la derecha para datos numericos para que los puntos decimales se alineen visualmente. ## Linea horizontal Usa `---` para crear una linea horizontal: --- Contenido despues de la linea. Las lineas horizontales son utiles para separar secciones principales de un post, indicar un cambio de tema o dividir visualmente articulos muy largos. Usalas con moderacion — si necesitas separadores frecuentes, los encabezados podrian ser una mejor eleccion estructural. ## Imagenes Las imagenes se soportan con sintaxis Markdown estandar: ```markdown ![Texto alternativo](./image.jpg) ``` Este tema se enfoca en la tipografia, pero las imagenes funcionan cuando las necesitas. ### Mejores practicas para imagenes - **Siempre incluye texto alternativo** — es esencial para la accesibilidad y tambien aparece cuando las imagenes no cargan - **Usa nombres de archivo descriptivos** — `dashboard-error-state.png` es mejor que `screenshot-2.png` - **Optimiza los tamanos de archivo** — comprime las imagenes antes de agregarlas a tu repositorio; imagenes grandes ralentizan la carga de las paginas - **Considera el flujo de lectura** — coloca las imagenes cerca del texto que las referencia, no a parrafos de distancia ## Poniendo todo junto Las funcionalidades Markdown descritas en esta guia cubren la gran mayoria de lo que necesitaras para la escritura de blog. La clave para un buen Markdown es usar el elemento correcto para el proposito correcto: encabezados para estructura, enfasis para importancia, listas para colecciones, bloques de codigo para contenido tecnico y parrafos para todo lo demas. Escribe con claridad, formatea con consistencia y deja que la tipografia haga su trabajo.

👋 Hola mundo

Thu, 01 Jan 2026 08:00:00 GMT

Bienvenido a Astro-Theme-Aither. Este es un tema de blog construido sobre una creencia: la buena escritura merece buena tipografia. Encabezados en serif, un ritmo de lectura limpio y un diseño de pagina que no estorba. Todo aqui sirve un unico objetivo: hacer que tus palabras se vean y se sientan hermosas. ## Por que otro tema de blog La web esta llena de temas de blog, asi que una pregunta justa es: por que construir otro? La respuesta se reduce a las prioridades. La mayoria de los temas optimizan para el impacto visual — grandes imagenes destacadas, diseños de pagina complejos y transiciones animadas. Se ven impresionantes en una demostracion, pero estorban cuando alguien se sienta a leer un articulo de 2,000 palabras. Astro-Theme-Aither parte de una premisa diferente. El contenido es el producto. El trabajo del tema es presentar ese contenido con el cuidado que merece: combinaciones de fuentes meditadas, espacios en blanco generosos y un ritmo vertical que hace la lectura larga comoda en lugar de agotadora. Esta filosofia se extiende tambien a las decisiones tecnicas. El tema distribuye aproximadamente 0.5 KB de JavaScript del lado del cliente — justo lo necesario para el toggle del tema. Todo lo demas es HTML estatico y CSS. Sin layout shifts, sin spinners de carga, sin frameworks JavaScript hidratandose en segundo plano. La pagina carga y tu lees. ## Comenzar Ponerse en marcha toma solo unos minutos. Aqui esta el proceso completo: 1. **Clona el repositorio** — usa el boton de template de GitHub o clona directamente con `git clone` 2. **Instala las dependencias** — ejecuta `pnpm install` para descargar todos los paquetes 3. **Configura tu sitio** — edita `src/config/site.ts` para establecer el titulo del sitio, la descripcion y los enlaces de navegacion 4. **Reemplaza el contenido de ejemplo** — cambia los posts en `src/content/posts/` por tus propios archivos Markdown 5. **Comienza a desarrollar** — ejecuta `pnpm dev` para lanzar el servidor de desarrollo local con hot reloading 6. **Despliega** — haz push a GitHub y deja que el flujo CI incluido maneje el despliegue a Cloudflare Pages ### Estructura del proyecto El codebase esta organizado para ser inmediatamente comprensible: ``` src/ ├── components/ # Componentes Astro reutilizables ├── config/ # Configuracion del sitio ├── content/ # Tus posts Markdown y contenido ├── layouts/ # Layouts de pagina (Layout.astro) ├── pages/ # Paginas de rutas └── styles/ # CSS global con tokens Tailwind v4 ``` Cada directorio tiene una responsabilidad clara. Los componentes son pequenos y componibles. Los layouts manejan el envoltorio del documento. Las paginas definen rutas. El contenido alberga tu escritura. No hay magia — solo archivos bien organizados. ### Escribiendo tu primer post Crea un nuevo archivo `.md` en `src/content/posts/` con el siguiente frontmatter: ```markdown --- title: El titulo de tu post date: "2026-01-15T16:00:00+08:00" category: General description: Un breve resumen para SEO y previsualizaciones sociales tags: [Tema, Otro] --- Tu contenido comienza aqui. ``` Los campos `title`, `date` y `category` son obligatorios. El campo `description` es altamente recomendado porque llena el tag meta description y las previsualizaciones Open Graph. Los tags son opcionales pero ayudan a los lectores a descubrir contenido relacionado. ## Lo que obtienes De serie, tienes una plataforma de blogging lista para produccion con cada caracteristica que necesitas y nada de lo que no. ### Caracteristicas de contenido - **Feed RSS** — generado automaticamente en `/rss.xml`, compatible con cada lector de feeds - **Sitemap** — auto-generado via `@astrojs/sitemap` para indexacion en motores de busqueda - **Meta tags SEO** — Open Graph, Twitter cards y URLs canonicas en cada pagina - **Modo oscuro** — toggle de tres vias (Claro / Oscuro / Sistema) con persistencia `localStorage` - **Paginas de categorias y tags** — archivos organizados para navegar por tema ### Caracteristicas para desarrolladores - **TypeScript en todas partes** — strict mode, componentes y utilidades completamente tipados - **Content Collections** — sistema integrado de Astro para Markdown type-safe con validacion de frontmatter - **Tailwind CSS v4** — usando tokens de diseno `@theme` para facil personalizacion de colores, fuentes y espaciado - **Vitest + Playwright** — tests unitarios y end-to-end ya conectados al pipeline CI - **Cloudflare Pages** — flujo de despliegue con URLs de vista previa automáticas para PRs - **Google Analytics** — opcional, aislado en un Partytown Web Worker para nunca bloquear el hilo principal ### Rendimiento Como el tema produce HTML estatico con JavaScript minimo, el rendimiento es excelente por defecto. Puedes esperar puntuaciones Lighthouse de 100 en todos los aspectos — Performance, Accessibility, Best Practices y SEO. No hay nada que optimizar porque no hay nada innecesario. ## Personalizacion El tema esta disenado para ser tuyo. Las personalizaciones mas comunes son directas: - **Colores** — edita las propiedades CSS personalizadas en `src/styles/global.css` para cambiar toda la paleta - **Fuentes** — intercambia los valores de font-family en la configuracion del tema Tailwind - **Navegacion** — actualiza el array de enlaces de navegacion en `src/config/site.ts` - **Analytics** — agrega tu ID de medicion de Google Analytics en la configuracion del sitio Para cambios mas profundos, la arquitectura de componentes es deliberadamente simple. No hay abstracciones profundamente anidadas ni patrones complejos de gestion de estado. Cada componente hace una cosa, lee sus props y renderiza HTML. ## Una nota sobre la filosofia de diseno La simplicidad visual de este tema es intencional, pero no es lo mismo que simplicidad de ingenieria. Bajo el capo, el tema maneja un numero sorprendente de aspectos: escalas tipograficas responsivas, relaciones de contraste de color accesibles en modos claro y oscuro, estructura HTML semantica correcta, jerarquia de encabezados correcta y atencion cuidadosa a la experiencia de lectura en pantallas que van desde telefonos hasta monitores ultrawide. El buen diseno es invisible. Cuando lees un articulo en este tema y simplemente disfrutas la escritura sin notar el tema en absoluto — ese es el diseno funcionando exactamente como fue planeado. Feliz escritura.