frontend-dev
Coding practices for frontend development in Atomic CRM. Use when creating or modifying React components, forms, list pages, detail views, filters, data fetching, or responsive layouts.
78
73%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/frontend-dev/SKILL.mdQuality
Discovery
82%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 has good structure with an explicit 'Use when...' clause and relevant trigger terms that developers would naturally use. Its main weakness is the vagueness of 'coding practices'—it doesn't specify what concrete actions or patterns the skill teaches. The project-specific scoping to 'Atomic CRM' helps with distinctiveness but the broad frontend terms could still cause overlap.
Suggestions
Replace 'Coding practices' with specific actions like 'Generates and refactors React components following Atomic CRM conventions, implements form validation, builds list/detail views with filtering and pagination'
Add project-specific distinguishing details such as the tech stack (e.g., specific state management, UI library) to reduce conflict risk with generic React/frontend skills
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (frontend development in Atomic CRM) and lists several areas (React components, forms, list pages, detail views, filters, data fetching, responsive layouts), but describes them as categories rather than concrete actions. 'Coding practices' is vague—it doesn't specify what actions are performed (e.g., 'creates components following X pattern', 'implements data fetching with Y'). | 2 / 3 |
Completeness | Explicitly answers both 'what' (coding practices for frontend development in Atomic CRM) and 'when' (Use when creating or modifying React components, forms, list pages, detail views, filters, data fetching, or responsive layouts). The 'Use when...' clause is present and specific. | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords users would say: 'React components', 'forms', 'list pages', 'detail views', 'filters', 'data fetching', 'responsive layouts', and 'frontend'. These are terms a developer would naturally use when requesting help with these tasks. | 3 / 3 |
Distinctiveness Conflict Risk | Scoped to 'Atomic CRM' which helps distinguish it, but 'React components', 'forms', 'data fetching', and 'responsive layouts' are very broad frontend terms that could overlap with other frontend or React-related skills. The project-specific scoping helps but the trigger terms themselves are generic. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, concise architectural reference for the Atomic CRM frontend that efficiently communicates project-specific conventions without over-explaining. Its main weakness is the lack of concrete code examples showing how to wire up a typical component, form, or list page using these conventions. Adding a small worked example and explicit step-by-step workflows for common tasks (e.g., adding a new resource) would significantly improve actionability.
Suggestions
Add a concrete code example showing a minimal resource component (e.g., a simple list or form) that demonstrates the import conventions, hook usage, and file structure in practice.
Include a step-by-step workflow for adding a new resource, covering file creation, registration in CRM.tsx, and verification steps.
Consider linking to or referencing specific example files in the codebase (e.g., 'See contacts/ for a complete example') to support progressive disclosure.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line conveys project-specific conventions Claude wouldn't know. No explanations of what React, shadcn, or react-admin are. Tight, well-structured, and every token earns its place. | 3 / 3 |
Actionability | Provides specific import paths, hook names, component names, and file structure conventions, which is quite actionable. However, there are no executable code snippets showing actual usage patterns (e.g., a sample component using these conventions), keeping it from a 3. | 2 / 3 |
Workflow Clarity | The file structure convention and data fetching decision tree (standard CRUD vs custom dataProvider) provide reasonable workflow guidance. However, there are no explicit step-by-step sequences for creating a new resource or component, and no validation checkpoints for verifying correctness. | 2 / 3 |
Progressive Disclosure | Content is well-organized into clear sections with good headers, but everything is inline in a single file. References to specific files (e.g., ActivityLog.tsx, SalesCreate.tsx) are mentioned as examples but not linked. For a skill of this scope, splitting detailed patterns (forms, responsive design) into separate referenced files could improve navigation. | 2 / 3 |
Total | 9 / 12 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 — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- marmelab/atomic-crm
- Commit
8126ceb
- 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.