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.
Actionable and well-organized as a convention catalog, but badly bloated: it inlines large framework-specific sections (React, API design, testing) that its own scope boundaries push to other skills, and its one external reference points to a file that does not exist. The description's promise of a lean 'shared floor' is not honored by the body.
Suggestions
Cut the React Best Practices, API Design Standards, Performance, and Testing sections (or move them to reference files) so the body matches its own scope boundaries and stays under ~150 lines.
Remove the generic KISS/DRY/YAGNI/Readability bullet lists — they restate knowledge Claude already has — and keep only the project-specific GOOD/FAIL convention pairs that actually encode house style.
Fix the dangling reference to "rules/common/coding-style.md" (no such file in the bundle) and either add a short ordered review checklist under 'When to Activate' so the standards can be applied as a sequence when reviewing code.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is noticeably verbose: the KISS/DRY/YAGNI bullet lists ("Simplest solution that works", "Avoid over-engineering", "Don't build features before they're needed") restate concepts Claude already knows, and roughly 200 lines of React, Next.js, zod, and supabase material directly contradict the skill's own boundary ("Do not use this skill as the primary source for: React composition, hooks, or rendering patterns; backend architecture, API design"). Not 3 because the scope contradiction and known-concept padding go beyond a few trimmable passages; not 1 because the GOOD/FAIL code pairs do encode project-specific convention. | 2 / 5 |
Actionability | Concrete, mostly executable TypeScript GOOD/FAIL example pairs cover naming, immutability, error handling, memoization, and code smells. Not 5 because several examples are non-executable stubs ("function getMarket(id: string): Promise<Market> { // Implementation }", "test('works', () => { })") and the API/validation examples depend on unstated project context (NextResponse, supabase). | 4 / 5 |
Workflow Clarity | "When to Activate" and the code-smell catalog give application structure, but there is no sequenced review procedure or checklist telling Claude how to apply the standards when reviewing code, and no validation checkpoints. Not 4 because the anchors at 4 and 5 require an ordered sequence with checkpoints, which a catalog of standards sections does not provide; not 2 because the activation criteria and scope boundaries do define when and where the guidance applies. | 3 / 5 |
Progressive Disclosure | Sections are clearly headed and navigable, but this is a ~550-line monolith with no bundle files (no references/, scripts/, or assets/ exist), while framework-specific content the skill itself defers to sibling skills is inlined and the body cites "rules/common/coding-style.md", which is absent from the bundle. Not 2 because the internal section structure is real and consistent; not 4 because content that clearly belongs in separate reference files is inlined and one referenced path dangles. | 3 / 5 |
Total | 12 / 20 Passed |