CtrlK
BlogDocsLog inGet started
Tessl Logo

feature-sliced-design

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

Quality

66%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./SKILL.md
SKILL.md
Quality
Evals
Security

Quality

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.

DimensionReasoningScore

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.

DimensionReasoningScore

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (849 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
aiko-atami/fsd
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.