docs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

README 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

docs/

directory. Also generates CLAUDE.md and AGENT.md if they don't exist.

生成（或更新）面向产品负责人（Product Owner）的法语版README.md，内容简洁并配有Mermaid图表。审核并完善

docs/

目录下的所有技术文档。如果CLAUDE.md和AGENT.md不存在，也会生成这两个文件。

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
```
,
```
Cargo.toml
```
, or equivalent at root and in sub-packages (monorepo)
Project structure: List top-level directories and key files to understand the architecture
Documentation: Check for
```
docs/
```
directory. Read the first 20-30 lines of each
.md
file in
docs/
to deduce a short French description (one line) for each — this will be used in the Table of Contents

CI/CD: Look for

.github/workflows/

.gitlab-ci.yml

Jenkinsfile

Dockerfile

docker-compose.yml

Database: Look for migrations, schemas, Prisma/TypeORM/Sequelize config
Routes/Controllers: Scan for route definitions, API endpoints, controllers
Git info: Run
```
git log --oneline -10
```
and
```
git remote -v
```
to understand recent activity and hosting
Environment: Look for
```
.env.example
```
, environment configuration files

全面探索项目以了解其用途、架构和技术栈：

包清单：读取根目录及子包（单体仓库）下的
```
package.json
```
、
```
composer.json
```
、
```
pyproject.toml
```
、
```
Cargo.toml
```
或等效文件
项目结构：列出顶层目录和关键文件以理解架构
现有文档：检查
```
docs/
```
目录。读取
docs/
下每个
.md
文件的前20-30行，为每个文件推导一行法语描述——将用于目录部分

CI/CD配置：查找

.github/workflows/

、

.gitlab-ci.yml

、

Jenkinsfile

、

Dockerfile

、

docker-compose.yml

数据库相关：查找迁移文件、数据库 schema、Prisma/TypeORM/Sequelize 配置
路由/控制器：扫描路由定义、API端点、控制器文件
Git信息：执行
```
git log --oneline -10
```
和
```
git remote -v
```
以了解近期活动和代码托管情况
环境配置：查找
```
.env.example
```
及其他环境配置文件

Step 2: Create or Update

步骤2：创建或更新文件

Check if
```
README.md
```
exists at the project root
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

README.md

at the project root.

将README.md保存至项目根目录。

Step 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

.md

file in the

docs/

directory and propose improvements following the Documentation Quality Rules defined below.

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

docs/

files to detect critical or important features that are not documented.

Inventory documented topics — List what each
```
docs/*.md
```
file covers
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)
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
```
  ）
- 一行描述文件覆盖的内容
- 优先级：关键（阻碍对系统的理解）或重要（显著帮助上手）
询问用户：选择要创建哪些提议的文件
生成获批文件——遵循文档质量规则，用法语编写，内容简洁、面向PO，必要时添加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
```
docs/
```
files reviewed with a one-line summary of improvements applied per file
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]

# [项目名称]

Short description (1-2 sentences, non-technical). Explain what the product does and who it's for.

简短描述（1-2句话，非技术向）。说明产品用途和目标用户。

## Table des matières

## 目录

Auto-generated table of contents listing all README sections with anchor links. Include a sub-section for technical documentation:

markdown

undefined

自动生成的目录，列出README的所有章节及锚点链接。需包含技术文档子章节：

markdown

undefined

Table des matières

Document	Description
Architecture REST & WebSocket	Description de l'architecture API
Schéma de base de données	Structure des tables et relations

文档	描述
REST & WebSocket架构	API架构说明
数据库Schema	表结构及关系说明

```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 LR

或

graph TD

绘制的高层架构图，下方配简短文字说明。

markdown

```mermaid
graph LR
    A[用户] --> B[Web应用]
    B --> C[后端API]
    C --> D[数据库]
    C --> E[外部服务]

用户通过Web应用与后端API交互，后端处理业务逻辑并将数据存储到数据库中。

undefined

## Environnements

## 环境配置

Table 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

| 环境 | URL | 描述 |
|---------------|-----|-------------|
| 开发环境 | `http://localhost:3000` | 本地开发环境 |
| 预生产环境 | `https://staging.example.com` | 预生产验证环境 |
| 生产环境 | `https://app.example.com` | 正式生产环境 |

如果在配置文件中找到实际URL则使用，否则使用合理的占位符。

## Déploiement

## 部署流程

CI/CD pipeline as a Mermaid

graph LR

diagram, followed by a short explanation.

用Mermaid

graph LR

绘制的CI/CD流水线图，下方配简短说明。

## Stack technique

## 技术栈

Categorized 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

- **前端**：React, TypeScript, TailwindCSS
- **后端**：Node.js, NestJS, TypeORM
- **数据库**：PostgreSQL
- **部署**：Docker, GitLab CI/CD

## Documentation complémentaire

## 补充文档

Links to

docs/

files if they exist. If no docs folder exists, omit this section.

若存在

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
```
,
```
flowchart
```
,
```
sequenceDiagram
```
Forbidden types:
```
classDiagram
```
,
```
erDiagram
```
,
```
stateDiagram
```
(too technical for PO audience)
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
```
、
```
flowchart
```
、
```
sequenceDiagram
```
禁止的类型：
```
classDiagram
```
、
```
erDiagram
```
、
```
stateDiagram
```
（对PO受众过于技术化）
每个图表下方配文字说明——仅图表不足以清晰传达信息
简洁清晰——避免嵌套子图、复杂条件或技术细节

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[开发者] -->|推送代码| B[GitLab CI]
    B -->|自动测试| C{测试通过？}
    C -->|是| D[部署到预生产环境]
    C -->|否| E[发送错误通知]
    D -->|人工验证| F[部署到生产环境]

该图表展示了持续部署流水线。当开发者推送代码后，自动测试启动。若测试通过，代码会部署到预生产环境，经人工验证后再部署到生产环境。

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（持续集成与持续部署）"）
术语保持一致：全文档使用统一的术语表述

Documentation Quality Rules

文档质量规则

These rules apply when reviewing and improving files in

docs/

. Each doc file must comply.

这些规则适用于审核和优化

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标题，方便读者跳转到所需内容
关键术语首现加粗：在章节中首次出现的关键术语加粗
对比内容用表格：当对比选项、功能或配置时，使用表格而非 prose
代码示例简短聚焦：每个代码块最多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

默认面向产品负责人——先解释「是什么」和「为什么」，再讲「怎么做」
技术主题按需增加深度——解析器、协议、数据库schema、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
CLAUDE.md
does not exist at the project root.

Explore 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
AGENT.md
does not exist at the project root.

Explore 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

undefined

Overwatch

Plateforme de supervision applicative permettant de surveiller la santé et les performances de vos applications en temps réel.

实时监控应用健康状态和性能的平台。

Table des matières

Document	Description
Architecture API	Vue d'ensemble de l'architecture REST

文档	描述
API架构	REST架构概述

À 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

持续监控应用可用性
出现故障时接收告警
通过仪表盘查看历史健康数据
管理部署环境（开发、预生产、生产）
集中监控所有应用

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

实时仪表盘——所有应用健康状态的总览
健康历史记录——过往性能的图表和指标
多环境管理——按部署环境跟踪状态
自动告警——服务降级时发送通知

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[用户] --> B[Web界面]
    B --> C[NestJS API]
    C --> D[PostgreSQL数据库]
    C --> E[健康检查模块]
    E --> F[被监控的应用]

用户通过Web界面查看应用状态。后端API定期执行健康检查，并将结果存储到数据库中。

Stack technique

技术栈

Frontend : React 18, TypeScript, TailwindCSS
Backend : NestJS, TypeORM, PostgreSQL
Infrastructure : Docker, GitLab CI/CD

---

前端：React 18, TypeScript, TailwindCSS
后端：NestJS, TypeORM, PostgreSQL
基础设施：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
```
docs/*.md
```
files with descriptions deduced from content
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
```
docs/*.md
```
files reviewed against Documentation Quality Rules
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
```
文件已按文档质量规则审核
Docs为法语、简洁、易扫描且面向PO
在冗长说明处添加了Mermaid图表
已执行差距分析：代码库功能 vs 现有文档
向用户提议缺失的关键/重要文档后再创建
新文档符合文档质量规则
已向用户告知创建/更新的内容、优化的文档、提议及创建的新文档

docs

Original

Translation

README Generator

README生成器

When to Use

使用场景

The Job

执行流程

Step 1: Explore the Codebase

步骤1：探索代码库

Step 2: Create or Update

步骤2：创建或更新文件

Step 3: Generate the Content

步骤3：生成内容

Step 4: Write the File

步骤4：保存文件

Step 5: Generate CLAUDE.md and AGENT.md

步骤5：生成CLAUDE.md和AGENT.md

Step 6: Review Technical Documentation

步骤6：审核技术文档

Step 7: Identify Missing Documentation

步骤7：识别缺失的文档

Step 8: Confirm

步骤8：确认完成

README Template

README模板

# [Project Name]

# [项目名称]

## Table des matières

## 目录

Table des matières

目录

Documentation technique

技术文档

## À quoi sert ce produit ?

## 产品用途

## Fonctionnalités principales

## 核心功能

## Comment ça fonctionne

## 工作原理

## Environnements

## 环境配置

## Déploiement

## 部署流程

## Stack technique

## 技术栈

## Documentation complémentaire

## 补充文档

Mermaid Diagram Rules

Mermaid图表规则

Example Mermaid Diagram

Mermaid图表示例

French Writing Guidelines

法语写作规范

Documentation Quality Rules

文档质量规则

Language

语言要求

Conciseness

简洁性要求

Readability

可读性要求

Audience

受众适配

Mermaid Diagrams

Mermaid图表要求

Structure

结构要求

Create vs. Update Mode

创建模式与更新模式

Creation Mode (no existing README.md)

创建模式（无现有README.md）

Update Mode (README.md already exists)

更新模式（已存在README.md）

CLAUDE.md Generation

CLAUDE.md生成规则

AGENT.md Generation

AGENT.md生成规则

Example Output

`# [Project Name]`

`# [项目名称]`

`## Table des matières`

`## 目录`

`## À quoi sert ce produit ?`

`## 产品用途`

`## Fonctionnalités principales`

`## 核心功能`

`## Comment ça fonctionne`

`## 工作原理`

`## Environnements`

`## 环境配置`

`## Déploiement`

`## 部署流程`

`## Stack technique`

`## 技术栈`

`## Documentation complémentaire`

`## 补充文档`