Claude Code
Configurez Claude Code pour rédiger et maintenir la documentation Jamdesk. Inclut un modèle CLAUDE.md et la connexion au serveur MCP.
Claude Code est le CLI d'Anthropic pour Claude. Parce qu'il lit l'intégralité de votre répertoire de projet, il repère votre style d'écriture existant et la structure de votre docs.json à partir des fichiers eux-mêmes, puis rédige des pages qui s'intègrent naturellement à ce que vous avez déjà.
Nous maintenons la documentation de Jamdesk dans cette configuration exacte. Le modèle CLAUDE.md ci-dessous est proche de celui que nous utilisons nous-mêmes. Personnalisez-le pour votre projet, mais les règles de structure des pages, la convention des cartes « Et ensuite ? » et la liste stricte des composants sont des conventions que nous recommandons de conserver.
Par rapport à Codex, le point fort de Claude Code est l'itération interactive. Vous pouvez rédiger une page, lire le résultat, contester une section et la faire réécrire dans la même session, avec un contexte de projet complet tout au long. Codex est le meilleur choix pour les tâches par lots multi-fichiers sans intervention ; cette page couvre le flux de travail pour tout le reste.
Configuration rapide
Installez depuis claude.ai/code.
Ajoutez votre documentation comme source de données MCP :
claude mcp add --transport http my-docs https://your-project.jamdesk.app/_mcpRemplacez your-project par votre sous-domaine Jamdesk. Claude peut maintenant rechercher et lire vos docs publiées directement. Voir Serveur MCP pour les détails.
Créez un CLAUDE.md à la racine de votre projet de documentation. Cela donne à Claude un contexte cohérent sur vos normes de documentation, les composants disponibles et votre style d'écriture.
Modèle CLAUDE.md
Ajoutez ce fichier à la racine de votre projet de documentation 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 before it. "What's Next?" is always the last section. Card descriptions explain why, not what ("Set up search for your docs", not "Search configuration page").
## Writing Style
Start with why. What problem does this page solve? Show that first, then walk through how to use the feature.
Use progressive disclosure: a simple example near the 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 reach for "also" or "additionally", start a new paragraph instead.
Code examples must actually work. Never show partial code or pseudocode. Every block should be complete and copy-pasteable.
Write like a person. Skip filler like "It's important to note that", "This allows you to", or "seamlessly". Drop the hedging ("you might want to consider"). Read your output back, and if it sounds like a chatbot wrote it, rewrite it shorter and more direct.
## Components
Layout: Card, Columns, Tabs, Tab, Accordion, AccordionGroup, Steps, Step, Expandable, Frame, CodeGroup
Callouts: Note, Info, Warning, Tip, Check, Danger
When to use each:
| Component | Use for | Don't use for |
|-----------|---------|---------------|
| Tabs | Mutually exclusive choices (npm/yarn, languages) | Sequential content |
| Steps | Ordered procedures | Unordered lists of features |
| Accordion | Optional/advanced detail | Core content readers need |
| Card (in Columns) | Navigation links, feature grids | Inline content |
| Note/Tip/Warning | Important context the reader might miss | 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.
## Before You're Done
Check your work:
- [ ] Frontmatter has both `title` and `description`
- [ ] Opening paragraph exists (no heading before it)
- [ ] Page ends with "What's Next?" cards
- [ ] New pages are added to `docs.json` navigation
- [ ] Code examples are complete and copy-pasteable
- [ ] No invented components; only the ones listed above
- [ ] No raw HTML tags; use MDX components
- [ ] Images use `.webp` format
## Common Mistakes
- Inventing components like `<CodeBlock>`, `<Alert>`, or `<Section>`. They don't exist. Use the components listed above.
- Wrapping code in components. Code blocks are standard Markdown triple backticks. Don't wrap them in `<CodeGroup>` unless you're showing multiple language alternatives.
- Skipping description frontmatter. Every page needs it; it appears in search results and link previews.
- Using `<Card>` without `<Columns>`. Cards must be inside a `<Columns>` wrapper.
- Writing "click here" links. Use descriptive link text: [Migration guide](/setup/migration), not [click here](/setup/migration).Personnalisez le modèle pour votre projet. Ajoutez le nom de votre produit, les conventions d'API, la terminologie et toutes les directives de contenu propres à votre documentation.
Exemples de prompts
Une fois votre CLAUDE.md et votre connexion MCP en place, vous n'avez pas besoin de tout expliquer en détail. Claude dispose déjà du contexte du projet, donc les prompts courts fonctionnent mieux que les longs.
Un point de départ courant : « Rédige un guide de démarrage pour [fonctionnalité] ». Parce que Claude a déjà lu vos autres pages, il reprend votre ton sans qu'on le lui dise. Pour détecter les dérives, demandez-lui de réviser une seule page par rapport au reste du site. Claude tend à repérer les petites incohérences (un composant utilisé différemment ici ou là, un changement de ton entre les sections) que les auteurs manquent lors de leur propre relecture.
Les prompts qui surprennent le plus sont ceux de nettoyage. « Convertis ce README en pages de documentation » transforme un fichier unique en un ensemble correctement structuré avec navigation. Pointer vers une page existante et demander une FAQ basée sur des Accordions puise dans les vrais problèmes de votre dépôt — bien plus proches des vraies questions des lecteurs que tout ce qu'on écrirait à partir d'un document vierge.
La compétence /update-jamdesk
Pour les mises à jour automatisées de la documentation lors de changements de code, installez la compétence /update-jamdesk :
npx skills add jamdesk/skills --skill update-jamdeskAprès avoir implémenté une fonctionnalité visible par les utilisateurs, lancez /update-jamdesk et Claude déterminera quelles pages de documentation doivent être créées ou modifiées. Voir Mises à jour automatisées pour le guide complet.