Content
77%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a highly actionable, well-sequenced workflow with strong validation gates (fact cards, submission checklist, failure handling), but it pays for that with token redundancy — the anti-scraping and no-fabrication rules each repeat 3–4 times — and keeps writing-style, chart, and comparison rulebooks inline in a single ~320-line file instead of splitting them into references.
Suggestions
State each guardrail once: consolidate the '不要主动抓取 GitHub Trending' rule (currently in Step 1 twice, the checklist, and the failure section) and the no-fabrication rule (currently in 数据来源优先级, Step 4, Step 5, and the checklist) into a single authoritative statement, leaving the checklist as the only reminder.
Move 写作风格, 图表规则, 竞品对比规则, and 代码示例规则 into reference files (e.g., references/writing-style.md, references/chart-rules.md) and link them from SKILL.md so the main file stays a lean workflow overview.
Trim redundant elaboration such as the banned-phrase variants list and the illustrative Mermaid example, which mostly restate rules already given in the 图表规则 section.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient operational rules, but several are stated repeatedly: "不要自行抓取 GitHub Trending 页面替代用户输入" appears in Step 1 (twice: "不要主动访问 https://github.com/trending…" and "不要自行抓取 GitHub Trending 页面替代用户输入"), in the 质量校验 checklist, and in 失败和不确定情况; the no-fabrication rule ("禁止把未验证信息写成事实") recurs in 数据来源优先级, Step 4, Step 5, and the checklist. This is 'mostly efficient but could be tightened' (anchor 3), not anchor 4 — the repetition is systematic, not minor — and not anchor 2 since no section explains concepts Claude already knows. | 3 / 5 |
Actionability | Fully concrete, copy-paste-ready guidance: README fallback URLs ("https://raw.githubusercontent.com/{owner}/{repo}/{default_branch}/README.md"), named DeepWiki tools (read_wiki_structure / read_wiki_contents / ask_question with repoName), a worked normalization example ("microsoft / markitdown" → repo URL → DeepWiki param), a fact-card field template, a full article markdown skeleton, and a sample Mermaid block. Matches anchor 5 for an instruction-only skill with actionable concrete guidance; not anchor 4 because the common cases (project selection, README retrieval, article structure, failure handling) are all covered with specific examples. | 5 / 5 |
Workflow Clarity | The pipeline is diagrammed up front ("用户粘贴榜单内容 -> README / GitHub 项目页 -> DeepWiki -> 项目事实卡 -> 公众号文章 -> 当前项目 markdown 目录 -> 事实校验") and elaborated as six sequenced steps with an explicit validation checkpoint (Step 5 fact cards required before writing), a checkbox 质量校验 checklist before submission, and a 失败和不确定情况 section covering error recovery (missing fields, README-poor projects, DeepWiki gaps). This is anchor 5 (explicit validation steps, feedback loops, checklist); not anchor 4 since both checkpoints and recovery paths are present. | 5 / 5 |
Progressive Disclosure | The ~320-line single-file body is well-sectioned, but content that reads as reference material is inlined: 写作风格, 图表规则 (Mermaid/SVG rules + example), 竞品对比规则, and 代码示例规则 could live in separate reference files, and no references/scripts/assets bundle exists. Anchor 3 fits ('some structure but could be better organized… content that should be separate is inline'); not anchor 4 because there are no external reference files at all despite the length, and not anchor 2 because section headers are clear and nothing is buried. | 3 / 5 |
Total | 16 / 20 Passed |