Jamdesk Documentation logo

Codex

Codex est l'agent de codage cloud d'OpenAI pour les tâches de documentation asynchrones et multi-fichiers directement sur des dépôts GitHub.

Codex est l'agent de codage cloud d'OpenAI. Il fonctionne directement avec les dépôts GitHub, ce qui vous permet d'effectuer des tâches de documentation sur votre projet sans configurer d'abord un environnement local.

Le compromis entre Codex et Claude Code porte surtout sur la forme du workflow. Codex s'exécute dans le cloud et fonctionne de manière asynchrone : vous décrivez une portion de travail, vous vous éloignez, puis vous examinez une PR une fois le travail terminé. Cela convient bien aux tâches par lots (diviser un README de 500 lignes en une douzaine de pages, ou générer une page de dépannage à partir de vos six derniers mois d'issues GitHub), mais ce n'est pas idéal pour les allers-retours nécessaires à l'affinage d'une seule page. Si votre tâche est un travail par lots sur plusieurs fichiers que vous préférez ne pas surveiller, Codex est le bon choix. Pour un travail interactif sur une seule page, utilisez plutôt Claude Code.

Configuration rapide

1
Ouvrir votre dépôt

Accédez à votre dépôt de documentation Jamdesk dans Codex. Codex fonctionne directement avec les dépôts GitHub.

2
Ajouter des instructions pour l'agent

Créez un fichier AGENTS.md à la racine de votre projet avec vos standards de documentation afin que Codex respecte vos conventions.

3
Connecter le serveur MCP

Ajoutez votre endpoint MCP de documentation à .codex/config.toml afin que Codex puisse rechercher dans votre documentation publiée.

Modèle AGENTS.md

Créez AGENTS.md à la racine de votre projet :

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.

Ajoutez la terminologie de votre produit, les conventions de nommage de votre API, ainsi que les règles de style propres à votre documentation.

Configuration MCP

Ajoutez votre endpoint de documentation à .codex/config.toml :

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

Remplacez your-project par votre sous-domaine Jamdesk — ou, si vous avez un domaine personnalisé actif, utilisez-le à la place : url = "https://docs.acme.com/_mcp". Consultez Serveur MCP pour plus de détails sur l'endpoint.

Exemples de prompts

Codex exécute les tâches de manière asynchrone. Cela change la façon de le prompter : au lieu d'un dialogue interactif, vous lancez une tâche longue puis revenez vérifier plus tard le résultat. Les prompts efficaces sont donc ceux qui demandent une portion de travail conséquente.

Un bon premier essai : « Rédige la documentation de l'API d'authentification à partir de la source dans /src/auth ». Codex lit votre base de code, trouve les fichiers pertinents et génère les pages correspondantes. Pour quelque chose de plus complexe, orientez-le vers votre historique réel de bugs : « Crée une page de dépannage couvrant les 5 erreurs les plus courantes dans nos issues GitHub » a tendance à produire une page plus honnête que tout ce que vous écririez de mémoire.

Les restructurations multi-fichiers fonctionnent particulièrement bien dans ce mode. Copiez ce prompt dans Codex pour une tâche avec des critères de révision clairs :

Restructurer un grand README

Restructurez le `README.md` de 500 lignes en pages de documentation Jamdesk ciblées. Critères d'acceptation : - Conservez chaque détail technique, commande, avertissement et exemple de code unique du README. - Regroupez le contenu en pages `.mdx` centrées sur des tâches, avec des noms de fichiers explicites. - Donnez à chaque page un frontmatter `title` et `description`, un paragraphe d'introduction, et des cartes « Et ensuite ? ». - Ajoutez chaque nouvelle page au groupe approprié dans `docs.json` et conservez un ordre de pages logique. - Utilisez uniquement les composants Jamdesk déjà répertoriés dans `components/overview.mdx` ; n'inventez pas de composants. - Corrigez les liens internes pour la nouvelle structure de fichiers et signalez tout lien source que vous ne parvenez pas à résoudre. - Ne supprimez pas le README d'origine tant que tout le contenu n'est pas représenté et que les nouvelles pages ne passent pas les contrôles de validation et de liens brisés du projet.

Restructurer un grand README

Restructurez le `README.md` de 500 lignes en pages de documentation Jamdesk ciblées.

Critères d'acceptation :

- Conservez chaque détail technique, commande, avertissement et exemple de code unique du README.
- Regroupez le contenu en pages `.mdx` centrées sur des tâches, avec des noms de fichiers explicites.
- Donnez à chaque page un frontmatter `title` et `description`, un paragraphe d'introduction, et des cartes « Et ensuite ? ».
- Ajoutez chaque nouvelle page au groupe approprié dans `docs.json` et conservez un ordre de pages logique.
- Utilisez uniquement les composants Jamdesk déjà répertoriés dans `components/overview.mdx` ; n'inventez pas de composants.
- Corrigez les liens internes pour la nouvelle structure de fichiers et signalez tout lien source que vous ne parvenez pas à résoudre.
- Ne supprimez pas le README d'origine tant que tout le contenu n'est pas représenté et que les nouvelles pages ne passent pas les contrôles de validation et de liens brisés du projet.

Le skill /update-jamdesk

Pour des mises à jour automatisées de la documentation lors de changements de code, installez le skill /update-jamdesk :

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

Consultez Mises à jour automatisées pour le guide complet.

Et ensuite ?

Rédiger avec l'IA

Des stratégies de prompt qui fonctionnent avec tous les outils

Claude Code

Modèle CLAUDE.md et workflows de contexte complet du projet