Espace documentation produit complet et a jour

Demande

Un utilisateur abonne (Andrea, profil consultant, non developpeur) signale que le principal manque d'AgentsRoom aujourd'hui n'est pas une fonctionnalite mais une documentation complete et a jour.

Il n'a trouve aucun endroit ou parcourir l'ensemble des features, des concepts et des options de configuration. Pour se lancer, il a du faire scraper les pages du site agentsroom.dev par une IA afin de se reconstituer une vue d'ensemble du produit et de se faire expliquer, etape par etape, comment demarrer. Plusieurs mois apres, il estime n'utiliser qu'une fraction du produit.

C'est un signal de retention et d'activation, pas un confort editorial : le cout d'entree est paye par chaque utilisateur qui n'est pas developpeur professionnel.

Verbatim (Andrea, par email)

If I had to point out the main thing that is still missing for me, though, it would be comprehensive and up-to-date documentation.

For someone who is not a professional developer, the first step into AgentsRoom was quite difficult. When I started, I actually ended up using AI to scrape and analyse the different pages of the AgentsRoom website, just to build a complete picture of the available features and have the AI explain to me step by step how I could start using them.

Even now, there are several parts of the product that are still not completely clear to me, and I'm quite sure I'm only using a fraction of what AgentsRoom can actually do.

Having a proper docs section where I could easily browse all current features, concepts, configuration options and some practical examples or workflows would make a huge difference, especially for users like me who are technical enough to experiment, but don't necessarily have a software engineering background.

Contexte utilisateur, sur le reste du message : il est satisfait du produit, cite la polyvalence et l'orchestration de plusieurs agents / projets / outils sans devoir tout faire rentrer dans un workflow unique, et dit qu'AgentsRoom est le premier outil qui lui donne le sentiment de pouvoir construire quelque chose de complexe par lui-meme (apres des essais frustrants sur VS Code, Cursor et Windsurf).

Ce qui est demande

Un espace documentation navigable, qui couvre :

1. Les concepts : projet, agent, role, provider CLI, team, backlog, skill, prompt, memoire projet, commandes dev, backlog public, cloud agents.
2. Toutes les features actuelles, une entree par feature, avec ce qu'elle fait et ou elle se trouve dans l'app.
3. Les options de configuration : reglages Settings, providers et modeles, MCP, hooks, worktrees, partage de donnees.
4. Des exemples pratiques et des workflows de bout en bout : premier projet, premier agent, un ticket backlog joue par un agent, une team, le backlog public, le mobile.
5. Un parcours de demarrage explicitement pense pour un utilisateur non developpeur.

Existant a auditer avant d'ecrire

Le contenu produit est aujourd'hui eclate et aucun de ces points d'entree ne joue le role d'une documentation :

• site/src/app/[locale]/features/* : pages marketing par feature, orientees conversion et SEO, pas reference.
• site/src/app/[locale]/guides/* : guides existants, couverture partielle.
• site/src/app/[locale]/blog/* : articles, non structures en reference.
• site/src/app/[locale]/skills et /prompts : catalogues, pas de doc d'usage.
• site/public/llms.txt : vue machine, pas destinee aux humains.
• Le changelog est en noindex.

Points de vigilance

• i18n : le site est publie dans toutes les locales de site/src/i18n/routing.ts. Une doc complete traduite a la main dans 20 langues est un chantier a chiffrer AVANT de commencer. Le decoupage en lots (concepts d'abord, features ensuite) fait partie du travail de cadrage. Rappel de la regle du depot : aucune locale ne se remplit avec de l'anglais.
• Fraicheur : le probleme signale est autant "complete" que "up-to-date". Une doc qui derive est pire que pas de doc. Prevoir des le cadrage comment elle reste synchrone avec les livraisons (la regle CLAUDE.md "une feature modifiee doit etre refletee cote site" doit pointer vers la doc, pas seulement vers la copy marketing).
• SEO : ne pas cannibaliser les pages /features/* qui portent deja des requetes. Definir la propriete des requetes avant de creer les URLs (voir context/SEO.md).

Definition of done

• Un cadrage ecrit : arborescence proposee, perimetre du premier lot, cout i18n estime, regle de fraicheur, arbitrage SEO vis-a-vis de /features/*.
• Validation de ce cadrage avant toute redaction.