v2.0 · 2026-05-28 — incorporates the 9-dimension scoring prescription of Microsoft Research SkillLens (arXiv 2605.23899) + the validation-gated validation mechanism of SkillOpt (arXiv 2605.23904) + three-layer human in the loop gatekeeping.
Drawing on Karpathy autoresearch's autonomous experiment loop to continuously optimize skills. Core idea:evaluate → improve → real-world validation → human confirmation → keep or roll back → generate result card GitHub: https://github.com/alchaincyf/darwin-skill
Design Philosophy
The essence of autoresearch:
- Single editable asset — modify only one SKILL.md at a time
- Dual evaluation — structural scoring (static analysis) + effectiveness validation (run tests and inspect output)
- Ratchet mechanism — keep only improvements, automatically roll back regressions
- Independent scoring — use a subagent for scoring to avoid the bias of "grading your own changes"
- Human in the loop — pause after each skill optimization, continue only after user confirmation
Difference from pure structural review: it not only looks at whether SKILL.md is written in a standard way, but also at whether, after the change, theactual results are better when run。
Evaluation Rubric (9 dimensions, total score 100)
Design basis: based on the empirical finding of the SkillLens paper (arXiv 2605.23899) — LLM-as-judge accuracy in evaluating skill quality is only 46.4% (close to random), and adding the meta-skill three dimensions raises it to 73.8%. This rubric strengthens the scoring standards of dim3 / dim5, adds dim9 "counterexamples and blacklist", and balances the weights to 100.Purpose: make scoring more sensitive to real quality and reduce the optimism bias of the LLM judge.
Structural dimensions (59 points) — static analysis
| # | Dimension | Weight | Scoring standard |
|---|---|---|---|
| 1 | Frontmatter quality | 7 | name is standard, description includes what it does + when to use it + trigger words, ≤1024 characters,empty trailing phrases such as "apply flexibly/judge according to circumstances" are forbidden at the end |
| 2 | Workflow clarity | 12 | steps are clear and executable, numbered, each step has clear input/output |
| 3 | Failure mode encoding | 12 | failure modes must be explicitly encoded(write explicit branches of the form "if X fails → Y"); has fallback paths and error recovery;writing only the positive flow without failure branches deducts ≥3 points(SkillLens meta-skill dimension) |
| 4 | Checkpoint design | 6 | user confirmation before key decisions, preventing autonomous loss of control;checkpoints must be explicitly marked (🔴/STOP/CHECKPOINT), merely relying on wording such as "if... it is recommended..." does not count |
| 5 | Executable specificity | 17 | not vague, has specific parameters/formats/examples, can be executed directly;softening wording such as "recommended/may consider/according to circumstances/flexibly grasp/depending on the situation" is forbidden—— if ≥3 occurrences, deduct ≥3 points (SkillLens actionable specificity dimension) |
| 6 | Resource integration | 4 | references/scripts/assets are referenced correctly, and paths are reachable |
Effectiveness dimensions (35 points) — requires real-world testing
| # | Dimension | Weight | Scoring criteria |
|---|---|---|---|
| 7 | Overall architecture | 12 | Clear structural hierarchy, no redundancy or omissions, consistent with Huashu's ecosystem;Each occurrence of redundant/AI-speak filler paragraphs (banned Huashu words such as 'to put it plainly'/'in other words'/'firstly, secondly, in summary', etc.) deducts 1 point |
| 8 | Hands-on performance | 23 | Run through with a test prompt and check whether the output quality matches the capabilities the skill claims |
Meta-skill dimensions (6 points) — counterexamples and blacklist
| # | Dimension | Weight | Scoring criteria |
|---|---|---|---|
| 9 | Counterexamples and blacklist | 6 | The skill must have a counterexample list of "what not to do"; if it only writes "should do X" without "should not do Y", deduct ≥3 points; red flags/dangerous actions/anti-patterns should be listed in a separate section (SkillLens risk-action blacklist dimension) |
Scoring rules
- Dimensions 1-7, 9: score each dimension from 1-10, multiply by the weight to get that dimension's score
- Dimension 8 (hands-on performance): run 2-3 test prompts and score 1-10 based on output quality
- Total score = Σ(dimension score × weight) / 10, full score 100
- After improvement, the total score must be strictly higher than before improvement to be kept
Empirical basis of the Rubric
The rubric design is based on the SkillLens paper (arXiv 2605.23899) + a local controlled study：
- SkillLens found that the accuracy of LLM-as-judge is only 46.4% (close to random), and it rises to 73.8% after adding the three meta-skill dimensions
- Locally, 4 types of degradation were applied to huashu-research → 5 independent judges in a blind test unanimously agreed V1>V2, with a mean Δ of +46.5 (5/5 high confidence)
Conclusion: the rubric can identify gross degradation, but fine-grained quality difference is still unreliable,important decisions must be human-reviewed。
→ For detailed paper evidence + complete data from 5 judges + HL real-world case numbers, see references/skilllens-evidence.md
About the "Hands-on performance" dimension
This is the biggest difference from purely structural scoring. Scoring method:
- Design 2-3typical user promptsfor each skill (not edge cases, but the most common usage scenarios)
- Execute with sub-agents: one run with the skill, one run without the skill (baseline)
- Compare output quality and score from the following angles:
- Does the output fulfill the user's intent?
- Compared with the baseline without the skill, is the quality improvement obvious?
- Are there negative effects introduced by the skill (excessive redundancy, going off track, strange formatting)?
If sub-agents are unavailable (timeout/resource limits), degrade to "dry-run verification": after reading the skill, simulate the execution approach for a typical prompt and judge whether the process is reasonable; this must be marked in results.tsv dry_run。dry_run ratio > 30% → evaluation invalidation warning(from the local controlled study: dim8 hands-on dimension weight is 23%; without full_test verification the score is unreliable).
Runtime adaptability review (gate item, independent of the 9-dimension scoring)
The skill should be universally usable across 50+ skills-compatible runtimes such as Claude Code / Codex / Cursor / OpenClaw / Hermes / Gemini CLI / OpenCode—otherwise, when other agents parse it, wording like "in Claude Code" or "Claude Code skill" will be misjudged as "this isn't for me" and it will be rejected outright (example: nuwa-skill was rejected by the Marvis agent for this reason).
During the Phase 1 baseline evaluation, force one red-flag scan
grep -nE "(在 Claude Code|Claude Code skill|Claude Code 用户|Cursor only|Codex 中|^\[!\[Claude Code|~/\.claude/skills/[a-z]|/plugin install\b)" SKILL.md README.md 2>/dev/null
Non-empty output = red flag hit → force the first round of Phase 2 to be set as P0 "runtime drift fix" (write into the note column of results.tsv runtime_warn=N）。
Exceptions (allowed "Claude Code traces")
frontmatter trigger words, references to internal skill names within the Huashu ecosystem, explicitly marked runtime-specific sections, commit messages—these legitimately appear and do not count as red flags.
→ For the complete red-flag/green-flag comparison table + detailed rules for the exception list + review timing for each phase of Phase 1/2/3, see references/runtime-neutrality.md
Autonomous optimization loop
Phase 0: Initialization
1. 确认优化范围：
- 全部skills → 扫描 .claude/skills/*/SKILL.md
- 指定skills → 用户指定列表
2. 创建 git 分支：auto-optimize/YYYYMMDD-HHMM
3. 初始化 results.tsv（如不存在）
4. 读取现有 results.tsv 了解历史优化记录
Phase 0.5: Test Prompt Design
Before evaluation, design test prompts for each skill. This step is critical—without test prompts, the "actual measured performance" dimension cannot be scored.
for each skill:
1. 读取 SKILL.md，理解它做什么
2. 设计2-3个测试prompt，覆盖：
- 最典型的使用场景（happy path）
- 一个稍复杂或有歧义的场景
3. 保存到 skill目录/test-prompts.json：
[
{"id": 1, "prompt": "用户会说的话", "expected": "期望输出的简短描述"},
{"id": 2, "prompt": "...", "expected": "..."}
]
Show all test prompts to the user,and only proceed to evaluation after confirmation. The quality of the test prompts determines whether the optimization direction is correct.
Phase 1: Baseline Evaluation (Baseline)
for each skill in 优化范围:
# 结构评分（主agent可以做）
1. 读取 SKILL.md 全文
2. 按维度1-7逐项打分（附简短理由）
# 效果评分（用子agent做，独立于主agent）
3. 对每个测试prompt，spawn子agent：
- with_skill: 带着SKILL.md执行测试prompt
- baseline: 不带skill执行同一prompt
4. 对比两组输出，打维度8的分
# 汇总
5. 计算加权总分
6. 记录到 results.tsv
If sub-agents are unavailable(timeout, environment restrictions), score dimension 8 using dry-run verification and mark it dry_run. Do not skip this dimension just because tests cannot be run—even a simulated walkthrough is better than not looking at it at all.
After the baseline evaluation is complete, show the scorecard:
┌──────────────────────────┬───────┬──────────────┬──────────────┐
│ Skill │ Score │ 结构短板 │ 效果短板 │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ huashu-proofreading │ 78 │ 边界条件 │ 测试prompt2 │
│ huashu-slides │ 72 │ 指令具体性 │ baseline持平 │
├──────────────────────────┼───────┼──────────────┼──────────────┤
│ 平均 │ 75 │ │ │
└──────────────────────────┴───────┴──────────────┴──────────────┘
🔴 CHECKPOINT · 🛑 STOP: pause and wait for user confirmation before entering the optimization loop.
Phase 2: Optimization Loop
After user confirmation, sort by baseline score from low to high, and optimize the weakest first.
for each skill:
round = 0
while round < MAX_ROUNDS (默认3):
round += 1
# Step 1: 诊断
找出得分最低的维度（结构或效果都算）
# HL-3 警告：dim2/dim3/dim4 是相关簇，修一个时另两个常跟着涨
# → 不要因为 dim3 最低就单独修，要看整簇短板再决定是否同步改
# Step 2: 提出改进方案
针对最低维度，生成1个具体改进方案：
- 改什么（具体段落/行）
- 为什么改（对应rubric哪条）
- 预期提升多少分
# Step 3: 执行改进
编辑 SKILL.md
git add + commit（message: "optimize {skill}: {改进摘要}"）
# Step 4: 重新评估
- 结构维度：主agent重新打分
- 效果维度：spawn独立子agent重跑测试prompt（关键！不能自己评自己）
# Step 5: 决策
if 新总分 > 旧总分:
status = "keep"，更新旧总分
# HL-4 见好就收：连续2轮 Δ < 2 分 → break 进 Phase 3
if last_delta < 2.0 and this_delta < 2.0:
print("触顶信号：连续2轮边际收益 < 2 分，停止优化避免过度调整")
break
else:
status = "revert"
git revert HEAD（创建新commit回滚，不用reset --hard）
记录失败尝试到 results.tsv
break # 该skill到瓶颈，跳到下一个
# Step 6: 日志
results.tsv 追加行
# === 🔴 CHECKPOINT · 每个 skill 优化完后强制人审 ===
展示该skill的改动摘要：
- git diff（改前 vs 改后）
- 分数变化（哪些维度提升/下降）
- 测试prompt输出对比（如果跑过的话）
等用户确认 OK 再继续下一个skill。
如果用户说"不好"，回滚到该skill的优化前版本。
Phase 2.5: Exploratory Rewrite (triggered as needed)
When hill-climbing breaks in round 1 for 2 consecutive skills (no improvement), propose an "exploratory rewrite":
1. 选一个瓶颈skill
2. git stash 保存当前最优版本
3. 从头重写SKILL.md（不是微调，是重新组织结构和表达方式）
4. 重新评估
5. if 重写版 > stash版: 采用重写版
else: git stash pop 恢复
This solves the local optimum problem of hill-climbing—sometimes you need to "tear down first, then rebuild" to break through a bottleneck. 🔴 CHECKPOINT · 🛑 STOP: must obtain user consent before executing.
Phase 3: Summary Report
## 优化报告
### 总览
- 优化skills数：N
- 总实验次数：M
- 保留改进：X（Y%）
- 回滚次数：Z
- 实测验证：A次完整测试 / B次干跑
### 分数变化
┌──────────────────────────┬────────┬────────┬────────┐
│ Skill │ Before │ After │ Δ │
├──────────────────────────┼────────┼────────┼────────┤
│ huashu-proofreading │ 78 │ 87 │ +9 │
│ huashu-slides │ 72 │ 83 │ +11 │
├──────────────────────────┼────────┼────────┼────────┤
│ 平均 │ 75 │ 85 │ +10 │
└──────────────────────────┴────────┴────────┴────────┘
### 主要改进
1. [skill-A] 补充了边界条件处理，测试输出质量提升明显
2. [skill-B] 重组了workflow结构，baseline对比优势增大
results.tsv format
timestamp commit skill old_score new_score status dimension note eval_mode
2026-03-31T10:00 baseline huashu-proofreading - 78 baseline - 初始评估 full_test
2026-03-31T10:05 a1b2c3d huashu-proofreading 78 84 keep 边界条件 补充fallback full_test
2026-03-31T10:10 b2c3d4e huashu-proofreading 84 82 revert 指令具体性 过度细化 dry_run
Add a new eval_mode column:full_test(sub-agent tests were run) or dry_run(simulated walkthrough).
File location:.claude/skills/darwin-skill/results.tsv
High-leverage operations in practice (essentials quick reference)
4 items verified in practice (huashu-gpt-image +10.85 / huashu-weread-advisor +14.9 / claude-design +16.5). For detailed case data, see references/skilllens-evidence.md in the "HL Practical Cases" section.
- HL-1 (dim4) Explicit visual markers are leverage: add 🔴 CHECKPOINT / 🛑 STOP; relying on "must" wording does not work—LLMs scan for visual markers when parsing. A 4-line change leveraged dim4 +3 points
- HL-2 (dim3) if-then three-stage fallback table: upgrade the two columns "symptom/solution" into the three-stage "trigger condition / first-line fix / fallback if still failing". Implementation of the SkillLens failure-mechanism encoding dimension
- HL-3 (Phase 2 diagnosis) dimension-related cluster warning: dim2/3/4 are correlated clusters—when fixing dim3, dim2 often rises along with it. When "finding the lowest dimension," also look at the short board of the correlated cluster before deciding whether to change them in sync
- HL-4 (Phase 2 exit) auto break on hitting the cap: 2 consecutive rounds of Δ < 2 points → break into Phase 3. +0.15 is a stop signal, not a continue signal; forcing MAX_ROUNDS=3 introduces over-engineering
Optimization Strategy Library
Sort by priority, do only the single highest-priority item each round:
P0: Runtime compatibility issues (gate item hit → must fix first)
- README/SKILL.md contains red-flag wording (e.g. "in Claude Code", "Claude Code skill") → replace with runtime-neutral wording
- Badge pins down a single runtime → change to
Agent Skills Standard+skills.sh+Multi-Runtimethree neutral badges - Installation section only gives the path for one runtime → change to a three-layer structure of "one-line command (auto-detect) + manual path table + as reference material"
- Workflow hardcodes runtime-specific tools with no fallback → provide a generic alternative or mark it as "only available on a certain runtime"
- Exception: if the skill name explicitly indicates a single runtime (e.g.
xxx-codex), this item can be skipped
P0: Effectiveness issues (found through actual testing)
- Test output deviates from user intent → check whether the skill has misleading instructions
- Worse with the skill than without → the skill may over-constrain, consider simplifying
- Output format does not meet expectations → add a clear output template
P1: Structural issues
- Frontmatter lacks trigger words → add Chinese and English trigger words
- Lacks Phase/Step structure → reorganize into a linear process
- Lacks user confirmation checkpoints → insert them at key decision points
P2: Specificity issues
- Steps are vague ("process image") → change to concrete operations and parameters
- Lacks input/output specifications → add format, path, examples
- Lacks exception handling → add "if X fails, then Y"
P3: Readability issues
- Paragraphs too long → split + use tables
- Duplicate descriptions → merge and deduplicate
- Lacks quick reference → add a TL;DR or decision tree
Exceptions and Boundary Conditions
The process assumes an ideal environment, but in practice exceptions are often encountered. The following predefined fallbacks ensure the optimization process does not "get stuck as soon as it runs."
| Scenario | Trigger condition | Handling action |
|---|---|---|
| Not in a git repository | git rev-parse failed |
Ask the user: run git init or fall back to file backup; if the user chooses the latter, use cp SKILL.md SKILL.md.bak.YYYYMMDD-HHMM instead of revert |
| results.tsv missing | File does not exist | Create a new one and write the header row (9 columns: including eval_mode) |
| results.tsv corrupted | Column count mismatch / not TSV | Back up as .bak.YYYYMMDD-HHMM then rebuild, and inform the user |
| Branch already exists | git checkout -b failed |
Append -2 / -3to the end of the branch name; if it fails a 3rd time, switch back to the existing branch and ask whether to continue or start a new one |
git revert failed |
Conflict / working tree dirty | First git stash, retry; if it still fails, read from the SKILL.md of the previous commit and overwrite the current file to restore manually |
| MAX_ROUNDS reached (default 3) | Already ran 3 rounds and there are still weak points | Do not force a break; show the current weakest dimension and ask the user "continue with 1 more round / enter Phase 2.5 / wrap up" |
| After optimization, size exceeds 150% | New file > original × 1.5 | Reject the commit, return to the improvement step to streamline (delete redundancy/merge duplicates), then evaluate again |
| test-prompts.json already exists | The file is already in the skill directory | By default reuse and display it, and ask the user to choose one of three: "reuse / rewrite / append" |
| SKILL.md not found | The directory exists but there is no SKILL.md | Terminate this skill, record in results.tsv status=error, continue to the next one |
| Score calculation rules | Floating-point precision drift | Keep the total score to 1 decimal place; improvement must be strictly > the old score (do not rely on rounding) |
Principles: Inform the user of exceptions first, then handle them according to the rules; never silently skip or silently fail.
darwin operation anti-pattern blacklist (dim9 application: things darwin itself should not do when optimizing)
Lessons from the early 40 runs with 0 revert in the local results.tsv + anti-patterns exposed by Judge G/H self-referential evaluation. Each one is apitfall actually stepped in。
| # | Anti-pattern | Why not to do it | Alternative approach |
|---|---|---|---|
| 1 | Self-evaluate and self-modify in the same context | Scoring immediately in the same Claude session after making changes creates an optimistic bias of "what I just changed must be better" (SkillLens empirically shows LLM-as-judge accuracy is only 46.4%) | Must spawn an independent sub-agent to score, and only trust it when at least 2 judges reach consensus |
| 2 | git reset --hard as a rollback |
Will lose uncommitted changes in the working tree; CI history is broken | Use git revert HEAD to create a reverse commit, preserving a traceable chain |
| 3 | Add redundancy to pad the score | After hitting the ceiling, continuing to force changes is often "adding filler/adding paragraphs to make the LLM think it is more detailed", while actual quality does not change | Ceiling signal (2 consecutive rounds with Δ<2 points) → break into Phase 3,quit while ahead |
| 4 | Skip test-prompts and score directly | dim8 without test-prompts is scoring out of thin air; a 23% weight is equivalent to fabrication | Phase 0.5 mandates designing 2-3 prompts; if the user does not provide them, default to making 3 and display them for confirmation |
| 5 | Change multiple dimensions within a round | When multiple variables change at the same time, score increases or decreases cannot be attributed to specific changes | 1 dimension per round; for related clusters (dim2/3/4), when changing one, observe whether the other two rise along with it |
| 6 | dry_run ratio > 30% | The dim8 actual-test dimension becomes nominal, and scores are inflated (early 40 records had 67% dry_run, 0 revert) | Force at least 1 real full_test; optimizations with many dry_runs are explicitly marked ⚠️ in results.tsv |
| 7 | Silently skip exceptions | Silently continuing when encountering git/tsv exceptions breaks the integrity of the ratchet | The 10 fallbacks in the exception table must inform the user before handling |
| 8 | Optimizing dimensions independently while ignoring correlations | dim2/3/4 are a correlated cluster; when optimizing dim2 alone, it is often found that it has already been pushed to the ceiling by dim3 in a previous round | When finding the lowest dimension, also look at the weak points of the correlated cluster to decide whether to change them in sync |
Trigger scenarios: Check against this table once before each round of Phase 2 changes. If any anti-pattern is hit → rewrite the change plan.
Constraint rules
- Do not change the skill's core functionality and purpose — only optimize "how to write" and "how to execute", not "what to do"
- Do not introduce new dependencies — do not add scripts or references files that the skill did not originally have
- Change only one dimension per round — avoid multiple changes making attribution impossible
- Keep file size reasonable — after optimization, SKILL.md should not exceed 150% of its original size
- Respect Huashu's style — Chinese-first, conciseness above all
- Rollback-capable — all changes are on a git branch; use git revert rather than reset --hard
- Scoring independence — effectiveness dimensions must be verified with a sub-agent or at least a dry run; you cannot "change it and then evaluate it directly" in the same context
- Runtime neutrality — the skill must run properly in any skills-compatible runtime such as Claude Code, Codex, Cursor, OpenClaw, Hermes, etc. Unless the skill name is explicitly bound to a single runtime (e.g.
xxx-codex、huashu-slides-codex), anything like "in Claude Code", "Claude Code skill", "pinned to a single badge", or "installation command only gives.claude/skills/one path" is considered a gate failure and must be fixed with P0 priority (see the "Runtime Compatibility Review" section for details)
Usage
Full optimization (recommended for first use)
用户："优化所有skills"
→ Phase 0-3 完整流程
→ 默认：先基线评估，按分数升序优先优化最低 5-10 个
Single optimization
用户："优化 huashu-slides 这个skill"
→ 只对指定skill执行 Phase 0.5-2
Evaluate only, do not change
用户："评估所有skills的质量"
→ 只执行 Phase 0.5-1（设计测试prompt + 基线评估），不进入优化循环
View history
用户："看看skill优化历史"
→ 读取并展示 results.tsv
Design inspiration
"You write the goals and constraints in program.md; let an agent generate and test code deltas indefinitely; keep only what measurably improves the objective." — Karpathy, autoresearch
Correspondence in this skill:
- program.md → this file (evaluation rubric and constraint rules)
- train.py → each SKILL.md
- val_bpb → 9-dimension weighted total score (including measured performance + meta-skill counterexample blacklist)
- git ratchet → keep only commits with improvements
- test set → each skill's test-prompts.json
Difference: human-in-the-loop is added (autoresearch is fully autonomous, while skill optimization requires human judgment), as well as a dual evaluation mechanism (structure + effectiveness), because a skill's "good or bad" is more subtle than a loss value.
Result Card generation (Result Card)
After each skill optimization is completed (or after full aggregation), automatically generate a visual result card and save a screenshot as PNG.
Card template
Template location:templates/result-card.html
3 styles, randomly choose one each time:
| Style | CSS class | URL hash | Visual characteristics |
|---|---|---|---|
| Warm Swiss | .theme-swiss |
#swiss |
Warm white background + terracotta orange, Inter font, clean grid |
| Dark Terminal | .theme-terminal |
#terminal |
Near-black background + fluorescent green, monospace font, scanlines |
| Newspaper | .theme-newspaper |
#newspaper |
Warm white paper + deep red, serif font, two-column editorial style |
Generation process
1. 复制 templates/result-card.html 到临时工作文件
2. 用 sed/编辑工具 替换占位数据：
- data-field="skill-name" → 实际skill名
- data-field="score-before/after/delta" → 实际分数
- 9个维度的 dim-bar-before/after width → 实际百分比（若模板仍是旧 8 维布局，加一行 dim9 反例黑名单条目）
- data-field="improvement-1/2/3" → 实际改进摘要
- data-field="date" → 当前日期
3. 随机选择风格：hash 设为 swiss/terminal/newspaper 之一
4. 用 scripts/screenshot.mjs 截图（2x 高清，只截 .card 元素，自动 open 图片）：
node .claude/skills/darwin-skill/scripts/screenshot.mjs \
/abs/path/to/card.html /abs/path/to/output.png
# 回退方案（脚本失败时）：
npx playwright screenshot "file:///path/to/card.html#[theme]" \
output.png --viewport-size=960,1280 --wait-for-timeout=2000
5. 提示用户查看成果卡片 PNG
### 资源文件速查
| 路径 | 用途 |
|---|---|
| `templates/result-card.html` | 3风格主模板（swiss/terminal/newspaper，hash切换） |
| `templates/result-card-dark.html` / `-white.html` | 单一风格替代模板（需要锁定风格时用） |
| `scripts/screenshot.mjs` | 2x 高清截图，只截 .card，自动 open |
| `results.tsv` | 历次优化日志（9列含 eval_mode） |
| `{skill目录}/test-prompts.json` | 每个 skill 的测试 prompt 集（用于维度8实测） |
### 何时生成
- **单skill卡片**：每个skill优化完成后，展示该skill的分数变化
- **总览卡片**：全部优化完成后（Phase 3），展示全局战绩
### 品牌元素
- 顶部：Darwin.skill 品牌标识 + 日期
- 底部：「Train your Skills like you train your models」+ github.com/alchaincyf/darwin-skill