<p align="center">
  <a href="https://product.example.com">
    <img src="./path/to/logo.svg" alt="Product name" width="120">
  </a>
</p>

<h1 align="center">Product name</h1>

<p align="center">
  A concise product promise written for the person who will use it.
</p>

<p align="center">
  <a href="https://product.example.com">Website</a> ·
  <a href="https://docs.example.com">Documentation</a> ·
  <a href="https://product.example.com/download">Download</a> ·
  <a href="https://product.example.com/support">Support</a> ·
  <a href="https://github.com/owner/repository/releases">Releases</a>
</p>

Product name helps **target user** accomplish **important job**. Explain the core experience,
platforms, privacy model, and commercial or maturity status in a short introduction.

> **Status:** State whether the product is experimental, in preview, beta, generally available, or
> private. Mention the most important compatibility or safety limitation.

## Highlights

- **Primary workflow** — describe the outcome and why it is useful.
- **Distinctive capability** — explain what makes the product meaningfully different.
- **Privacy or safety property** — state what remains local, what is sent to a service, or how the
  product fails safely.
- **Platform experience** — list the supported platforms without overstating parity.

## See it in action

![Product name showing its primary workflow](./path/to/screenshot.webp)

Describe what the screenshot demonstrates. Use an optimized repository-owned image and useful alt
text; omit this section when no maintained visual exists.

## Get started

### Requirements

- Supported operating system or runtime
- Required account, toolchain, or service

### Install or run

```bash
# Public product: use the real download or package command.
# Contributor-only product: use the verified local setup commands.
```

Explain the first-run experience and link to the
[complete setup guide](https://docs.example.com/getting-started).

## Applications and services

| Surface     | Path                           | Purpose               | Destination                                      |
| ----------- | ------------------------------ | --------------------- | ------------------------------------------------ |
| Product app | [`apps/product`](apps/product) | Main user experience  | [Download](https://product.example.com/download) |
| Website     | [`apps/website`](apps/website) | Marketing and support | [Visit](https://product.example.com)             |
| API         | [`apps/api`](apps/api)         | Product backend       | [API docs](https://docs.example.com/api)         |

## Documentation

- [User guide](https://docs.example.com)
- [Architecture](docs/architecture.md)
- [Privacy](docs/privacy.md)
- [Deployment](docs/deployment.md)
- [Release process](docs/release.md)
- [Support](https://product.example.com/support)

## Development

```bash
pnpm install
pnpm dev
pnpm test
pnpm check
pnpm build
```

Identify the canonical quality command, local URLs, required services, and environment template.
Never place real credentials in the README.

## Privacy and security

Explain where user data lives, which external services receive it, and the responsible security
reporting path. Link to detailed policies instead of replacing them with vague claims.

## Distribution

Explain how releases reach users and link to the release runbook. Keep signing, notarization,
store, deployment, and rollback details in maintained documentation when they are substantial.

## Support

Link to the correct support channel, issue tracker, feedback form, or private owner process. State
what information a useful report should include and what sensitive information must be omitted.

## License

State the exact open-source license, proprietary terms, or source-availability boundary and link to
the root license file.
