CtrlK
BlogDocsLog inGet started
Tessl Logo

frontend-conventions

Coding conventions, architecture patterns, and testing rules for the SkillHub React frontend. Ensures agents follow Feature-Sliced Design and use the generated OpenAPI types.

54

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/frontend-conventions/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

Reviews 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-structured, highly actionable conventions document: concrete paths, commands, and a validation step for the API-regeneration workflow. Its main costs are token weight from pinned version numbers and the dependency inventory, and the absence of a single canonical code example for the patterns it mandates.

Suggestions

Drop or relocate the pinned version numbers (react 19, Vite 6, Playwright 1.58, etc.) — they will go stale and 'web/package.json' is the authoritative source — and cut the HMR explanation sentence.

Add one short canonical example (a TanStack Query hook using the openapi-fetch typed client) so the mandated data-fetching pattern is copy-paste ready.

Consider moving the 14-item feature inventory and dependency list into a reference file to slim the main SKILL.md body.

DimensionReasoningScore

Conciseness

The body is mostly dense tables and bullet lists that assume Claude's competence (no library explainers), but it carries unnecessary weight: pinned version numbers ('react 19', 'Vite 6', 'TypeScript 5.7', 'Playwright 1.58' — time-sensitive info not placed in a deprecated/old-patterns section) and filler like 'Vite HMR is enabled by default — save a file and the browser updates instantly.' This matches the 'mostly efficient but includes some unnecessary explanation or could be tightened' anchor rather than the efficient-but-minor anchor above.

3 / 5

Actionability

Guidance is concrete and executable throughout — exact paths ('web/src/api/generated/schema.d.ts', 'web/src/shared/lib/utils.ts'), copy-paste commands ('make generate-api', 'make typecheck-web', './scripts/check-openapi-generated.sh'), and the actual 'openapi-typescript' invocation. It falls short of 5 because, despite mandating TanStack Query and component patterns, it shows no canonical example of a query hook or component structure to copy from.

4 / 5

Workflow Clarity

Mostly a rule-based skill, but its one real workflow (API type regeneration) is clearly sequenced with an explicit validation checkpoint ('To verify the generated file is not stale: ./scripts/check-openapi-generated.sh') plus a commit instruction. It is not a 5 because there is no error-recovery guidance if the staleness check fails, and no checklist tying the rules together before opening a PR.

4 / 5

Progressive Disclosure

A single well-organized file with clearly headed sections (Trigger, Rules by topic, Build & Development) and all content appropriately inline at this size; there are no bundle files, so nothing is nested or buried. It does not earn the simple-skill 5 because at ~118 lines it exceeds the under-50-line threshold, and the feature inventory and dependency list could plausibly live in a reference file.

4 / 5

Total

15

/

20

Passed

Description

53%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is appropriately third-person, scoped to a specific project, and names two concrete technical specifics. Its main weaknesses are the absence of any explicit 'Use when...' trigger clause and thin natural-keyword coverage, both of which hurt its ability to be surfaced at the right moments.

Suggestions

Add an explicit trigger clause, e.g., 'Use when adding or modifying React/TypeScript code in web/src, creating new features or shared components, or changing API client calls.'

Include the natural terms users would actually say — TypeScript, components, hooks, Tailwind, API client, tests — to improve trigger term coverage.

Promote one or two more of the body's concrete rules (e.g., 'use TanStack Query for all server state', 'never useEffect for data fetching') into the description to raise specificity.

DimensionReasoningScore

Specificity

The description names its domain ('coding conventions, architecture patterns, and testing rules for the SkillHub React frontend') and two concrete specifics ('Feature-Sliced Design' and 'the generated OpenAPI types'), which matches the 'names domain and 1-2 concrete actions, but not comprehensive' anchor. It does not list several specific actions (e.g., TanStack Query for server state, layer placement, Tailwind styling), so it falls short of a 4.

3 / 5

Completeness

The 'what' is clearly stated (conventions, architecture patterns, and testing rules for the SkillHub React frontend) but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines. It is not a 2 because the 'what' is concrete, not vague.

3 / 5

Trigger Term Quality

Some relevant keywords are present ('React frontend', 'Feature-Sliced Design', 'OpenAPI types') but common natural terms users would actually say are missing — 'TypeScript', 'components', 'hooks', 'Tailwind', 'API client', 'frontend tests'. This matches the 'some relevant keywords but missing common variations or synonyms' anchor rather than the good-coverage anchor above.

3 / 5

Distinctiveness Conflict Risk

Scoping to 'the SkillHub React frontend' plus named specifics (Feature-Sliced Design, generated OpenAPI types) creates a clear niche with minor overlap risk against generic React-conventions or linting skills. It is not a 5 because it lacks distinct trigger phrases that would fully separate it from similar frontend conventions skills.

4 / 5

Total

13

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
iflytek/skillhub
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.