用途：把 GitHub 仓库从“代码堆”改造成公开项目页，依次回答：这是什么、给谁用、为什么现在值得关注、能否信任、能否五分钟内试用、下一步去哪。适用于创建或重写 README、让仓库更可信或更适合发布、提升可发现性、配置 About 描述与 topics、主页、社交预览、文档、截图、badge、issue 模板与贡献文件，以及逆向分析优秀开源 README 模式。
主要能力：写作前先检查仓库名、包名、CLI 名、About 描述、主页、topics、许可证、README、LICENSE、CONTRIBUTING、CODE_OF_CONDUCT、SECURITY、CHANGELOG、issue 与 PR 模板、docs、examples、demo、assets、screenshots、包配置文件、测试与 CI、现有截图与演示等；若元数据无法自动读取，则给出人工检查清单。命名被视为独立战略层，若仓库名像内部文档、仅是分类名、过长或触发错误联想，建议先做命名。
推荐的 README 结构包括：H1 加一句具体承诺、易记标语、badge、首图或横幅、定位段落、Why、Features、Quickstart、Demo、How it works、用例、要求、配置、文档、隐私与安全、路线图或状态、贡献与许可证。快速开始尽量放在前 100–150 行，给出可复制命令与预期输出；若安装复杂，可用 Docker、在线演示、Codespaces、示例输入输出、dry-run 或截图替代。每个视觉素材需有有效 alt 文本。
输出：诊断、命名与定位建议、完整 README 或补丁、GitHub 界面设置建议（About 描述、主页、topics、社交预览）、需要创建的素材、仓库维护待办（许可证、贡献指南、issue 模板、文档、变更日志、安全与隐私）以及确定性的检查结果。
限制：必须基于真实信息，不得编造 star、下载量、生产用户、赞助、基准或关联；不得声称雇主所有权、私有代码或生产指标，除非用户明确提供可公开的安全证据。不使用夸张措辞，避免无解释的“无缝”“AI 驱动”等表述；README 不应超过 GitHub 截断限制。资料中未提供具体安装命令、代码示例或价格信息。