Jamdesk Documentation logo

Codex

Codex é o agente de programação em nuvem da OpenAI para tarefas assíncronas de documentação em vários arquivos diretamente em repositórios do GitHub.

Codex é o agente de programação em nuvem da OpenAI. Ele funciona diretamente com repositórios do GitHub, permitindo executar tarefas de documentação no seu projeto sem configurar primeiro um ambiente local.

A diferença entre o Codex e o Claude Code está principalmente no fluxo de trabalho. O Codex é executado na nuvem e funciona de forma assíncrona: você descreve uma parte do trabalho, deixa o processo rodando e revisa um PR quando ele termina. Isso é adequado para tarefas em lote, como dividir um README de 500 linhas em uma dúzia de páginas ou gerar uma página de solução de problemas a partir dos seus últimos seis meses de issues do GitHub, mas não é ideal para o vai e volta de refinar uma única página. Se o seu trabalho é uma tarefa em lote com vários arquivos que você prefere não acompanhar continuamente, o Codex é a escolha certa. Para trabalhar de forma interativa em uma única página, use o Claude Code.

Configuração rápida

1
Abra seu repositório

Navegue até o repositório de documentação do Jamdesk no Codex. O Codex funciona diretamente com repositórios do GitHub.

2
Adicione instruções para o agente

Crie um arquivo AGENTS.md na raiz do projeto com os padrões de documentação para que o Codex siga suas convenções.

3
Conecte o servidor MCP

Adicione o endpoint MCP da sua documentação a .codex/config.toml para que o Codex possa pesquisar sua documentação publicada.

Modelo de AGENTS.md

Crie AGENTS.md na raiz do projeto:

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.

Adicione a terminologia do seu produto, as convenções de nomenclatura da API e quaisquer regras de estilo específicas da sua documentação.

Configuração do MCP

Adicione o endpoint da sua documentação a .codex/config.toml:

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

Substitua your-project pelo seu subdomínio do Jamdesk ou, se você tiver um domínio personalizado ativo, use-o: url = "https://docs.acme.com/_mcp". Consulte Servidor MCP para obter detalhes sobre o endpoint.

Prompts de exemplo

O Codex executa tarefas de forma assíncrona. Isso muda a maneira como você cria prompts: em vez de uma interação contínua, você inicia uma tarefa longa e verifica o progresso mais tarde. Por isso, os prompts mais eficazes são os que solicitam uma parte específica do trabalho.

Uma boa primeira tentativa: "Escreva a documentação da API de autenticação com base no código-fonte em /src/auth". O Codex lê sua base de código, encontra os arquivos relevantes e gera páginas correspondentes. Para algo mais confuso, direcione-o ao seu histórico real de bugs: "Crie uma página de solução de problemas que cubra os 5 erros mais comuns nas nossas issues do GitHub" tende a produzir uma página mais honesta do que qualquer texto que você escreveria de memória.

Reestruturar vários arquivos funciona especialmente bem nesse modo. Copie este prompt no Codex para uma tarefa com critérios de revisão claros:

Reestruture um README grande

Reestruture o `README.md` de 500 linhas em páginas de documentação do Jamdesk focadas em temas específicos. Critérios de aceitação: - Preserve todos os detalhes técnicos exclusivos, comandos, avisos e exemplos de código do README. - Agrupe o conteúdo em páginas `.mdx` focadas em tarefas, com nomes de arquivo descritivos. - Adicione a cada página o frontmatter `title` e `description`, um parágrafo de abertura e cards de Próximos passos. - Adicione cada página nova ao grupo apropriado em `docs.json` e mantenha a ordem lógica das páginas. - Use apenas componentes do Jamdesk já listados em `components/overview.mdx`; não invente componentes. - Corrija os links internos para a nova estrutura de arquivos e informe qualquer link de origem que não consiga resolver. - Não exclua o README original até que todo o conteúdo esteja representado e as novas páginas sejam aprovadas pela validação do projeto e pelas verificações de links quebrados.

Reestruture um README grande

Reestruture o `README.md` de 500 linhas em páginas de documentação do Jamdesk focadas em temas específicos.

Critérios de aceitação:

- Preserve todos os detalhes técnicos exclusivos, comandos, avisos e exemplos de código do README.
- Agrupe o conteúdo em páginas `.mdx` focadas em tarefas, com nomes de arquivo descritivos.
- Adicione a cada página o frontmatter `title` e `description`, um parágrafo de abertura e cards de Próximos passos.
- Adicione cada página nova ao grupo apropriado em `docs.json` e mantenha a ordem lógica das páginas.
- Use apenas componentes do Jamdesk já listados em `components/overview.mdx`; não invente componentes.
- Corrija os links internos para a nova estrutura de arquivos e informe qualquer link de origem que não consiga resolver.
- Não exclua o README original até que todo o conteúdo esteja representado e as novas páginas sejam aprovadas pela validação do projeto e pelas verificações de links quebrados.

A skill /update-jamdesk

Para atualizações automatizadas da documentação quando o código mudar, instale a skill /update-jamdesk:

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

Consulte Atualizações automatizadas para ver o guia completo.

O que vem a seguir?

Escrevendo com IA

Estratégias de prompting que funcionam em todas as ferramentas

Claude Code

Modelo de CLAUDE.md e fluxos de trabalho com contexto de todo o projeto