DX 吐槽器
对一个 GitHub 仓库的开发者体验进行吐槽。生成四个文件：roast.md、action-plan.md、ideal-readme.md、score.json。专为那些准备在 Show HN、Product Hunt 或任何“前五分钟决定成败”的场合进行产品发布的开源维护者和 DevTool 创始人打造。
关键规则（每次运行前必读）
-
在评分之前，先阅读所有三个参考文件。
references/scoring-rubric.md、references/roast-voice-guide.md、references/readme-template.md。评分标准不可协商——必须使用确切的 10 个维度。 -
每个维度都要在 0–10 分范围内评分。不能跳过。 缺失数据 = 0 分，而不是“N/A”。
-
吐槽必须引用具体发现。 逐字引用糟糕的代码行。引用文件路径。尽可能引用行号。永远不要写像“文档可以写得更好”这样笼统的套话。
-
语气很重要。 默认为
honest。根据references/roast-voice-guide.md切换语气。brutal模式有趣但不针对个人。kind模式鼓励但依然具体。 -
行动计划按影响力排序，而非严重程度。 使用
影响 × (1 / 工作量)公式。一个耗时 5 分钟却能增加 10 分的修复，优先级高于一个耗时 2 小时才能增加 12 分的修复。 -
永远不要发明 URL。 在编写
ideal-readme.md时，对于缺失的链接，使用<placeholder>语法。吐槽报告会告诉维护者自行填充。 -
永远不要提及维护者或贡献者的名字。 批评的是作品，而不是人。
-
严格输出四个文件到
dx-roast/目录。不要写入其他位置。不要跳过文件。
第一步：输入
必需：
repo— 本地路径（默认.）或https://github.com/owner/repoURL
可选：
| 参数 | 默认值 | 描述 |
|---|---|---|
tone | honest | brutal / honest / kind |
output_dir | dx-roast/ | 四个输出文件的写入位置 |
compare_to | 无 | 可选的第二个仓库 URL，用于基准比较 |
如果 repo 是一个 URL：使用 git clone <url> /tmp/dx-roast-<short-hash> 克隆到一个临时目录。在那里进行扫描。运行结束后删除临时目录。
如果 repo 是 . 或本地路径：在原地扫描，不要修改任何内容。
第二步：发现
读取以下文件（每个文件可能都不存在——需要记录缺失情况）：
README.md— 完整内容、结构（标题）、代码块、图片引用、徽章 URLCONTRIBUTING.md、CODE_OF_CONDUCT.md.github/ISSUE_TEMPLATE/、.github/PULL_REQUEST_TEMPLATE.md、.github/CODEOWNERSpackage.json（描述、首页、仓库、许可证、脚本）、pyproject.toml、Cargo.toml、go.modLICENSE（存在性和类型）docs/文件夹内容（仅文件名和大小）examples/或samples/或cookbook/文件夹.github/workflows/*.yml（仅名称和简要的 CI 存在性检查）
如果 repo 是一个 URL，还需要通过 gh 获取：
gh api repos/<owner>/<repo> --jq '{stars: .stargazers_count, forks: .forks_count, watchers: .subscribers_count, pushed_at, description, homepage, topics, default_branch}'
gh api repos/<owner>/<repo>/commits --jq '.[0].commit.author.date' | head -1
gh api repos/<owner>/<repo>/contributors --paginate --jq '[.[] | .login] | length'
如果任何 GitHub API 调用失败，应捕获异常并继续执行。
第三步：对 10 个维度进行评分
对于 references/scoring-rubric.md 中的 10 个维度中的每一个，输出 {score: 0–10, evidence: [...]}，其中 evidence 是一个包含 1–3 个短字符串的列表，说明你发现了什么。
示例：
"visual_proof": {
"score": 4,
"evidence": [
"在第 89 行发现 1 张截图（位于折页下方）",
"没有动画演示 / gif",
"没有视频"
]
}
求和所有分数 → 总分数（0–100）→ 等级（根据评分标准为 A/B/C/D/F）。
保存到 dx-roast/score.json，格式必须如下：
{
"repo": "<owner/repo 或本地路径>",
"scanned_at": "<ISO 8601 时间戳>",
"dimensions": {
"time_to_first_success": { "score": 7, "evidence": ["..."] },
"what_is_this_clarity": { "score": 5, "evidence": ["..."] },
"visual_proof": { "score": 4, "evidence": ["..."] },
"install_simplicity": { "score": 9, "evidence": ["..."] },
"runnable_quick_start": { "score": 8, "evidence": ["..."] },
"documentation_depth": { "score": 6, "evidence": ["..."] },
"examples": { "score": 5, "evidence": ["..."] },
"community_signals": { "score": 3, "evidence": ["..."] },
"trust_signals": { "score": 7, "evidence": ["..."] },
"marketing_signals": { "score": 4, "evidence": ["..."] }
},
"total": 58,
"grade": "D",
"tone": "honest"
}
第四步：撰写吐槽
阅读 references/roast-voice-guide.md。应用请求的语气。向 dx-roast/roast.md 写入 250–500 词。
必需结构：
# DX 吐槽：<仓库名>
**评分：<等级>（<总分数>/100）** · 语气：<语气>
<第一段：结论。什么做得不错 + 最大的差距是什么。>
<第二段：引用 2 个具体发现，并附上文件引用。>
<第三段：引用另外 2 个发现，并将其与维度分数联系起来。>
<第四段（可选）：最后的转折或与一个知名的优秀仓库进行对比。>
<结尾段：指向 `action-plan.md` 以获取前进路线。>
每次吐槽必须至少引用 score.json 证据数组中的 3 个具体发现。
第五步：生成行动计划
为每个候选修复计算 优先级 = 影响 / 工作量（分钟）。选取前 5–10 个。按优先级降序排列。
对于每个修复，写入到 dx-roast/action-plan.md：
### N. <以祈使语气描述修复，一行>
**原因：** <一句话证明。引用该修复改进了哪个维度。>
**影响力：** +<X> 分 · **工作量：** <5 分钟 / 30 分钟 / 2 小时 / 半天>
**方法：**
1. <具体步骤 1>
2. <具体步骤 2>
3. <具体步骤 3>
<可选的代码/markdown 片段，显示确切变更>
action-plan.md 以以下内容开头：
# 行动计划 —— <仓库名>
当前等级：<等级>（<总分数>/100）
按影响力 × 工作量排列的顶级修复。请按顺序执行。
---
第六步：生成理想 README
阅读 references/readme-template.md。按照“填充规则”部分填充模板。写入 dx-roast/ideal-readme.md。
对于缺失的值，使用像 <homepage_url> 这样的占位符。长度限制：100 行。
第七步：终端摘要
向用户打印此确切格式：
DX 吐槽完成 —— 等级：<等级>（<总分数>/100）
按影响力排列的前 3 个修复：
1. <修复 1> +<X> 分 · <工作量>
2. <修复 2> +<X> 分 · <工作量>
3. <修复 3> +<X> 分 · <工作量>
文件：
→ dx-roast/roast.md （可分享的结论）
→ dx-roast/action-plan.md （按优先级排列的修复）
→ dx-roast/ideal-readme.md （目标状态）
→ dx-roast/score.json （原始分数）
如果提供了 compare_to，则添加一行比较：
基准：<其他仓库> 得分 <X>/100（等级 <Y>）—— 差距 <delta> 分。
自我 QA（每次运行，在打印终端摘要之前）
-
score.json中所有 10 个维度都有分数和证据 - 总分等于各维度分数之和
- 等级字母与根据评分标准的总分阈值匹配
- 吐槽引用了至少 3 个来自 score.json 的证据项
- 吐槽没有提及任何维护者/贡献者的名字
- 行动计划有 5–10 项，按优先级降序排列
- 理想 README 少于 100 行
- 理想 README 对扫描中未找到的任何 URL 使用了
<placeholder> - 所有 4 个文件都存在于 output_dir 中
-
roast.md或action-plan.md中没有<TBD>/<TODO>占位符
如果任何检查失败，修复并重新运行相应步骤。
错误处理
以下四种故障模式需要显式处理——绝不能让技能静默地产生部分输出而不说明原因。
| 情况 | 行为 |
|---|---|
repo 不存在 / 无法克隆 / 无法读取 | 立即退出，并提示消息 仓库不存在或无法访问：<repo>。不要写入任何输出文件。 |
README.md 缺失 | 仍然运行。将 what_is_this_clarity、visual_proof、runnable_quick_start 和 marketing_signals 的分数评为接近 0。将缺失作为吐槽的开场（“没有 README 本身就是一种声明”）。 |
| 仓库是私有的且没有可用的 GitHub 认证 | 尝试本地克隆（git clone <url>）；如果失败，退出并提示 仓库是私有的且没有可用的认证。建议用户设置 GITHUB_TOKEN 或传入本地路径。 |
compare_to URL 失败（网络问题、404、私有等） | 继续运行，不进行基准比较。在吐槽报告中添加一行：注意：请求对 <compare_to> 进行基准比较，但无法获取。 从终端摘要中省略 基准： 这一行。 |
在第二步的元数据获取过程中，任何 GitHub API 错误（速率限制、临时 5xx 错误）都将被捕获并在 score.json 的 trust_signals.evidence 中记录为 "github 元数据不可用"。其余运行过程将继续进行。
示例
良好调用：
“吐槽一下我的仓库 https://github.com/myorg/mytool —— 语气：brutal。”
→ 技能克隆、扫描、评分，将 4 个文件写入 dx-roast/，打印摘要。对于一个典型的仓库，总运行时间 <60 秒。
良好比较：
“对当前目录进行 DX 审计。与 https://github.com/vercel/next.js 进行基准比较。”
→ 扫描两者，对当前目录进行评分，在吐槽和摘要中包含基准比较行。
这个技能不做的事情
- 不会修改目标仓库（只读扫描）
- 不会运行安全审计或依赖扫描
- 不会生成营销文案（行动项是具体的，不是“重写以匹配语气”）
- 不会生成图片或素材（仅使用占位符）
- 不会发布到社交媒体（仅编写可分享的文本）