zh-readme

Chinese README Generator

Trigger Conditions

Activate this skill when the user asks to write a README, rewrite a project introduction, complete the documentation homepage, or optimize an open-source repository showcase page.

Core Principles

Read the code and directory first, then write the README; do not guess functionality based only on the project name.
Express for Chinese developers, keep technical terms in English, and explain in natural Chinese.
The homepage must answer three questions: what this is, why it is worth using, and how to get started quickly.
Prioritize real commands, real paths, and real examples; write fewer vague promotional phrases.
If the project already has a README, preserve the valid information first, then fill in the missing structure.
If the project includes an official website or documentation site, the README must provide a unified, clickable official entry link to avoid inconsistency between the README / official website / Issue template addresses.
The project introduction page should include social proof signals as much as possible (such as Stars, featured counts, update time, representative scenarios) to help visitors quickly judge whether it is worth continuing to browse.
The first screen of the README must have the ability to support a "30-second value judgment": a one-sentence value proposition + who it is for + the shortest installation method, none of which can be missing.
If the project has an official website, Issue template, download mirror, or community entry, prioritize organizing them into a single official entry to reduce users jumping back and forth between multiple links.
If there are supporting channels such as badges, Hero copy, or the official website homepage, the README copy should remain consistent with these channels to avoid conflicts in promises and data.

First Screen Optimization Template

One-sentence value proposition: Clearly state what problem it solves, and avoid empty words like "powerful/elegant/modern".
Who it is for: Name the target users or typical scenarios, such as "for Chinese developers", "suitable for team collaboration", or "suitable for zero-configuration onboarding".
Shortest installation method: Provide a command that can be copied directly, prioritizing the native GitHub address; if there is a mirror, add it as a supplement.
Unified entry: Converge the official website, documentation, Issue solicitation, and download methods into 1 official entry as much as possible to reduce users' decision cost.
Social proof: Without piling up data, show stars, featured counts, update time, or representative cases.

Recommended Structure

# 项目名称

> 一句话价值主张，告诉用户“这东西解决什么问题”

[![Stars](badge)](link)
[![License](badge)](link)
[![Version](badge)](link)

## ✨ 项目亮点
- 亮点 1：解决什么痛点
- 亮点 2：与同类方案相比优势是什么
- 亮点 3：适合谁使用

## 📦 安装
```bash
pip install xxx
# 或 npm install / go install / cargo install

🚀 Quick Start

xxx init
xxx run

🧭 Usage Examples

from xxx import yyy

📁 Project Structure

src/: Core implementation
tests/: Tests
docs/: Extended documentation

❓ Applicable Scenarios

Scenario 1
Scenario 2
Scenario 3

🛠️ Development

make test
make lint

🤝 Contributing

PRs / Issues are welcome.

📝 License

MIT


## 工作流程
1. 检查项目结构、包管理文件、入口文件、测试目录和已有文档。
2. 提炼项目定位：目标用户、核心能力、和替代方案相比的差异点。
3. 优先补全“安装 / 快速开始 / 使用示例 / 项目结构 / 开发方式”。
4. 如果缺少真实命令，基于仓库中的 `package.json`、`pyproject.toml`、`Makefile`、`Cargo.toml` 等提取。
5. 用中文重写标题、摘要和亮点，避免“强大、优雅、现代化”这类空词。
6. 最后检查 README 是否能支持首次访问者在 30 秒内理解并开始使用。

## 输出要求
- 默认使用 Markdown。
- 标题层级清晰，emoji 适量，不要堆砌。
- 示例命令必须可复制。
- 如果信息不足，显式标注“待补充”，不要编造不存在的特性。

## 自检清单
- 是否说明了项目解决的问题？
- 是否给出最短可运行示例？
- 是否覆盖安装、使用、贡献、License？
- 是否避免了 AI 腔和空泛营销语？
- 是否让中文开发者一眼看懂？