Install
npx skills add feature-sliced/skillsFür wen
Wenn du Verzeichnisse eines Front-End-Projekts neu ordnest oder immer wieder grübelst, ob ein Stück Code nach app, pages, features, entities oder shared gehört, passt dieses Agent-Skill-Set besser. Es lehrt einen Coding-Agenten, Feature-Sliced Design (FSD) v2.1 anzuwenden: Schichten, Importregeln, Platzierungsentscheidungen und gängige Muster. Methodik-Fließtext:
https://fsd.how/
Es nimmt an, du hast schon ein Front-End-Repository und akzeptierst, die Skills mit npx in einen Coding-Agenten zu legen. Wer nur die Methodik lesen und keinen Agenten Verzeichnisse ändern lassen will, sieht zuerst die Docs oben. Die Seite gibt keine Client-Namensliste und schreibt FSD nicht als Plugin exklusiv für ein Framework, also keine Framework-Bindung erfinden.
Ersten Versuch in 3 Minuten abschließen
Der offizielle Installationsbefehl ist nur dieser:
npx skills add feature-sliced/skills
Er schreibt Skills in deine Agentenumgebung. Zuerst bestätigen, dass dieser Rechner npx hat und das der Coding-Agent ist, den du ändern willst, dann ausführen.
Nach der Installation zuerst eine Nur-Lese-Prüfung; das Repository nicht sofort umbauen. Den Agenten die aktuelle Front-End-Struktur gegen FSD v2.1 halten lassen: was schon in app/, pages/, shared/ liegt, welche Importrichtungen verdächtig wirken. Erfolgssignal: er kann über Schichten und Importregeln sprechen und zeigt eine pages-first-Neigung — zuerst diese drei Schichten ansehen, statt sofort features/ oder entities/ anzulegen. Beginnt er, Dateien stapelweise zu verschieben, zuerst stoppen.
SKILL.md ist der Einstieg. Der Agent soll Referenzdateien nur lesen, wenn die Aufgabe sie braucht, damit der Anfangskontext klein bleibt. Die erste Frage möglichst konkret auf «Struktur prüfen / wohin gehört dieser Code» halten und ihn nicht alle Referenzen auf einmal laden lassen.
Anwendungsfälle
Fall 1: Front-End-Projektstruktur aufsetzen oder neu ordnen. Offiziell gilt diese Art Aufgabe als Nutzungsmoment. Der Agent soll v2.1-Schichten und gängige Muster anwenden, aber die Voreingenommenheit ist pages-first: bei app/, pages/, shared/ beginnen und features oder entities erst öffnen, wenn eine stabile geteilte Verantwortung schon eine Grenze verdient. Der Auszug gibt kein Verzeichnisvorlagen-Archiv und kein Migrationsskript. Die erste Neuordnung soll zuerst eine Vergleichsnotiz mit zu verschiebenden Pfaden liefern; du bestätigst, dann Dateien ändern.
Fall 2: Codeplatz beurteilen. Ein weiterer Nutzungsmoment ist zu entscheiden, ob Code zu app, pages, features, entities oder shared gehört. Ein vorhandenes Modul dem Agenten geben und nur fragen «nach FSD v2.1 welche Schicht, verstoßen Importe». Er schreibt keine Auto-Fix-Regeln und keine Vergleichstabelle zu einer bestimmten Router-Bibliothek. Abnahme sieht nur: Schichtvorschlag und Importgrund; schlägt er vor, sofort ein feature/entity zu schneiden, muss er zugleich erklären, warum jene geteilte Verantwortung schon stabil ist. Eine neue Grenze ohne Erklärung liegt außerhalb dieses Materials.
Nutzungsgrenzen
Dieses Skill-Set lehrt FSD v2.1, keine mündliche FSD beliebiger Jahre. Methodikdetails folgen
https://fsd.how/
Die Seite deckt keine Backend-Schichtung und erlaubt dem Agenten keine großflächigen Umbenennungen ohne Bestätigung.
Installationsweg ist npx skills add feature-sliced/skills. Keine zwei Installer nebeneinander. Einstieg ist immer SKILL.md; Referenzdateien bei Bedarf. Aus diesem Auszug kannst du jene Referenzdateien nicht benennen, also nicht so tun, als kenntest du schon ein vollständiges Inventar.
Beim ersten Mal bei Strukturprüfung und Platzurteil stoppen. Jedes Verschieben von Verzeichnissen, Anlegen von features/entities oder Ändern von Import-Aliassen muss zuerst den Agenten die zu ändernden Dateien und Gründe auflisten lassen; du bestätigst, dann weiter.