Files
pos-system/docs/en/skills/documentation.md
Ho Ngoc Hai 2640b351c3 Enhance documentation with detailed diagrams and structured flows
- Added request/response flow diagrams to api-design and api-gateway-advanced skills for better visualization of processes.
- Introduced configuration loading flow in configuration-management skill to clarify the configuration process.
- Included error propagation flow in error-handling-patterns skill to illustrate error handling across layers.
- Enhanced various skills with additional diagrams to improve understanding of complex concepts.

These updates aim to provide clearer guidance and improve the overall documentation experience for developers.
2026-01-01 23:22:54 +07:00

12 KiB

name, description
name description
documentation Guidelines for writing technical documentation in the GoodGo project. Use when creating or updating README files, guides, architecture docs, or API documentation. Ensures bilingual (EN/VI) consistency and proper structure.

Documentation Writing Guidelines

Documentation Structure

The project follows a structured documentation hierarchy organized by location and content type:

docs/
├── en/                          # English documentation
│   ├── guides/                  # How-to guides
│   │   ├── getting-started.md
│   │   ├── development.md
│   │   ├── deployment.md
│   │   └── local-development.md
│   ├── architecture/            # System design docs
│   │   ├── system-design.md
│   │   └── service-communication.md
│   ├── api/                     # API documentation
│   │   └── openapi/
│   └── runbooks/                # Operational guides
│       ├── incident-response.md
│       └── rollback-procedure.md
├── vi/                          # Vietnamese documentation (mirror structure)
└── README.md                    # Documentation index

Documentation Structure Diagram

The following diagram illustrates where different types of documentation should be placed:

graph TD
    Start[Documentation Need] --> TypeDecision{Documentation Type?}
    
    TypeDecision -->|Project-Level| ProjectDocs[Project-Level Documentation]
    TypeDecision -->|Service/Package| ServiceDocs[Service/Package Documentation]
    TypeDecision -->|Deployment| DeployDocs[Deployment Documentation]
    TypeDecision -->|Infrastructure| InfraDocs[Infrastructure Documentation]
    
    ProjectDocs --> ProjectLoc["docs/en/<br/>docs/vi/"]
    ProjectLoc --> ProjectSub{Content Type?}
    ProjectSub -->|Guides| GuidesLoc["guides/<br/>(getting-started.md,<br/>deployment.md)"]
    ProjectSub -->|Architecture| ArchLoc["architecture/<br/>(system-design.md)"]
    ProjectSub -->|API Specs| APILoc["api/openapi/<br/>(*.yaml)"]
    ProjectSub -->|Runbooks| RunbookLoc["runbooks/<br/>(incident-response.md)"]
    
    ServiceDocs --> ServiceLoc["services/[name]/README.md<br/>packages/[name]/README.md"]
    ServiceLoc --> ServiceFormat[Format: Side-by-side bilingual]
    
    DeployDocs --> DeployLoc["deployments/[env]/README.md"]
    DeployLoc --> DeployFormat[Format: Technical, operations-focused]
    
    InfraDocs --> InfraLoc["infra/[component]/README.md"]
    InfraLoc --> InfraFormat[Format: Side-by-side bilingual]
    
    style ProjectDocs fill:#e1f5ff
    style ServiceDocs fill:#fff4e1
    style DeployDocs fill:#ffe1f5
    style InfraDocs fill:#e1ffe1

Where to Put Documentation

Project-Level Documentation

  • Location: docs/en/ and docs/vi/
  • Examples: Getting started, deployment guides, architecture
  • Format: Markdown with bilingual support

Service/Package Documentation

  • Location: services/[service-name]/README.md or packages/[package-name]/README.md
  • Content: Service-specific setup, API endpoints, configuration
  • Format: Single README with bilingual sections

Deployment Documentation

  • Location: deployments/[environment]/README.md
  • Content: Environment-specific deployment instructions
  • Format: Technical, operations-focused

Infrastructure Documentation

  • Location: infra/[component]/README.md
  • Content: Infrastructure component configuration and usage
  • Examples: infra/traefik/README.md, infra/observability/README.md

Bilingual Documentation Rules

Format Options

Option 1: Side-by-side (Recommended for short content)

# Service Name / Tên Dịch Vụ

This is a description.
Đây là mô tả.

Option 2: Separate files (Recommended for long content)

docs/
├── en/
│   └── guides/
│       └── deployment.md
└── vi/
    └── guides/
        └── deployment.md

Option 3: Sections (For mixed content)

# English Section

Content in English...

---

# Phần Tiếng Việt

Nội dung bằng tiếng Việt...

When to Use Each Format

  • Side-by-side: README files, short guides, configuration docs
  • Separate files: Long guides (>200 lines), architecture docs, runbooks
  • Sections: API documentation, technical specifications

Bilingual Format Decision Flow

Use the following decision tree to choose the appropriate bilingual format:

flowchart TD
    Start[Creating Documentation] --> CheckLength{Content Length?}
    
    CheckLength -->|Short<br/>< 200 lines| CheckLocation{Document Location?}
    CheckLength -->|Long<br/>> 200 lines| SeparateFiles[Use Separate Files Format]
    
    CheckLocation -->|README files<br/>Service/Package docs<br/>Infrastructure docs| SideBySide[Use Side-by-side Format]
    CheckLocation -->|docs/guides/<br/>Short configuration docs| SideBySide
    
    CheckLength -->|Medium| CheckType{Content Type?}
    CheckType -->|API Documentation<br/>Technical Specifications| Sections[Use Sections Format]
    CheckType -->|Mixed Content| Sections
    
    SeparateFiles --> SeparateAction["Create docs/en/[path]/file.md<br/>Create docs/vi/[path]/file.md<br/>(Mirror structure)"]
    SideBySide --> SideBySideAction["Single file with<br/>EN / VI inline<br/>Example: 'Title / Tiêu Đề'"]
    Sections --> SectionsAction["Single file with<br/>--- separator<br/>EN section then VI section"]
    
    SeparateAction --> Done[Documentation Complete]
    SideBySideAction --> Done
    SectionsAction --> Done
    
    style SideBySide fill:#e1f5ff
    style SeparateFiles fill:#fff4e1
    style Sections fill:#ffe1f5
    style Done fill:#e1ffe1

Documentation Templates

Service README Template

# Service Name / Tên Dịch Vụ

> **EN**: Brief description in English
> **VI**: Mô tả ngắn gọn bằng tiếng Việt

## Features / Tính Năng

- Feature 1 / Tính năng 1
- Feature 2 / Tính năng 2

## Prerequisites / Yêu Cầu

- Node.js 20+
- PostgreSQL (Neon)
- Redis

## Quick Start / Bắt Đầu Nhanh

```bash
# Install dependencies / Cài đặt dependencies
pnpm install

# Setup environment / Thiết lập môi trường
cp .env.example .env

# Start service / Khởi động service
pnpm dev

Configuration / Cấu Hình

Variable Description / Mô Tả Default Required
PORT Server port / Cổng server 5000 No

API Endpoints

See API Documentation

Development / Phát Triển

[Development instructions...]

Testing / Kiểm Thử

pnpm test

Deployment / Triển Khai

See Deployment Guide


### Guide Template (docs/en/guides/)

```markdown
# Guide Title

**Last Updated**: 2024-01-01  
**Difficulty**: Beginner/Intermediate/Advanced

## Overview

Brief overview of what this guide covers.

## Prerequisites

- Requirement 1
- Requirement 2

## Step-by-Step Instructions

### Step 1: Title

Description and commands...

```bash
command here

Step 2: Title

Description and commands...

Troubleshooting

Issue 1

Problem: Description Solution: Steps to fix

Next Steps

  • Link to related guide
  • Link to another resource

Resources


### Architecture Document Template

```markdown
# Component Architecture

## Overview

High-level description of the component.

## Architecture Diagram

```mermaid
graph TD
    A[Component A] --> B[Component B]
    B --> C[Component C]

Components

Component Name

Purpose: What it does
Technology: Tech stack
Dependencies: What it depends on

Data Flow

  1. Step 1
  2. Step 2
  3. Step 3

Design Decisions

Decision 1

Context: Why this decision was needed
Decision: What was decided
Consequences: Impact of the decision

Deployment

How this component is deployed.

Monitoring

How to monitor this component.


## Writing Style Guidelines

### Technical Writing Principles

1. **Clear and Concise**: Use simple language, avoid jargon
2. **Action-Oriented**: Start with verbs (Install, Configure, Deploy)
3. **Structured**: Use headings, lists, and tables
4. **Examples**: Provide code examples and commands
5. **Visual**: Use diagrams where helpful

### Code Examples

```markdown
# Good: With context and explanation
Install dependencies using pnpm:

```bash
pnpm install

Bad: No context

pnpm install

### Commands

- Always show the full command
- Include comments for clarity
- Show expected output when helpful

```bash
# Good
docker-compose up -d
# Expected output: Creating network, Starting containers...

# Bad
docker-compose up
  • Use relative links for internal docs
  • Use descriptive link text (not "click here")
# Good
See the [Deployment Guide](../guides/deployment.md) for details.

# Bad
Click [here](../guides/deployment.md) for more info.

Documentation Checklist

Before Writing

  • Determine correct location (docs/ vs service README)
  • Choose bilingual format (side-by-side vs separate)
  • Review existing docs for consistency

While Writing

  • Use clear, concise language
  • Include code examples
  • Add diagrams where helpful
  • Provide troubleshooting section
  • Link to related documentation

After Writing

  • Test all commands and code examples
  • Check all links work
  • Ensure bilingual consistency
  • Update documentation index (docs/README.md)
  • Request review from team

Common Mistakes to Avoid

Don't

  • Write documentation in only one language
  • Put detailed guides in service README (use docs/)
  • Use absolute paths in links
  • Assume prior knowledge
  • Skip code examples
  • Forget to update when code changes

Do

  • Maintain bilingual documentation
  • Use appropriate location (docs/ vs README)
  • Use relative links
  • Explain prerequisites
  • Provide working examples
  • Keep docs up-to-date with code

Documentation Maintenance

When to Update Documentation

  • New feature added
  • API changes
  • Configuration changes
  • Deployment process changes
  • Bug fixes affecting usage
  • Architecture changes

Version Documentation

For major changes, consider:

  • Adding "Last Updated" date
  • Creating versioned docs (v1/, v2/)
  • Maintaining changelog

Tools and Resources

Markdown Tools

  • Mermaid: For diagrams
  • Tables Generator: For complex tables
  • Markdown Linter: For consistency

Documentation Testing

# Check for broken links
find docs -name "*.md" -exec markdown-link-check {} \;

# Lint markdown files
markdownlint docs/**/*.md

Examples from Project

Good Documentation Examples

  • docs/en/guides/getting-started.md - Clear step-by-step guide
  • services/_template/README.md - Comprehensive service README
  • deployments/local/README.md - Operations-focused deployment guide

Documentation Locations Reference

Content Type Location Format
Getting Started docs/en/guides/getting-started.md Separate files
Service Setup services/[name]/README.md Side-by-side
Deployment docs/en/guides/deployment.md Separate files
Architecture docs/en/architecture/ Separate files
API Specs docs/en/api/openapi/ OpenAPI YAML
Runbooks docs/en/runbooks/ Separate files
Infrastructure infra/[component]/README.md Side-by-side
Environment Config deployments/[env]/README.md Technical only

Quick Reference

File Naming

  • Use kebab-case: getting-started.md
  • Be descriptive: local-development.md not dev.md
  • Match EN and VI filenames

Heading Levels

# H1: Document Title (only one per file)
## H2: Major Sections
### H3: Subsections
#### H4: Details (use sparingly)

Bilingual Patterns

# Pattern 1: Inline
Description / Mô tả

# Pattern 2: After slash
PORT=5000  # Server port / Cổng server

# Pattern 3: Table
| Variable | Description / Mô Tả |

# Pattern 4: Code comments
# EN: Install dependencies
# VI: Cài đặt dependencies
pnpm install