Use-Cliche-Data-In-Docs

# Use Cliche Data in Documentation

When updating or writing documentation for a tool, **never include real data** that was provided in prompts, local configuration, scripts, task files, or any other implementation-specific source. Documentation must use only generic, commonly recognized placeholder data that cannot expose sensitive information.

Why This Matters

A tool's source code and local configuration often contain real names, real email addresses, real organization details, and real domain names. These values are necessary for the tool to function, but they have **no place in public-facing documentation**. Leaking real data into docs can expose:

- Internal business names and contacts

- Email addresses and domain names

- Client or customer identifiers

- Account names and credentials

- Organization-specific terminology that reveals private operations

Core Rule

> **If data came from a prompt, a local file, a script, a config, or a task — it does NOT go into documentation.**

>

> Documentation examples use only well-known, fictional, or obviously placeholder data.

What Counts as Real Data

Any value that originates from:

- **Local configuration files** (e.g., `config.json`, `.env`, account modules)

- **Scripts and task files** (e.g., batch scripts, shell scripts, task runners)

- **Prompt context** (e.g., data the user supplies when asking an agent to build or update the tool)

- **Map or filter files** (e.g., JSON mappings, data extraction rules)

- **Git-ignored files** (e.g., files excluded from version control that contain environment-specific values)

Approved Placeholder Data for Documentation

Use these generic, cliche substitutes in all documentation and examples:

| Category | Approved Placeholder Examples |

| --- | --- |

| **People** | Jane Doe, John Smith, Alice, Bob |

| **Email addresses** | `jane.doe@example.com`, `admin@example.org` |

| **Organizations** | Acme Corp, Contoso, Northwind Traders |

| **Domains** | `example.com`, `example.org`, `example.net` |

| **Addresses** | 123 Main Street, Suite 100, Springfield |

| **Phone numbers** | `(555) 123-4567` |

| **Accounts / usernames** | `demo-user`, `test-account` |

| **File paths** | `accounts/acme.mjs`, `config/reports.json` |

| **Project names** | My Project, Sample App, Demo Tool |

Match the Placeholder to the Context

A placeholder is only correct if it is **plausible in the surrounding context**. A generic name that violates OS conventions, tooling norms, or the workflow being described is just as misleading as a real value. Pick substitutes that fit the platform, the tool, and the role the value plays.

Choose Paths That Match the Platform

| OS / context | Use | Avoid |

| --- | --- | --- |

| Windows, per-user data | `C:\Users\<user>\AppData\Local\AcmeApp\` | `/home/user/...`, `~/.config/...` |

| Windows, per-machine shared data | `C:\ProgramData\AcmeApp\` | `C:\Users\<user>\...` |

| Windows, temporary | `%TEMP%\acme\` or `C:\Users\<user>\AppData\Local\Temp\acme\` | `/tmp/acme/` |

| POSIX, per-user data | `~/.config/acme/`, `~/.local/share/acme/` | `C:\Users\<user>\...` |

| POSIX, temporary | `/tmp/acme/` | `%TEMP%\acme\` |

| Cross-platform examples | Show both, or use `<config-dir>/acme/` | Picking one silently |

When the surrounding text or code is OS-specific (a `.bat` file, a `.jsx` running on Windows, a `bash` snippet), the path placeholder must match that OS. When the docs are platform-neutral, either show both forms or use a clearly abstract token (`<install-dir>`, `<config-dir>`).

Match the Scope to the Workflow

The placeholder must sit in a location that makes sense for the kind of data it represents:

| Data role | Plausible placeholder location |

| --- | --- |

| Per-user logs and runtime output | User-profile folder (`C:\Users\<user>\AppData\Local\<App>\logs\`, `~/.local/state/<app>/`) |

| Per-user settings | User config folder (`%APPDATA%\<App>\`, `~/.config/<app>/`) |

| Machine-wide shared state | `C:\ProgramData\<