SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsgrading-frontend

grading-frontend

Frontend & websites

View repository

Updated 10-15 22:39

About this skill

grading-frontend

Score the frontend implementation of an AI training program. 50 students are divided into ~12 groups, implementing a locally deployed website in a spec-driven way. This skill lets Claude (or Qoder / Cursor / Claude Code agent) score one group's frontend according to a unified rubric, producing a markdown report that can be given to students + JSON that can be aggregated into a leaderboard.

Prerequisites

  • Runnable locally: the project to be evaluated can be run on the local machine via npm run dev / pnpm dev / yarn dev startup, default http://localhost:3000(adjust according to the project README).
  • Spec document location：<project>/docs/spec.md or <project>/README.md or <project>/spec/*. If not found, confirm the spec path with the user before starting work; do not score out of thin air.
  • Node.js environment: Node ≥ 18, used to run npx playwright screenshots,npx ajv-cli to validate JSON. On first use npx playwright install chromium。
  • Output directory: all evidence and reports are written to .grading/under the root directory of the project to be evaluated (already agreed by spec to be gitignored).

Agreed working directory: all probe scripts and .grading/ output are by default executed underthe root directory of the project to be evaluated. That is, when scoring:

  1. cd to the project being evaluated (e.g. cd group-workshop/group-2）
  2. call probe with an absolute path:bash $WORKSHOP_ROOT/skills/grading-frontend/probes/probe-screenshots.sh team-2 http://localhost:3000
  3. .grading/ will land under the root of the project being evaluated, coexisting with that project

Shared contract (required reading)

Before scoring begins,you must first finish reading this file ## 评分标尺 / ## 报告模板 / ## 证据硬约束 three sections, as well as ../score-schema.json. These are hard constraints shared by the frontend / backend skills; not reading them will lead to inconsistent output formats and an inability to aggregate the leaderboard:

  1. See this file ## Scoring scale — meaning of the 0–10 scale + definitions of S/A/B/C/D tiers.All dimension scores must be checked against this scale。
  2. See this file ## Report template — unified Markdown report template. The produced report.md must be filled in according to this structure.
  3. ../score-schema.json — schema of the JSON summary. The produced summary.json must pass validation against this schema.
  4. See this file ## Evidence hard constraints — a score ≥7 or ≤4 must have ≥2 pieces of evidence, and a score of 5–6 must have ≥1. Violation makes the score invalid.

Scoring scale (0–10)

This section is grading-frontend and grading-backend shared by the two skillsthe onlyscoring anchor. All dimension scores on both sides must land according to this table, then use evidence to explain why it is not the adjacent anchor.

1. Score anchors

Score Name Judgment criteria
10 Industry-grade exemplar Can be directly used as a teaching sample for the next cohort; the scorer cannot find room for improvement in this dimension; clearly ahead even relative to the best student work seen so far
9 Excellent The core is fully in place, with only 1–2 non-critical flaws (e.g. edge-case copy, extreme breakpoints, cold-path logging)
7 Good The main flow is in place, but there are ≥3 improvable points; it does not affect delivery but clearly shows signs of rushing
5 Passing The happy path runs, but it is clearly rough; there is 1 type of systemic flaw (e.g. missing state, missing validation) but it is not fatal
3 Failing There are traces of an attempt but it is severely incomplete; major sub-items are missing or logically flawed
0 Not implemented Completely missing, or implemented but does not run
N/A Not applicable The spec explicitly does not require it, or this dimension is meaningless for this project's stack;a reason must be written, not counted toward the total score

Allowed scores: 0, 3, 5, 7, 9, 10 are anchors; 1/2/4/6/8 are used only when the evidence supports "between two anchors." Decimals are not allowed.

2. Scoring operation rules

  1. Choose the anchor first, then fine-tune: after obtaining the evidence, first align with the closest anchor (10/9/7/5/3/0), then use the evidence to decide a ±1 fine adjustment. "Pick an 8 first and then find evidence" is prohibited.
  2. High and low scores must have evidence：
    • score ≥ 7 → at least 2 pieces of evidence
    • score ≤ 4 → at least 2 pieces of evidence
    • 5–6 → at least 1 piece of evidence
    • For detailed rules, see this file's ## 证据硬约束 section
  3. N/A must have a reason written：na_reason field is required, format "spec §X.Y 未涉及此项" or "技术栈 Z 无此概念". N/A is not counted toward the total score.
  4. Cannot have a low score + high praise at the same time: if the comment is "very good, just one small thing missing," the score cannot be ≤ 5.
  5. When anchors conflict, take the lower rather than the higher: if a dimension both matches the positive description of 9 and hits the negative description of 5, take 5 (as a warning effect).

3. Total score calculation

Formula(N/A is not counted in the denominator):

total = Σ(score_i × weight_i) / Σ(weight_i for dim_i where score_i != null) × 100 / 10

Equivalent form: first compute the weighted average over non-N/A dimensions (0–10), then normalize the effective weights to 100, and finally multiply by 10 to map to 0–100.

Example: the frontend 10 dimensions have a total weight of 100; if 微文案 (权重 6) is judged N/A:

  • Total effective weight = 94
  • Weighted sum of the remaining 9 dimensions = Σ(score_i × weight_i)
  • total = (Σ / 94) × 10

4. Total score bands

Band Score range Meaning
S ≥ 90 Can serve as a teaching example for this cohort
A 80–89 Qualified delivery; can go live after small-scale polishing
B 70–79 Main flow is OK; systemic issues require rework
C 60–69 Can demo, cannot deliver; multiple structural defects
D < 60 Did not meet the training objectives; key modules need to be redone

Bands are only used for horizontal comparison on the class leaderboard; student feedback is mainly based ondimension scores + evidence + improvement list.

Report template

The .grading/reports/<team>-<side>.md mustproduced by the two grading skills strictly follow this template. No field may be missing; when there is no information, fill in —，Do not omit lines. The template body is presented as a Markdown code block wrapped in four backticks; when copying, remove the outermost backticks.

Usage notes

  • Placeholders have the form {队伍名}, and are replaced with actual values when applied
  • The detailed dimension review blocks are fully expanded according to grading-frontend 10 dimensions / grading-backend 9 dimensions, and cannot be merged or omitted
  • When evidence for any dimension is insufficient, fill the score with null，na_reason fill EVIDENCE_MISSING: ..., and summarize in the "Scoring risks" section at the end
  • A corresponding JSON must exist alongside the report:<team>-<side>.json, schema see ../score-schema.json

Template

# 项目评分报告 — {队伍名}（{前端 | 后端}）

- 评分人：{Claude@model-id / 助教姓名}
- 日期：{YYYY-MM-DD}
- Spec 版本：{git sha 或 docs/spec.md 路径}
- 被评项目 commit：{sha}
- 评分耗时：{xx 分钟}

## 总分：{score} / 100 — 等级 {S | A | B | C | D}

## 维度汇总

| # | 维度 | 得分 | 权重 | 加权 | 一句话 |
|---:|---|---:|---:|---:|---|
| 1 | {维度名} | {0–10 或 N/A} | {w} | {score×w/10} | {一句话概述} |
| 2 | ... | ... | ... | ... | ... |

> 有效权重总和：{Σw_non-NA}；N/A 维度：{列表或 "无"}

## 逐维度详评

### 1. {维度名} — {score}/10（权重 {w}）

**证据**
- `path/to/file.ext:L12-L40` — {这条证据说明了什么}
- 截图：`.grading/shots/{team}-{view}.png`
- 命令：`curl -s localhost:8080/api/x` → `.grading/probes/{team}-x.log`

**要到 10 差什么**
1. {具体、可操作的改进建议}
2. {...}
3. {...}

---

### 2. {维度名} — {score}/10（权重 {w}）

（同样模板，完整列出所有维度）

---

## 亮点

- {值得表扬的 2–4 条，要带证据}

## 最该优先修的 3 件事

1. **{问题}** — 影响：{哪个维度掉了多少分}；改法：{一两句话说清}
2. ...
3. ...

## 评分风险（可选）

仅当出现以下情况时填写，否则删除整节：
- 证据不足被判 `EVIDENCE_MISSING` 的维度列表
- 评分人对某维度存疑但无法进一步取证的原因
- 项目未跑起来 / spec 缺失等影响评分可信度的事实

Verification Checklist (self-check after writing the report)

  • Total score = Σ(weighted columns) × 10 / Σ(valid weights), the numbers check out
  • Every dimension has at least one citation (evidence / screenshot / log / spec item)
  • All N/A have na_reason
  • Each of the "top 3 things that should be fixed first" refers back to a specific dimension
  • The corresponding JSON has been written to .grading/reports/<team>-<side>.json

Hard Evidence Constraints

This section is thewhether the score is validdecision rule.grading-frontend and grading-backend the two skills, before writing the score for each dimension,mustfirst check this table; scores whose evidence does not meet the standard are deemed invalid.

Design purpose: prevent the agent from scoring off the top of its head in the absence of actual observation.Better to have one more EVIDENCE_MISSING, than to make up a nice-looking score。

1. Evidence Count Rules

Score band Minimum evidence count Description
9–10 3 High scores must be reproducible; at minimum cover: 1 code citation + 1 runtime evidence item (screenshot/probe/log) + 1 spec comparison
7–8 2 Must simultaneously reflect "main flow is in place" and "non-critical flaws"
5–6 1 One is enough, but it must be able to point out a specific defect
3–4 2 Low scores cannot rely on impressions; must list ≥2 specific failure points
0 1 At minimum prove "it really is absent": grep results, spec items + codebase absence, startup failure logs
N/A 1 Must cite a spec item or tech stack description to prove the item is "not applicable"

2. Legal Forms of Evidence

Each piece of evidence must be one of the following 4 types,must notbe a natural-language paraphrase:

  1. Code citation：path/to/file.ext:L{start}-L{end} or path/to/file.ext:L{line}
    • Path must be relative to the project root
    • Must actually exist (confirmed by open / grep before scoring)
  2. Screenshot：.grading/shots/<team>-<view>.png
    • The file must exist; backend dimensions generally do not use this
    • A brief description may be attached: "login page desktop 1280×800, has layout shift"
  3. Command log：.grading/probes/<team>-<probe>.log or give the command and key output directly within the evidence line
    • In the form:curl -s -o /dev/null -w "%{http_code}" localhost:8080/api/x -d '{}' → 500
    • Load test results cite the autocannon output file
  4. Spec citation：spec §3.2 / docs/spec.md:L120-L145 / issue link
    • Essential when determining N/A or Spec consistency

3. Handling Violations

3.1 Insufficient Evidence

If, per §1, the required number of evidence items cannot be gathered:

  1. score set to null
  2. na_reason written as "EVIDENCE_MISSING: 需要 N 条证据，仅能取得 M 条（已尝试：<动作清单>）"
  3. At the end of the report, in the ## 评分风险 section, list this dimension
  4. This dimensionis not counted in the total score denominator(consistent with normal N/A), but mark "non-spec exclusion" in the scoring risk section

3.2 Evidence Fabrication / Placeholder

If the scorer/agent writes evidence in any of the following forms, that dimension is directly invalidated and downgraded to EVIDENCE_MISSING：

  • file:line of a nonexistent path (lint: after scoring, use test -f for batch verification)
  • Screenshot file does not exist or has size 0
  • Command log content contradicts the conclusion
  • Descriptive language ("the code is well organized") without a specific citation attached

3.3 High/Low Scores Without Evidence

  • score ≥ 7 but evidence < 2 items → downgrade to 6, or mark EVIDENCE_MISSING
  • score ≤ 4 but evidence < 2 items → upgrade to 5, or mark EVIDENCE_MISSING

Which handling to choose depends on the evaluator's grasp of the dimension; both methods must be noted in "Scoring Risk".

4. Recommended order of evidence collection

Do the cheap, batchable ones first, then the expensive ones:

  1. Static (cheap)：grep / rg Scan keywords, look at package.json / schema / migration
  2. Spec alignment: map spec checklist items to code files one by one
  3. Runtime: start dev server / backend service, run screenshot script / probe script
  4. Interaction: go through the main flow, check console / network / logs
  5. Testing: run the test suite, check coverage and failure list

After each step is finished, save the artifacts to .grading/, and just reference the relative path in the report's evidence line.

Supporting Resources

Read as needed (not all of them every time):

  • ./anti-patterns.md — AI slop front-end anti-pattern checklist.Required reading when scoring the two dimensions "Theme and Aesthetics" and "Code Quality", used to identify typical slippages such as the default shadcn gray-white palette, no theme color, all buttons being bg-blue-500, and empty states only saying "No data".
  • ./examples/good-report.md and ./examples/mediocre-report.md — two calibration sample reports.Read once before scoring for distribution calibration, to avoid problems like the whole class getting 8 points, which makes it impossible to differentiate tiers.
  • ./probes/probe-screenshots.sh — batch-run 4 states + 3 breakpoint screenshots (login / dashboard / empty / error × desktop / tablet / mobile). When collecting evidence, just bash ./probes/probe-screenshots.sh <team> <base-url> ; do not hand-craft playwright commands.
  • ./probes/probe-performance.sh — run Lighthouse to measure key page performance, output .grading/probes/<team>-lighthouse.json(raw Lighthouse JSON) and .grading/probes/<team>-lighthouse-mapping.txt(rubric mapping suggestions).
  • ./probes/probe-a11y.sh — run the axe-core CLI to scan key pages for a11y violations, output .grading/probes/<team>-axe.json and .grading/probes/<team>-axe-summary.txt。

Scoring Process (5 steps)

Step 1: Locate and Start

  1. Confirm the spec path, record spec_sha(if the spec is inside a git repository).
  2. After reading the spec, list: route list / core components / main flows (login, submit, list, details, management, etc.).
  3. Read package.json to identify the tech stack (React/Vue, TS/JS, Tailwind/CSS-in-JS, state management, etc.), record project_sha。
  4. Start the dev server, confirm http://localhost:<port> is accessible.

Step 2: Collect evidence (evidence-first)

Static evidence：

  • Use Grep/Glob to scan the component tree, route table, global styles, TS types, and state management.
  • Reserve at least 1 file:line reference for each dimension.

Dynamic evidence：

# 一次性把主要页面的 3 断点 × 4 态截图跑完
bash ./probes/probe-screenshots.sh <team> http://localhost:3000

# 性能 & a11y
bash ./probes/probe-performance.sh <team> http://localhost:3000
bash ./probes/probe-a11y.sh <team> http://localhost:3000

Save all screenshots to .grading/shots/<team>-*.png, and save all probe logs to .grading/probes/<team>-*.log。

If playwright is unavailable, the fallback is: instruct the evaluator to manually place screenshots into .grading/shots/ before continuing.

Interaction evidence: manually, or with playwright, go through the main flow (login → core CRUD → submit → error path), and record console / network exceptions.

Step 3: Score item by item across the 10 dimensions

⚠️ Mandatory behavior when evidence is insufficient

  • When the dimension score is ≥7 or ≤4 and the number of evidence items is below the minimum required by evidence-requirements.md → score must be set to null, and na_reason must state "EVIDENCE_MISSING: attempted X, Y, but failed to obtain Z"
  • This is different from the N/A for "not required by spec": for N/A, write "N/A — not specified in spec §X.Y"
  • All EVIDENCE_MISSING dimensions must be summarized and listed in the "## Scoring Risks" section at the bottom of the report

Score each dimension from 0–10 against the rubric below in this document (as well as the ## 评分标尺 section of this document). Every score must include evidence (file:line / screenshot path / probe log line number). For dimensions not required by spec, write "N/A — reason"; these are not counted toward the total score.

Step 4: Produce report.md + summary.json

Follow the ## 报告模板 section of this document to fill in .grading/reports/<team>-frontend.md; follow ../score-schema.json to fill in .grading/reports/<team>-frontend.json. For each dimension, include 2–4 items on "what is missing to reach 10".

Step 5: Self-check (must pass)

# JSON schema 校验
npx ajv-cli validate -s skills/score-schema.json \
  -d .grading/reports/<team>-frontend.json

# 证据数量自检（每维度统计 file:line + 截图 + log 引用总数）
grep -cE "\.(tsx?|jsx?|vue|css|png|log):" .grading/reports/<team>-frontend.md

If the self-check fails, return to Step 2 to gather more evidence; do not let it slide.

10 scoring dimensions (weights total 100)

# Dimension Weight
1 Spec consistency 20
2 Theme and aesthetics 12
3 Animation and smoothness 10
4 State completeness 10
5 Code quality 10
6 Responsive adaptation 8
7 Forms and input feedback 8
8 Performance 8
9 Accessibility (a11y) 8
10 Microcopy 6

1. Spec consistency (weight 20)

Focus

  • Whether every route / page / component listed in the spec is implemented.
  • Whether core flow fields, states, and copy align with the spec, with no corner-cutting and no irrelevant extras.
  • Whether permission / role branches (such as admin pages) are complete.

Anchors

  • 10: All pages and flows listed in the spec are 100% implemented; fields, state codes, and copy are fully consistent with the spec; features beyond the spec are clearly marked as enhancements.
  • 9: All spec pages are implemented, with only 1–2 minor differences in non-critical fields or copy versus the spec (e.g., a detail page subtitle differs by one character, a secondary table header order differs slightly), while core fields / state codes / routes are 100% aligned.
  • 8: The main flow and all major pages fully align with the spec; there are omissions in spec corners (e.g., 1–2 interaction details on non-main paths, 1 secondary filter not implemented), without affecting the core business loop.
  • 7: The main flow aligns, but 1–2 secondary pages or 2–3 field details are missing.
  • 5: The core pages are all present, but multiple fields deviate from the spec, or 1 key flow (e.g., submission / review) is not implemented.
  • 3: Large portions deviate from the spec, or only demo pages are implemented and the real business flow is missing.

Evidence collection method

  1. List the correspondence between the spec's route list and the src/routes / app/ directory.
  2. Walk through the core flow step by step, taking screenshots + comparing against spec clauses.
  3. For each missing item, record the spec section number + expected behavior.

Evidence requirements

  • At least 3 file:line references to component / route files.
  • At least 2 screenshots of the main flow.
  • One spec vs implementation alignment table (use a markdown table in the report).

2. Theme and aesthetics (weight 12)

Focus points

  • Whether the color scheme has a theme color rather than being uniformly gray and white.
  • Whether the fonts, font-size hierarchy, and spacing form a system (rather than all using defaults).
  • Whether the cards, shadows, and rounded corners have a sense of design (rather than the default rounded-lg shadow）。
  • AI slop feel (see ./anti-patterns.md）。

Anchors

  • 10: Has a clear theme color system (primary / secondary / accent), a custom font stack, consistent spacing rhythm, and visual hierarchy clear enough to look like a real product.
  • 9: The color scheme is nearly perfect, fonts / spacing form a system, but there is 1 spot where contrast is slightly off (e.g., secondary text gray-500 on gray-50) or 1 button whose hover color is not defined.
  • 8: Theme colors / fonts / card styles are all well established, but a few secondary pages (e.g., 404 / settings) still use the default component appearance without a unified reskin.
  • 7: Has basic theme colors and font choices, most pages are consistent, but 1–2 pages fall short or default components are not reskinned.
  • 5: It is clear that styles have been modified, but the theme is unclear, gray and white dominate, and there are lots of shadcn default appearances.
  • 3: Throughout, gray and white + default bg-blue-500 buttons + gray-100 background, typical AI slop.

Forensic methods

  1. Read ./anti-patterns.md, and compare it against this project's screenshots to determine item by item which anti-patterns were hit.
  2. Look at tailwind.config.* / theme/* / global CSS to confirm whether theme tokens are actually defined.
  3. Stitch multiple screenshots together for comparison: whether the buttons, cards, and heading hierarchy are consistent across different pages.

Evidence requirements

  • At least 3 screenshots covering 3 different pages.
  • At least 1 reference to tailwind.config.*:line or theme.ts:line .
  • Anti-pattern hit list (at least cover the first 5 items in anti-patterns.md ).

3. Animation and smoothness (weight 10)

Focus points

  • Whether transitions for page switches / modals / Toasts / menus are natural rather than abrupt.
  • Whether micro-interactions (hover, press, icon feedback) are present.
  • No obvious layout shift, and list loading does not jump around.
  • Main interactions stay at 60fps with no stutter.

Anchors

  • 10: Key transitions use spring / cubic-bezier, with enter / leave animations; micro-interactions cover the main buttons; no layout shift; scrolling and dragging are smooth.
  • 9: Transitions are implemented throughout the main flow and the curves are reasonable, micro-interactions are well covered; only 1 Toast or modal exit is slightly stiff (disappears directly instead of fade-out).
  • 8: Main page switches / modal transitions are natural, with hover / active feedback; occasionally 1 list-loading image has no placeholder, causing slight layout shift.
  • 7: Main transitions use fade / slide, micro-interactions cover some buttons, and there are occasionally 1–2 jitters.
  • 5: Only default Tailwind transition, modals / routes hard-cut, and hover only changes color.
  • 3: Zero animation, UI changes abruptly, and a large area reflows the moment a list loads.

Forensic methods

  1. Record the screen or run a Playwright trace (--trace on) to observe transitions.
  2. Search for usages of transition / motion / framer-motion / @keyframes .
  3. Check the FPS of key interactions in the DevTools Performance panel.

Evidence requirements

  • At least 1 trace screenshot or recorded frame.
  • At least 2 instances of file:line proving the animation implementation (or proving its absence).

4. State completeness (weight 10)

Focus points

  • Whether all four states—loading / empty / error / success—are covered on key lists and detail pages.
  • loading has a skeleton or spinner, no blank screen.
  • empty has guidance (not just "No data").
  • error has an actionable way out (retry, go back).

Benchmarks

  • 10: All major data components implement the 4 states; the empty state has an illustration or guiding CTA; the error state has a retry button and distinguishes network / business errors.
  • 9: Major components have all 4 states and each state has a CTA; only 1 empty state lacks an illustration / guiding image (but still has copy guidance), or error does not distinguish offline vs business errors.
  • 8: Key lists and detail pages have all 4 states and they are usable; secondary pages (such as settings, help) lack an empty state or their error state falls back to the default error boundary.
  • 7: The main flow has all four states in place, but 1–2 secondary pages lack empty or error.
  • 5: Only loading + success; empty is "No data"; error is alert(err)。
  • 3: A slow API means a blank screen; an API error means a crash to a blank page or a console error.

Evidence-gathering methods

  1. Use the DevTools Network panel to set key APIs to Slow 3G + manual Fail, and take screenshots of each.
  2. Clear the data / mock an empty array to see the empty state.
  3. bash ./probes/probe-screenshots.sh Screenshots of routes with built-in empty / error views.

Evidence requirements

  • At least 4 screenshots covering loading / empty / error / success.
  • At least 2 file:line citations of component state-branch code.

5. Code quality (weight 10)

Focus points

  • Reasonable component splitting granularity (not a single 500-line giant component).
  • TypeScript types are genuinely effective, not a screen full of any。
  • hooks are used correctly (complete dependency arrays, no unnecessary re-renders).
  • No severe prop drilling; state management is methodical.
  • Reusability (shared components, constants, utility functions).

Benchmarks

  • 10: Clear directory layering, components ≤ 200 lines, 100% type coverage, no hooks warnings, clear state-management boundaries, sufficient reuse.
  • 9: Layering and types are both in place; only 1–2 instances of any appear at third-party type gaps and are commented; component line counts and hooks dependencies are clean.
  • 8: Overall architecture is clear and reuse is good; a few components approach 300 lines but have a single responsibility, or there is 1 instance of mild prop drilling (≤3 levels).
  • 7: Overall clean, with occasional 1–2 instances of any or slight prop drilling, but the architecture is understandable.
  • 5: It runs, but there are giant components or any everywhere, and hooks dependency arrays are filled in arbitrarily.
  • 3: Spaghetti code, lots of console.log, types are purely nominal, copy-paste runs rampant.

Evidence-gathering methods

  1. Grep any、@ts-ignore、console.log count.
  2. Sort by file line count, and look at the longest few component files.
  3. Sample 2–3 hooks and check their dependency arrays.
  4. Compare against ./anti-patterns.md frontend code anti-patterns.

Evidence requirements

  • At least 4 file:line citations (both good and bad ones).
  • A set of grep statistics (any / ts-ignore / console.log counts).

6. Responsive adaptation (weight 8)

Focus points

  • All three breakpoints—desktop (≥1280) / tablet (768–1279) / mobile (<768)—are viewable and usable.
  • The layout does not break, and buttons are not squashed into a clump.
  • Gestures and reachability (minimum 44px touch area).

Anchors

  • 10: All three breakpoints are carefully laid out, mobile has dedicated navigation (drawer / tab bar), and content priority adjustments are reasonable.
  • 9: All three breakpoints are carefully laid out and mobile has dedicated navigation; only 1 minor modal is slightly wide on mobile / the button group occasionally wraps.
  • 8: desktop / tablet / mobile are all usable and mobile navigation has been restructured, but 1–2 secondary pages (such as long tables) require horizontal scrolling on mobile.
  • 7: All three breakpoints are usable, but mobile is crowded in multiple places or requires horizontal scrolling.
  • 5: It only looks normal on desktop; mobile is barely usable but the layout is disordered.
  • 3: Only desktop is done; mobile directly overflows / overlaps / is not clickable.

Evidence collection method

  1. bash ./probes/probe-screenshots.sh Screenshots of 3 breakpoints have been generated.
  2. Check tailwind.config breakpoint settings and the sm: / md: / lg: distribution in components.

Evidence requirements

  • 3 breakpoints × at least 2 pages = at least 6 screenshots.
  • At least 2 file:line that reflect breakpoint handling code.

7. Forms and input feedback (weight 8)

Focus points

  • Client-side validation (required, format, length).
  • Error messages are close to the field, not an alert.
  • During submission, the button is disabled + loading to prevent duplicate submission.
  • After success, there is clear feedback (toast / redirect / inline success).

Anchors

  • 10: All forms include inline validation + submission debouncing + success-state toast, all fields can be tabbed through via keyboard, and there is aria-invalid annotation.
  • 9: All forms have inline validation + duplicate submission prevention + success feedback in place; only 1 place lacks aria-invalid or 1 place's error style is not fully consistent with the rest of the site.
  • 8: The main form's validation / disabled state / success feedback are complete; secondary forms (such as feedback, settings) only do required-field validation and do not cover format / length.
  • 7: The main form has basic validation and a disabled state; 1–2 error message styles are inconsistent.
  • 5: Only backend fallback validation exists, errors use alert, and double-clicking submit can produce two records.
  • 3: No validation, no disabling, it crashes on error, and there is no feedback at all.

Evidence collection method

  1. For each form, run: empty submission / invalid format / overly long field / rapid repeated-click submission, take screenshots + record network.
  2. Search for the usage of useForm / zod / yup / disabled / isSubmitting .

Evidence requirements

  • At least 3 screenshots (empty submission / invalid / success).
  • At least 2 file:line referencing validation logic.
  • One network log proving whether duplicate submission is prevented.

8. Performance (weight 8)

Focus points

  • First-screen TTFB + FCP + LCP are reasonable (LCP < 2s is acceptable under local dev).
  • Bundle size is reasonable, with no duplicate dependencies and no unused large libraries.
  • Long-list virtualization and image lazy loading.
  • Interaction response (INP) is smooth.

Anchors

  • 10: Lighthouse Performance ≥ 90 (under local dev), key pages LCP < 1.5s, bundle < 500KB gzip, long list virtualization.
  • 9: Lighthouse 85–89, LCP < 2s, bundle 500–700KB gzip, image lazy loading and code splitting are both done, only long list virtualization is missing.
  • 8: Lighthouse 80–84, first screen is acceptable (LCP < 2.5s), bundle is reasonable but there is 1 route without code-split or an uncompressed large image.
  • 7: Lighthouse 75–89, there are obvious optimization points but they do not affect the experience.
  • 5: Lighthouse 50–74, first screen is slow or the bundle is bloated (> 1MB gzip with no reason).
  • 3: Lighthouse < 50, switching pages takes several seconds, the JS main thread is occupied for a long time.

Evidence collection method

  1. bash ./probes/probe-performance.sh Generate TTFB / FCP / LCP data.
  2. npm run build Check artifact size;npx source-map-explorer check bundle composition (optional).
  3. Search React.lazy / import() / loading="lazy" / use of virtual list library.

Evidence requirements

  • At least 1 <team>-lighthouse.json + <team>-lighthouse-mapping.txt。
  • At least 1 piece of build artifact size data.
  • At least 2 file:line reflecting optimization measures or lack thereof.

9. Accessibility a11y (weight 8)

Focus points

  • Keyboard navigable (reasonable Tab order, focus visible).
  • Semantic tags (button / a / label / heading hierarchy).
  • Color contrast meets WCAG AA (body text 4.5:1, large text 3:1).
  • ARIA attributes used correctly (not overused).
  • focus-visible styles exist.

Anchors

  • 10: axe scan has zero serious violations, fully keyboard operable,focus-visible clear, forms have associated labels, all contrast passes.
  • 9: axe zero serious + zero moderate violations, only 1–2 minor (such as redundant role, landmark naming), keyboard / focus / contrast all pass.
  • 8: axe only 1 moderate violation (such as a single contrast 4.3:1), keyboard usable and focus-visible covers main interactive elements, all labels associated.
  • 7: axe has 1–2 moderate violations, keyboard usable but the focus ring occasionally disappears.
  • 5: multiple contrast issues, some buttons use <div>, no focus-visible。
  • 3: a large number of <div onClick>, pressing Tab does nothing.

Evidence collection method

  1. bash ./probes/probe-a11y.sh run axe-core, check the violation list.
  2. Manually Tab through key pages.
  3. Search role= / aria- / focus-visible / <label usage density.

Evidence requirements

  • 1 <team>-axe.json + <team>-axe-summary.txt。
  • At least 2 file:line citations (positive or negative).
  • At least 1 screenshot of keyboard focus.

10. Microcopy (weight 6)

Focus points

  • Button copy is verb + object, not "OK" / "Submit".
  • Empty state copy tells users what to do next.
  • Error messages are specific and actionable (not "Something went wrong").
  • Copy style is consistent (same person, same tone across the site).

Anchors

  • 10: All button, empty state, and error state copy has been polished, consistent, specific, and with brand tone.
  • 9: Main button / empty state / error copy are all specific and consistent, only 1–2 secondary action buttons still use generic "OK / Cancel" copy.
  • 8: The key flow copy specifically includes guidance (empty states have CTAs, errors have actionable instructions), but in 2–3 places the error messages directly pass through the backend message without localization.
  • 7: The key buttons and empty-state copy are good, but error messages occasionally use generic templates.
  • 5: The buttons are "Submit" / "OK", the empty state is "No data", and the error is "Operation failed".
  • 3: Mixed Chinese and English, or all English but machine-translated in feel, with inconsistent copy tone.

Evidence collection method

  1. Sample and list all button / empty-state / error copy (grep key strings).
  2. Check whether the button copy for the same action is consistent across different pages.

Evidence requirements

  • At least 1 copy sampling table (buttons / empty states / errors, each ≥ 3 entries).
  • At least 2 file:line cite specific copy locations.

Output checklist

Before finishing the scoring, check each item off one by one; if any item fails, go back to the corresponding step and fill it in:

  • .grading/reports/<team>-frontend.md Completed according to this document's ## 报告模板 section structure, with all 10 dimensions scored (or explicitly marked N/A).
  • .grading/reports/<team>-frontend.json Produced, and passed npx ajv-cli validate -s skills/score-schema.json validation.
  • Each dimension has evidence citations and satisfies this document's ## 证据硬约束 section (≥7 / ≤4 points ≥2 entries; 5–6 points ≥1 entry).
  • .grading/shots/ Includes screenshots of at least 3 breakpoints × 4 states;.grading/probes/ Includes <team>-lighthouse.json + <team>-lighthouse-mapping.txt + <team>-axe.json + <team>-axe-summary.txt。
  • At the end of the report, give the "top 3 things that should be fixed first", each corresponding to a specific dimension and file:line.