Jamdesk Documentation logo

Codex

Codex es el agente de programación en la nube de OpenAI para tareas de documentación asíncronas y multiarchivo directamente en repositorios de GitHub.

Codex es el agente de programación en la nube de OpenAI. Funciona directamente con repositorios de GitHub, así que puedes ejecutar tareas de documentación en tu proyecto sin configurar antes un entorno local.

La diferencia entre Codex y Claude Code tiene que ver sobre todo con la forma del flujo de trabajo. Codex se ejecuta en la nube y funciona de forma asíncrona: describes un bloque de trabajo, te alejas y revisas un PR cuando está listo. Esto encaja bien con tareas por lotes (dividir un README de 500 líneas en una docena de páginas, o generar una página de solución de problemas a partir de tus últimos seis meses de issues de GitHub), pero no es ideal para el ir y venir de refinar una sola página. Si tu trabajo es una tarea por lotes de varios archivos que prefieres no supervisar de cerca, Codex es la opción adecuada. Para trabajo interactivo en una sola página, usa Claude Code en su lugar.

Configuración rápida

1
Abre tu repositorio

Navega a tu repositorio de documentación de Jamdesk en Codex. Codex funciona directamente con repositorios de GitHub.

2
Añade instrucciones para el agente

Crea un archivo AGENTS.md en la raíz de tu proyecto con los estándares de documentación para que Codex siga tus convenciones.

3
Conecta el servidor MCP

Añade tu endpoint MCP de documentación a .codex/config.toml para que Codex pueda buscar en tu documentación publicada.

Plantilla de AGENTS.md

Crea AGENTS.md en la raíz de tu proyecto:

AGENTS.md
# Jamdesk Documentation Project

Jamdesk docs project. Pages are MDX (Markdown + React components). Config is in `docs.json`.

## How This Project Works

- `docs.json`: navigation structure, theme, colors, branding. Pages must be listed here to appear in the sidebar.
- `*.mdx` files: documentation pages. Every page needs `title` and `description` frontmatter.
- `images/`: static assets. Always use `.webp` format.
- `snippets/`: reusable MDX fragments. Import with `<Snippet file="name.mdx" />`.

## Page Template

Every page follows this structure:

    ---
    title: Clear, Specific Title
    description: One sentence. Used in search results and social previews.
    ---

    Opening paragraph: what this page covers and who it's for. No heading needed.

    ## First Section

    Content. Use components where they help, not for decoration.

    ## What's Next?

    <Columns cols={2}>
      <Card title="Related Page" icon="arrow-right" href="/path">

        Why the reader would go here next

</Card>
</Columns>

The opening paragraph comes right after frontmatter with no heading. "What's Next?" is always the last section. Card descriptions explain why, not what.

## Writing Style

Start with why. What problem does this solve? Show the answer first, then unpack the how.

Use progressive disclosure: simple example up top, advanced options tucked into Accordions or later sections.

Active voice. "Run this command", not "This command should be run".

One idea per paragraph. If you find yourself reaching for "also" or "additionally", that's the cue to start a new paragraph instead.

Code examples have to actually work. Every block should be complete and copy-pasteable, never partial or pseudocode.

And write like a person. No filler ("It's important to note that", "This allows you to"). No hedging ("you might want to consider"). If a paragraph reads like a chatbot wrote it, rewrite it shorter.

## Components

Only use these. Do not invent others.

Layout: Card, Columns, Tabs, Tab, Accordion, AccordionGroup, Steps, Step, Expandable, Frame, CodeGroup
Callouts: Note, Info, Warning, Tip, Check, Danger

| Use | For | Don't use for |
|-----|-----|---------------|
| Tabs | Mutually exclusive choices (npm/yarn, OS) | Sequential content |
| Steps | Ordered procedures | Unordered lists |
| Accordion | Optional/advanced detail | Core content |
| Card + Columns | Navigation links, feature grids | Inline content |
| Note/Tip/Warning | Important context | Every other paragraph |

Cards always go inside Columns:

    <Columns cols={2}>
      <Card title="Page Title" icon="icon-name" href="/path">

        Brief description

</Card>
</Columns>

Icons are Font Awesome Light names: "rocket", "code", "terminal", "book-open", "gear"

## Adding Pages

1. Create the `.mdx` file
2. Add the page path (no `.mdx` extension) to `docs.json` in the right navigation group
3. Link to it from related pages via "What's Next?" cards

If you skip step 2, the page won't show up in the sidebar. Read `docs.json` before creating pages so you understand the navigation structure.

## Common Mistakes

- Inventing components like `<CodeBlock>`, `<Alert>`, `<Section>`. They don't exist.
- Using `<Card>` without a `<Columns>` wrapper.
- Skipping `description` in frontmatter, which breaks search results and link previews.
- Using raw HTML tags instead of MDX components.
- Writing "click here" links instead of descriptive link text.

Añade la terminología de tu producto, las convenciones de nomenclatura de tu API y cualquier regla de estilo específica de tu documentación.

Configuración de MCP

Añade el endpoint de tu documentación a .codex/config.toml:

.codex/config.toml
[mcp_servers.my-docs]
url = "https://your-project.jamdesk.app/_mcp"

Sustituye your-project por tu subdominio de Jamdesk — o, si tienes un dominio personalizado activo, úsalo en su lugar: url = "https://docs.acme.com/_mcp". Consulta Servidor MCP para más detalles sobre el endpoint.

Prompts de ejemplo

Codex ejecuta tareas de forma asíncrona. Eso cambia la forma de escribir los prompts: en lugar de un ir y venir interactivo, lanzas una tarea larga y revisas el resultado más tarde, así que los prompts que mejor funcionan son los que piden un bloque de trabajo completo.

Un buen primer intento: "Escribe documentación para la API de autenticación basándote en el código fuente de /src/auth". Codex lee tu código base, encuentra los archivos relevantes y genera páginas equivalentes. Para algo más complicado, apúntalo a tu historial real de errores: "Crea una página de solución de problemas que cubra los 5 errores más comunes en nuestros issues de GitHub" suele producir una página más honesta que cualquier cosa que escribirías de memoria.

Las reestructuraciones de varios archivos funcionan especialmente bien en este modo. Copia este prompt en Codex para una tarea con criterios de revisión claros:

Reestructura un README grande

Reestructura el `README.md` de 500 líneas en páginas de documentación de Jamdesk enfocadas en tareas concretas. Criterios de aceptación: - Preserva cada detalle técnico único, comando, advertencia y ejemplo de código del README. - Agrupa el contenido en páginas `.mdx` enfocadas en tareas con nombres de archivo descriptivos. - Dale a cada página el frontmatter `title` y `description`, un párrafo de apertura y tarjetas de "¿Qué sigue?". - Añade cada página nueva al grupo correspondiente en `docs.json` y mantén el orden de las páginas de forma lógica. - Usa solo componentes de Jamdesk ya incluidos en `components/overview.mdx`; no inventes componentes. - Corrige los enlaces internos para la nueva estructura de archivos e informa de cualquier enlace de origen que no puedas resolver. - No elimines el README original hasta que todo el contenido esté representado y las páginas nuevas pasen las comprobaciones de validación y enlaces rotos del proyecto.

Reestructura un README grande

Reestructura el `README.md` de 500 líneas en páginas de documentación de Jamdesk enfocadas en tareas concretas.

Criterios de aceptación:

- Preserva cada detalle técnico único, comando, advertencia y ejemplo de código del README.
- Agrupa el contenido en páginas `.mdx` enfocadas en tareas con nombres de archivo descriptivos.
- Dale a cada página el frontmatter `title` y `description`, un párrafo de apertura y tarjetas de "¿Qué sigue?".
- Añade cada página nueva al grupo correspondiente en `docs.json` y mantén el orden de las páginas de forma lógica.
- Usa solo componentes de Jamdesk ya incluidos en `components/overview.mdx`; no inventes componentes.
- Corrige los enlaces internos para la nueva estructura de archivos e informa de cualquier enlace de origen que no puedas resolver.
- No elimines el README original hasta que todo el contenido esté representado y las páginas nuevas pasen las comprobaciones de validación y enlaces rotos del proyecto.

La skill /update-jamdesk

Para actualizaciones automáticas de documentación cuando cambia el código, instala la skill /update-jamdesk:

npx skills add jamdesk/skills --skill update-jamdesk -a codex

Consulta Actualizaciones automáticas para la guía completa.

¿Qué sigue?

Escribir con IA

Estrategias de prompting que funcionan en todas las herramientas

Claude Code

Plantilla de CLAUDE.md y flujos de trabajo de contexto de todo el proyecto