Apply Feature-Sliced Design (FSD) v2.1 architectural methodology to frontend projects. Use when organizing code structure, decomposing features, creating new components or features, refactoring existing codebases, or when users mention "FSD", "Feature-Sliced", layers, slices, or frontend architecture patterns.
57
66%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly identifies a specific architectural methodology (FSD v2.1), provides an explicit 'Use when...' clause with multiple trigger scenarios, and includes natural keywords users would employ. The main weakness is that the listed actions (organizing code, decomposing features, refactoring) are somewhat generic rather than FSD-specific concrete operations like managing app/processes/pages/widgets/features/entities/shared layers.
Suggestions
Consider adding FSD-specific concrete actions such as 'manage app/processes/pages/widgets/features/entities/shared layers' or 'define public API segments' to increase specificity beyond generic architecture tasks.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Feature-Sliced Design for frontend projects) and mentions actions like 'organizing code structure', 'decomposing features', 'creating new components', and 'refactoring existing codebases', but these are somewhat generic software architecture actions rather than highly specific concrete operations unique to FSD. | 2 / 3 |
Completeness | Clearly answers both 'what' (apply FSD v2.1 architectural methodology to frontend projects) and 'when' (explicit 'Use when...' clause listing multiple trigger scenarios including keyword mentions like 'FSD', 'Feature-Sliced', layers, slices, etc.). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'FSD', 'Feature-Sliced', 'layers', 'slices', 'frontend architecture patterns', 'organizing code structure', 'decomposing features', 'creating new components or features', 'refactoring'. These are terms users would naturally use when seeking help with this methodology. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive due to the specific methodology name 'Feature-Sliced Design (FSD) v2.1' and domain-specific terms like 'layers', 'slices'. This is unlikely to conflict with generic frontend or architecture skills because of the precise methodology focus. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is highly actionable with excellent concrete examples, decision frameworks, and executable code, but is severely undermined by extreme verbosity and lack of progressive disclosure. The same concepts (especially 'Pages First' and 'extract only when reused') are repeated across nearly every section, inflating token cost significantly. The content would benefit enormously from being split into a concise overview SKILL.md with references to detailed sub-documents.
Suggestions
Reduce the main file to ~100-150 lines covering the core decision framework, import rules, and layer overview, then split detailed layer definitions, migration guide, framework integrations, and anti-patterns into separate referenced files (e.g., LAYERS.md, MIGRATION.md, PATTERNS.md).
Eliminate the 5+ repetitions of the 'Pages First' principle and 'only extract when reused' guidance - state it once prominently and reference it elsewhere.
Integrate Steiger validation into the migration and implementation workflows as explicit checkpoint steps (e.g., 'After moving code, run `npx steiger src` to verify no import violations').
Remove the 'When to Use This Skill' and 'Core Philosophy' ending sections - these duplicate the overview and are metadata concerns, not actionable content.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~500+ lines with massive repetition. The 'Pages First' principle is restated at least 5-6 times across different sections. Layer definitions repeat the same guidance ('only extract when reused') for every single layer. The 'When to Use This Skill' and 'Core Philosophy' sections at the end restate what was already covered. Claude doesn't need explanations of what React components are or basic frontend concepts. | 1 / 3 |
Actionability | Provides concrete, executable TypeScript/React code examples throughout, including complete file structures, import patterns, tsconfig.json configuration, and specific CLI commands for tooling (Steiger). The decision framework with specific examples ('User profile form with validation') gives clear, actionable guidance for real scenarios. | 3 / 3 |
Workflow Clarity | The decision framework provides a clear decision tree for where to place code, and the migration steps are sequenced. However, there are no validation checkpoints - no step says 'run Steiger to verify your structure is correct' within the workflows themselves. The migration workflow lists steps but lacks verification between them. Steiger is mentioned separately but not integrated into the workflows. | 2 / 3 |
Progressive Disclosure | This is a monolithic wall of text with no references to external files. The 'Additional Resources' section lists topics (Cross-imports, SSR, Monorepos) but doesn't link to actual files. All content is inline - the layer definitions, patterns, migration guide, framework integrations, and anti-patterns could easily be split into separate referenced documents. At this length, progressive disclosure is essential but absent. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (849 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
3e53f88
Table of Contents
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.