Content
50%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 well-organized standards reference with consistently concrete PASS/FAIL code examples that encode genuinely useful project conventions, but it is monolithic and padded with generic programming principles (KISS/DRY/YAGNI, basic readability advice) that Claude already knows. Splitting topic areas into reference files and cutting the generic sections would raise both conciseness and progressive disclosure. No multi-step workflow or validation is needed for a reference skill, but an explicit 'how to apply these during a review' sequence would help.
Suggestions
Delete or compress the '代码质量原则' section (KISS/DRY/YAGNI/readability bullets) — this is knowledge Claude already has; keep only conventions that differ from defaults, as done well in the immutability section.
Split the body into one-level-deep reference files (e.g. references/react.md, references/api-design.md, references/testing.md) and have SKILL.md keep only the core naming/immutability/error-handling rules with clear pointers like 'React 组件与 Hooks 规范: 见 [react.md](references/react.md)'.
Fill in the stub examples (getMarket's '// Implementation', the useDebounce hook's missing React imports) or trim them to one-line signatures so every example is executable as written.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The opening sections restate basic programming concepts Claude already knows — 'KISS (保持简单，傻瓜)', 'DRY (不要重复自己)', 'YAGNI', '可读性优先' with bullets like '代码被阅读的次数远多于被编写的次数' — which is exactly the padded explanation the rubric penalizes. The project-specific conventions (immutability rules, ApiResponse shape, supabase/zod patterns) are valuable, but several full sections teach generic wisdom rather than project standards, matching anchor 2 ('noticeably verbose; several unnecessary explanations or padded sections') rather than anchor 3's 'some unnecessary explanation'. | 2 / 5 |
Actionability | PASS/FAIL code pairs are concrete, largely executable, and cover the common cases (naming, spread-operator immutability, try/catch fetch, Promise.all, typed React components, zod validation, AAA test structure). It stops short of anchor 5 because several examples are stubs — 'function getMarket(id: string): Promise<Market> { // Implementation }' and the useDebounce example that uses useState/useEffect without imports — so not everything is copy-paste ready. | 4 / 5 |
Workflow Clarity | This is a standards reference rather than a multi-step process, and it defines activation triggers in '何时激活', but it prescribes no workflow at all — no order to check rules when writing or reviewing code, and no validation/verification checkpoints anywhere. It fits anchor 3 ('sequence present but checkpoints missing or implicit' — here the sequence is at best implicit) and does not reach anchor 4, which requires most checkpoints to be explicit. | 3 / 5 |
Progressive Disclosure | The body has clear, well-organized headers, but it is a ~540-line monolith with no references/ files, no external links, and no navigation pointers; distinct topic areas (React best practices, API design standards, testing standards, file organization) that clearly belong in separate reference files are all inlined. This matches anchor 3 ('content that should be separate is inline') rather than anchor 2, since the in-file structure and section organization are good. | 3 / 5 |
Total | 12 / 20 Passed |