readme
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseREADME Generator
README 生成器
Generates (or updates) a README.md oriented Product Owner, written in French, concise and illustrated with Mermaid diagrams. Reviews and improves all technical documentation in the directory. Also generates CLAUDE.md and AGENT.md if they don't exist.
docs/生成（或更新）面向产品负责人（Product Owner）的法语版README.md，内容简洁并配有Mermaid图表。审阅并优化目录下的所有技术文档。若CLAUDE.md和AGENT.md不存在则生成它们。
docs/When to Use
使用场景
- No README.md exists at the project root
- The existing README.md is outdated after major changes
- After a significant feature addition or architectural change
- Onboarding a Product Owner or new stakeholder on the project
- 项目根目录下无README.md文件
- 重大变更后现有README.md已过时
- 添加重要功能或架构变更后
- 产品负责人或新利益相关者加入项目需要快速了解情况
The Job
工作流程
Step 1: Explore the Codebase
步骤1：探索代码库
Thoroughly explore the project to understand its purpose, architecture, and tech stack:
- Package manifest: Read ,
package.json,composer.json,pyproject.toml, or equivalent at root and in sub-packages (monorepo)Cargo.toml - Project structure: List top-level directories and key files to understand the architecture
- Documentation: Check for directory. Read the first 20-30 lines of each
docs/file in.mdto deduce a short French description (one line) for each — this will be used in the Table of Contentsdocs/ - CI/CD: Look for ,
.github/workflows/,.gitlab-ci.yml,Jenkinsfile,Dockerfiledocker-compose.yml - Database: Look for migrations, schemas, Prisma/TypeORM/Sequelize config
- Routes/Controllers: Scan for route definitions, API endpoints, controllers
- Git info: Run and
git log --oneline -10to understand recent activity and hostinggit remote -v - Environment: Look for , environment configuration files
.env.example
全面探索项目以理解其用途、架构和技术栈：
- 包清单：读取项目根目录及子包（单体仓库）下的、
package.json、composer.json、pyproject.toml或等效文件Cargo.toml - 项目结构：列出顶层目录和关键文件以理解架构
- 文档：检查目录。读取
docs/下每个docs/文件的前20-30行，为每个文件撰写一句法语简短描述——这将用于目录中.md - CI/CD：查找、
.github/workflows/、.gitlab-ci.yml、Jenkinsfile、Dockerfiledocker-compose.yml - 数据库：查找迁移文件、模式、Prisma/TypeORM/Sequelize配置
- 路由/控制器：扫描路由定义、API端点、控制器
- Git信息：运行和
git log --oneline -10以了解近期活动和托管情况git remote -v - 环境配置：查找及其他环境配置文件
.env.example
Step 2: Create or Update
步骤2：创建或更新
- Check if exists at the project root
README.md - If it does NOT exist: Create it from scratch using the template below
- If it DOES exist: Read the existing content, update factual sections (stack, architecture, features), and preserve any custom sections added by the team
- 检查项目根目录是否存在
README.md - 若不存在：使用下方模板从头创建
- 若存在：读取现有内容，更新事实性章节（技术栈、架构、功能），并保留团队添加的所有自定义章节
Step 3: Generate the Content
步骤3：生成内容
Follow the template defined in the "README Template" section below. All content must be in French, following the writing guidelines.
遵循下方“README模板”部分定义的结构。所有内容必须为法语，符合写作指南。
Step 4: Write the File
步骤4：写入文件
Save at the project root.
README.md将保存到项目根目录。
README.mdStep 5: Generate CLAUDE.md and AGENT.md
步骤5：生成CLAUDE.md和AGENT.md
Only if these files do NOT exist at the project root. If they already exist, do not touch them.
- CLAUDE.md — Generate instructions for Claude Code based on codebase exploration (see dedicated section below)
- AGENT.md — Generate instructions for autonomous AI agents based on codebase exploration (see dedicated section below)
仅当项目根目录下不存在这些文件时生成。若已存在则不修改。
- CLAUDE.md：基于代码库探索结果生成用于Claude Code的指令（见下方专属章节）
- AGENT.md：基于代码库探索结果生成用于自主AI Agent的指令（见下方专属章节）
Step 6: Review Technical Documentation
步骤6：审阅技术文档
Review every file in the directory and propose improvements following the Documentation Quality Rules defined below.
.mddocs/For each file:
- Read the entire file
- Evaluate against each rule in the Documentation Quality Rules section
- Propose concrete improvements — rewrite sections that violate the rules
- Apply changes directly to the files
- Report a summary of changes per file to the user
Do NOT delete or remove existing documentation files. Only improve their content.
审阅目录下的每个文件，并根据下方定义的文档质量规则提出优化建议。
docs/.md针对每个文件：
- 完整读取文件
- 对照文档质量规则的每条进行评估
- 提出具体优化方案——重写违反规则的章节
- 直接应用修改到文件中
- 向用户汇报每个文件的修改摘要
请勿删除或移除现有文档文件，仅优化其内容。
Step 7: Identify Missing Documentation
步骤7：识别缺失的文档
Cross-reference the codebase exploration (Step 1) with the existing files to detect critical or important features that are not documented.
docs/- Inventory documented topics — List what each file covers
docs/*.md - Inventory codebase features — From Step 1, list key features, modules, APIs, integrations, workflows, and architectural decisions found in the code
- Gap analysis — Compare the two lists. Flag any feature that is:
- Used in production code but has no corresponding documentation
- A core business workflow (e.g., authentication, data pipeline, external integrations)
- An architectural decision that would confuse a new team member without context
- A complex module with non-obvious behavior
- Propose new documentation files — For each gap, present to the user:
- Suggested file name (e.g., )
docs/authentication-flow.md - One-line description of what it would cover
- Priority: Critique (blocks understanding of the system) or Important (significantly helps onboarding)
- Suggested file name (e.g.,
- Ask the user which proposed files to create
- Generate approved files following the Documentation Quality Rules — in French, concise, PO-oriented, with Mermaid diagrams where useful
将步骤1的代码库探索结果与现有文件进行交叉对比，检测未被文档化的关键或重要功能。
docs/- 盘点已文档化的主题——列出每个文件覆盖的内容
docs/*.md - 盘点代码库功能——从步骤1中，列出在代码中发现的关键功能、模块、API、集成、工作流和架构决策
- 差距分析——对比两个列表，标记以下类型的功能：
- 生产代码中使用但无对应文档的功能
- 核心业务工作流（如认证、数据管道、外部集成）
- 无上下文说明会让新团队成员困惑的架构决策
- 行为不直观的复杂模块
- 向用户提议新文档文件——针对每个差距，向用户展示：
- 建议的文件名（如）
docs/authentication-flow.md - 一行描述该文件将覆盖的内容
- 优先级：关键（阻碍对系统的理解）或重要（显著帮助新成员融入）
- 建议的文件名（如
- 询问用户要创建哪些提议的文件
- 根据文档质量规则生成获批的文件——法语内容、简洁、面向产品负责人、必要时配有Mermaid图表
Step 8: Confirm
步骤8：确认
Summarize to the user what was done:
- Which files were created vs. updated
- Key sections included
- Any information that could not be determined and was left as placeholder
- Documentation review: list of files reviewed with a one-line summary of improvements applied per file
docs/ - Missing documentation: list of new doc files proposed, which were approved and created
向用户总结已完成的工作：
- 创建和更新了哪些文件
- 包含的关键章节
- 无法确定的信息及留作占位符的内容
- 文档审阅：列出已审阅的文件及每个文件的修改摘要
docs/ - 缺失文档：列出提议的新文档文件、获批并创建的文件
README Template
README模板
The generated README.md must follow this structure:
生成的README.md必须遵循以下结构：
# [Project Name]
# [Project Name]# [项目名称]
# [项目名称]Short description (1-2 sentences, non-technical). Explain what the product does and who it's for.
简短描述（1-2句话，非技术向）。说明产品的用途和受众。
## Table des matières
## Table des matières## Table des matières
## Table des matièresAuto-generated table of contents listing all README sections with anchor links. Include a sub-section for technical documentation:
markdown
undefined自动生成的目录，列出README的所有章节及锚点链接。包含技术文档子章节：
markdown
undefinedTable des matières
Table des matières
Documentation technique
Documentation technique
| Document | Description |
|---|---|
| Architecture REST & WebSocket | Description de l'architecture API |
| Schéma de base de données | Structure des tables et relations |
**Important:** The description for each doc file must be deduced from actually reading the file content (Step 1), not invented.| Document | Description |
|---|---|
| Architecture REST & WebSocket | Description de l'architecture API |
| Schéma de base de données | Structure des tables et relations |
**重要提示**：每个文档文件的描述必须从实际读取的文件内容（步骤1）中推导，而非凭空捏造。## À quoi sert ce produit ?
## À quoi sert ce produit ?## À quoi sert ce produit ?
## À quoi sert ce produit ?Business value explanation. 3-5 bullet points describing what the product enables, from the user's perspective.
业务价值说明。3-5个项目符号，从用户视角描述产品能实现什么。
## Fonctionnalités principales
## Fonctionnalités principales## Fonctionnalités principales
## Fonctionnalités principalesList of features oriented toward user benefit. Use bullet points. Focus on what the user can do, not how it's implemented.
面向用户收益的功能列表。使用项目符号，聚焦用户能做什么，而非实现方式。
## Comment ça fonctionne
## Comment ça fonctionne## Comment ça fonctionne
## Comment ça fonctionneHigh-level architecture diagram using Mermaid or , followed by a short textual explanation.
graph LRgraph TDmarkdown
```mermaid
graph LR
A[Utilisateur] --> B[Application Web]
B --> C[API Backend]
C --> D[Base de données]
C --> E[Services externes]
`` `
L'utilisateur interagit avec l'application web, qui communique avec l'API backend. Le backend gère la logique métier et stocke les données en base.使用Mermaid 或的高层架构图，后跟简短文字说明。
graph LRgraph TDmarkdown
```mermaid
graph LR
A[Utilisateur] --> B[Application Web]
B --> C[API Backend]
C --> D[Base de données]
C --> E[Services externes]L'utilisateur interagit avec l'application web, qui communique avec l'API backend. Le backend gère la logique métier et stocke les données en base.
undefined## Environnements
## Environnements## Environnements
## EnvironnementsTable with environment information:
markdown
| Environnement | URL | Description |
|---------------|-----|-------------|
| Développement | `http://localhost:3000` | Environnement local |
| Staging | `https://staging.example.com` | Pré-production |
| Production | `https://app.example.com` | Environnement de production |Use actual URLs if found in config, otherwise use realistic placeholders.
包含环境信息的表格：
markdown
| Environnement | URL | Description |
|---------------|-----|-------------|
| Développement | `http://localhost:3000` | Environnement local |
| Staging | `https://staging.example.com` | Pré-production |
| Production | `https://app.example.com` | Environnement de production |若在配置中找到实际URL则使用，否则使用合理的占位符。
## Déploiement
## Déploiement## Déploiement
## DéploiementCI/CD pipeline as a Mermaid diagram, followed by a short explanation.
graph LR使用Mermaid 图展示CI/CD流水线，后跟简短说明。
graph LR## Stack technique
## Stack technique## Stack technique
## Stack techniqueCategorized tech stack in 3-5 lines:
markdown
- **Frontend :** React, TypeScript, TailwindCSS
- **Backend :** Node.js, NestJS, TypeORM
- **Base de données :** PostgreSQL
- **Hébergement :** Docker, GitLab CI/CD分类列出技术栈，3-5行：
markdown
- **Frontend :** React, TypeScript, TailwindCSS
- **Backend :** Node.js, NestJS, TypeORM
- **Base de données :** PostgreSQL
- **Hébergement :** Docker, GitLab CI/CD## Documentation complémentaire
## Documentation complémentaire## Documentation complémentaire
## Documentation complémentaireLinks to files if they exist. If no docs folder exists, omit this section.
docs/若存在文件则添加链接。若无docs文件夹则省略此章节。
docs/Mermaid Diagram Rules
Mermaid图表规则
- Labels in French — All node labels and edge labels must be in French
- Maximum 8-10 nodes per diagram — Keep diagrams readable and high-level
- Allowed types: ,
graph,flowchartsequenceDiagram - Forbidden types: ,
classDiagram,erDiagram(too technical for PO audience)stateDiagram - Textual explanation under every diagram — The diagram alone is not enough
- Simple and clear — Avoid nested subgraphs, complex conditions, or technical details
- 标签用法语——所有节点标签和边标签必须为法语
- 每个图表最多8-10个节点——保持图表可读性和高层视角
- 允许的类型：、
graph、flowchartsequenceDiagram - 禁止的类型：、
classDiagram、erDiagram（对产品负责人受众来说过于技术化）stateDiagram - 每个图表下方配有文字说明——仅图表不足以说明问题
- 简洁清晰——避免嵌套子图、复杂条件或技术细节
Example Mermaid Diagram
示例Mermaid图表
mermaid
graph LR
A[Développeur] -->|Push du code| B[GitLab CI]
B -->|Tests auto| C{Tests OK ?}
C -->|Oui| D[Déploiement Staging]
C -->|Non| E[Notification erreur]
D -->|Validation manuelle| F[Déploiement Production]Ce diagramme illustre le pipeline de déploiement continu. Lorsqu'un développeur pousse du code, les tests automatiques se lancent. Si les tests réussissent, le code est déployé en staging puis, après validation manuelle, en production.
mermaid
graph LR
A[Développeur] -->|Push du code| B[GitLab CI]
B -->|Tests auto| C{Tests OK ?}
C -->|Oui| D[Déploiement Staging]
C -->|Non| E[Notification erreur]
D -->|Validation manuelle| F[Déploiement Production]Ce diagramme illustre le pipeline de déploiement continu. Lorsqu'un développeur pousse du code, les tests automatiques se lancent. Si les tests réussissent, le code est déployé en staging puis, après validation manuelle, en production.
French Writing Guidelines
法语写作指南
- Natural and professional French, use "vous" (vouvoiement)
- Avoid anglicisms except for technical terms without French equivalent (WebSocket, Docker, CI/CD, API, etc.)
- Short sentences: maximum 20 words per sentence
- Bullet points preferred over long paragraphs
- No technical jargon — Write for a Product Owner, not a developer
- No code blocks in the README (except Mermaid diagrams)
- Acronyms explained at first occurrence (ex: "CI/CD (Intégration et Déploiement Continus)")
- Consistent terminology throughout the document
- 自然且专业的法语，使用“vous”（正式称谓）
- 避免英语外来词，除非没有法语等效术语（如WebSocket、Docker、CI/CD、API等）
- 短句：每句最多20个单词
- 优先使用项目符号而非长段落
- 无技术行话——为产品负责人写作，而非开发者
- README中无代码块（Mermaid图表除外）
- 首字母缩写首次出现时需解释（如“CI/CD (Intégration et Déploiement Continus)”）
- 术语一致——整个文档中术语保持统一
Documentation Quality Rules
文档质量规则
These rules apply when reviewing and improving files in . Each doc file must comply.
docs/这些规则适用于审阅和优化下的文件，每个文档文件必须遵守。
docs/Language
语言
- Written in French — All content must be in French
- Exception: Technical terms without French equivalent (API, WebSocket, Docker, CI/CD, JSON, etc.) stay in English
- Vouvoiement — Use "vous" consistently
- Acronyms explained at first occurrence
- 用法语撰写——所有内容必须为法语
- 例外：无法语等效术语的技术词汇（API、WebSocket、Docker、CI/CD、JSON等）保留英文
- 正式称谓——始终使用“vous”
- 首字母缩写首次出现时需解释
Conciseness
简洁性
- Short sentences — Maximum 20 words per sentence
- Bullet points over paragraphs — Prefer structured lists to long blocks of text
- No filler — Remove introductions like "Dans cette section, nous allons voir..." — go straight to the point
- One idea per paragraph — If a paragraph covers two topics, split it
- 短句——每句最多20个单词
- 优先使用项目符号而非段落——结构化列表比长文本块更易读
- 无冗余内容——删除“在本节中，我们将看到...”这类引言，直接切入主题
- 每段一个核心思想——若一段包含两个主题则拆分
Readability
可读性
- Scan-friendly structure — Use headings (H2, H3) liberally so the reader can jump to what they need
- Bold key terms on first mention in a section
- Tables for comparisons — When comparing options, features, or configurations, use a table instead of prose
- Code examples short and focused — Maximum 10-15 lines per code block, with a one-line comment explaining the purpose
- 便于扫描的结构——大量使用标题（H2、H3），让读者能跳转到所需内容
- 章节中首次提及的关键术语加粗
- 对比内容使用表格——当比较选项、功能或配置时，使用表格而非散文
- 代码示例简短聚焦——每个代码块最多10-15行，带有一行注释说明用途
Audience
受众
- Product Owner oriented by default — Explain the "what" and "why" before the "how"
- Technical depth when the subject requires it — Parsers, protocols, database schemas, API contracts can and should include technical details
- Label technical sections clearly — Use a heading or callout (e.g., "> Détail technique") so non-technical readers can skip them
- 默认面向产品负责人——先解释“是什么”和“为什么”，再解释“怎么做”
- 主题需要时增加技术深度——解析器、协议、数据库模式、API契约可以且应该包含技术细节
- 技术章节需明确标记——使用标题或提示框（如“> 技术细节”），让非技术读者可以跳过
Mermaid Diagrams
Mermaid图表
- Prefer a diagram over a long description — If a concept involves a flow, sequence, or architecture, use Mermaid instead of (or in addition to) text
- Follow the Mermaid Diagram Rules defined above (French labels, max 8-10 nodes, allowed types, textual explanation below)
- Replace verbose explanations — If a section has 5+ lines describing a flow or architecture, consider replacing or supplementing with a diagram
- 优先使用图表替代长描述——若某个概念涉及流程、序列或架构，使用Mermaid替代（或补充）文本
- 遵循上述Mermaid图表规则（法语标签、最多8-10个节点、允许的类型、下方配有文字说明）
- 替换冗长的解释——若某章节有5行以上描述流程或架构，考虑用图表替换或补充
Structure
结构
- Every doc file must start with a H1 title matching the file name / topic
- A short intro paragraph (1-2 sentences) right after the title explaining what this document covers and who it's for
- Logical section order: Context/Purpose → How it works → Details/Reference → Examples
- 每个文档文件必须以与文件名/主题匹配的H1标题开头
- 标题后紧跟简短引言段落（1-2句话），说明该文档覆盖的内容和受众
- 逻辑章节顺序：背景/用途 → 工作原理 → 细节/参考 → 示例
Create vs. Update Mode
创建与更新模式
Creation Mode (no existing README.md)
创建模式（无现有README.md）
Generate all sections from scratch based on codebase exploration.
基于代码库探索结果从头生成所有章节。
Update Mode (README.md already exists)
更新模式（已存在README.md）
- Read the existing README.md
- Identify which sections match the template
- Update factual sections (stack, architecture, features, environments) with current codebase state
- Preserve custom sections that don't match the template — they may have been added manually by the team
- Update the table of contents to reflect all sections
- 读取现有README.md
- 识别与模板匹配的章节
- 根据当前代码库状态更新事实性章节（技术栈、架构、功能、环境）
- 保留与模板不匹配的自定义章节——这些可能是团队手动添加的
- 更新目录以反映所有章节
CLAUDE.md Generation
CLAUDE.md生成
Only generate if does not exist at the project root.
CLAUDE.mdExplore the codebase to deduce and include:
- Project overview: One-paragraph summary of what the project is
- Tech stack and key dependencies with versions
- Project structure: Key directories and their purpose
- Useful commands: dev, build, test, lint, migrate, seed — with actual commands found in package.json scripts or Makefile
- Code conventions: Naming patterns, file structure patterns, architectural patterns observed (e.g., React hooks, service pattern, controller/route separation)
- Git workflow: Branch naming conventions (if observable), commit message patterns (from git log)
- Key files and directories that Claude should know about
- Gotchas and important notes specific to the project (e.g., monorepo structure, shared packages, environment variables needed)
- Patterns to follow when writing new code (deduced from existing code style)
仅当项目根目录下不存在时生成。
CLAUDE.md探索代码库以推导并包含以下内容：
- 项目概述：一段总结项目用途的文字
- 技术栈和关键依赖及版本
- 项目结构：关键目录及其用途
- 实用命令：dev、build、test、lint、migrate、seed——从package.json脚本或Makefile中获取实际命令
- 代码规范：命名模式、文件结构模式、观察到的架构模式（如React hooks、服务模式、控制器/路由分离）
- Git工作流：分支命名规范（若可观察到）、提交消息模式（从git log中获取）
- Claude需要了解的关键文件和目录
- 项目特有的注意事项和重要提示（如单体仓库结构、共享包、所需的环境变量）
- 编写新代码时需遵循的模式（从现有代码风格中推导）
AGENT.md Generation
AGENT.md生成
Only generate if does not exist at the project root.
AGENT.mdExplore the codebase to deduce and include:
- Project summary and objective (2-3 sentences)
- Monorepo structure and dependencies between packages (if applicable)
- Essential commands: install, dev, build, test, migrate, seed — with actual commands
- Code conventions to respect when making automated changes
- Development workflow: Branches, commits, CI/CD pipeline
- Important notes for automated modifications: What to avoid, what to always do, critical files not to modify
仅当项目根目录下不存在时生成。
AGENT.md探索代码库以推导并包含以下内容：
- 项目总结和目标（2-3句话）
- 单体仓库结构和包之间的依赖关系（若适用）
- 必要命令：install、dev、build、test、migrate、seed——实际命令
- 进行自动化修改时需遵守的代码规范
- 开发工作流：分支、提交、CI/CD流水线
- 自动化修改的重要注意事项：需要避免的操作、必须执行的操作、不可修改的关键文件
Example Output
示例输出
Here is a condensed example of the expected README format:
markdown
undefined以下是预期README格式的精简示例：
markdown
undefinedOverwatch
Overwatch
Plateforme de supervision applicative permettant de surveiller la santé et les performances de vos applications en temps réel.
Plateforme de supervision applicative permettant de surveiller la santé et les performances de vos applications en temps réel.
Table des matières
Table des matières
Documentation technique
Documentation technique
| Document | Description |
|---|---|
| Architecture API | Vue d'ensemble de l'architecture REST |
| Document | Description |
|---|---|
| Architecture API | Vue d'ensemble de l'architecture REST |
À quoi sert ce produit ?
À quoi sert ce produit ?
- Surveiller la disponibilité de vos applications en continu
- Recevoir des alertes en cas de dysfonctionnement
- Visualiser l'historique de santé via des tableaux de bord
- Gérer les environnements de déploiement (dev, staging, production)
- Centraliser la supervision de toutes vos applications
- Surveiller la disponibilité de vos applications en continu
- Recevoir des alertes en cas de dysfonctionnement
- Visualiser l'historique de santé via des tableaux de bord
- Gérer les environnements de déploiement (dev, staging, production)
- Centraliser la supervision de toutes vos applications
Fonctionnalités principales
Fonctionnalités principales
- Tableau de bord temps réel — Vue d'ensemble de la santé de toutes vos applications
- Historique de santé — Graphiques et métriques sur les performances passées
- Gestion multi-environnements — Suivi par environnement de déploiement
- Alertes automatiques — Notification en cas de dégradation du service
- Tableau de bord temps réel — Vue d'ensemble de la santé de toutes vos applications
- Historique de santé — Graphiques et métriques sur les performances passées
- Gestion multi-environnements — Suivi par environnement de déploiement
- Alertes automatiques — Notification en cas de dégradation du service
Comment ça fonctionne
Comment ça fonctionne
``mermaid graph LR A[Utilisateur] --> B[Interface Web] B --> C[API NestJS] C --> D[Base PostgreSQL] C --> E[Vérification de santé] E --> F[Applications surveillées]L'utilisateur accède à l'interface web pour consulter l'état de ses applications. L'API backend effectue des vérifications de santé régulières et stocke les résultats en base de données.
mermaid
graph LR
A[Utilisateur] --> B[Interface Web]
B --> C[API NestJS]
C --> D[Base PostgreSQL]
C --> E[Vérification de santé]
E --> F[Applications surveillées]L'utilisateur accède à l'interface web pour consulter l'état de ses applications. L'API backend effectue des vérifications de santé régulières et stocke les résultats en base de données.
Stack technique
Stack technique
- Frontend : React 18, TypeScript, TailwindCSS
- Backend : NestJS, TypeORM, PostgreSQL
- Infrastructure : Docker, GitLab CI/CD
---- Frontend : React 18, TypeScript, TailwindCSS
- Backend : NestJS, TypeORM, PostgreSQL
- Infrastructure : Docker, GitLab CI/CD
---Checklist
检查清单
Before saving the README.md, verify:
- All content is in French (except technical terms)
- Table of contents matches all sections with correct anchor links
- Documentation technique sub-section lists all files with descriptions deduced from content
docs/*.md - Mermaid diagrams are valid and have max 8-10 nodes
- Mermaid diagrams use only allowed types (graph, flowchart, sequenceDiagram)
- Every diagram has a textual explanation below it
- Labels in Mermaid diagrams are in French
- No code blocks (except Mermaid)
- Sentences are under 20 words
- Vouvoiement used consistently
- Acronyms explained at first occurrence
- CLAUDE.md generated only if it did not exist
- AGENT.md generated only if it did not exist
- All files reviewed against Documentation Quality Rules
docs/*.md - Docs are in French, concise, scan-friendly, and PO-oriented
- Mermaid diagrams added where they replace verbose explanations
- Gap analysis performed: codebase features vs. existing documentation
- Missing critical/important docs proposed to user before creation
- New doc files follow Documentation Quality Rules
- User informed of what was created/updated, docs improved, and new docs proposed/created
保存README.md前，请验证：
- 所有内容为法语（技术术语除外）
- 目录与所有章节匹配，锚点链接正确
- 技术文档子章节列出所有文件，描述从内容推导而来
docs/*.md - Mermaid图表有效且最多8-10个节点
- Mermaid图表仅使用允许的类型（graph、flowchart、sequenceDiagram）
- 每个图表下方配有文字说明
- Mermaid图表的标签为法语
- 无代码块（Mermaid除外）
- 句子不超过20个单词
- 始终使用正式称谓“vous”
- 首字母缩写首次出现时已解释
- CLAUDE.md仅在不存在时生成
- AGENT.md仅在不存在时生成
- 所有文件已对照文档质量规则审阅
docs/*.md - 文档为法语、简洁、便于扫描、面向产品负责人
- 在替代冗长解释的地方添加了Mermaid图表
- 已执行差距分析：代码库功能 vs 现有文档
- 向用户提议缺失的关键/重要文档后再创建
- 新文档文件遵循文档质量规则
- 已告知用户创建/更新的内容、优化的文档、提议并创建的新文档