Best Practices für SolidJS als Skill auf skills.sh veröffentlicht

Ich nutze skills.sh regelmäßig. Wissen, das man an Agenten übergibt, als Skills verwalten zu können, ist praktisch — nach und nach habe ich immer mehr für mich und mein Team angelegt.

Da ich zunehmend SolidJS schreibe, brauchte ich einen Skill dafür. Etwa das Problem, dass Destructuring von props die Reactivity zerstört, oder Situationen, in denen man <For> statt .map() verwenden sollte — jedes Mal den Kontext manuell zu ergänzen, wurde lästig.

Also habe ich den Skill mit Claude Code erstellt und direkt auf skills.sh veröffentlicht. Hier halte ich den Ablauf als Notiz fest.

Skill erstellen

Man startet /skill-creator und beantwortet die Fragen, dann wird ein Entwurf geschrieben.

/skill-creator

Wofür ist der Skill, wann soll er auslösen, was wird als Ausgabe erwartet. Beantwortet man diese drei Fragen, erhält man einen Entwurf der SKILL.md. Deutlich schneller, als von Null anzufangen.

Die description muss man selbst anpassen

Wenn der Entwurf steht, sollte man unbedingt die description überarbeiten. Ihre Genauigkeit bestimmt direkt die Trigger-Genauigkeit.

# Vage formuliert triggert der Skill kaum
description: SolidJS-Hilfe

# Tatsächlich verwendet
description: SolidJS のコードを書いたりレビューするためのベストプラクティス。
  createSignal, createEffect, createMemo, createStore, createResource,
  createContext, Show, For, Switch, SolidJS, solid-js が出てきたら使う。
  React パターンを Solid に変換する質問や、コンポーネントが更新されない
  バグのデバッグにも使う。

Nicht nur Keywords auflisten, sondern auch beschreiben, in welchen Situationen der Skill zum Einsatz kommt — dann wird er auch bei impliziten Szenarien erkannt.

SKILL.md auf unter 500 Zeilen halten

SKILL.md wird immer in den Kontext geladen. Wird sie zu lang, verdrängt sie andere Arbeit. Deshalb habe ich Details in references/ ausgelagert und nur bei Bedarf referenziert.

## Bei Verwendung von SolidStart

Details siehe [`references/solidstart.md`](references/solidstart.md).

Unterschiede durch Tests überprüfen

/skill-creator bietet eine Funktion, die with-skill und without-skill parallel ausführt und vergleicht.

Ich habe drei Testfälle vorbereitet.

Als ich die Tests laufen ließ, konnte die Version ohne Skill <For> und createResource durchaus korrekt einsetzen. Unterschiede zeigten sich an folgenden Stellen.

Beim Code-Review erkannte die Version mit Skill das Problem, dass Destructuring von props in den Argumenten die Reactivity zerstört, als Critical. Die Version ohne Skill übersah es.

Bei der Todo-Erstellung schlug die Version mit Skill createStore + produce vor, während die Version ohne Skill bei createSignal<Todo[]> stehen blieb.

Beim asynchronen Laden schlug die Version mit Skill die Kombination aus Suspense und ErrorBoundary vor. Die Version ohne Skill prüfte manuell mit users.loading.

Der Destructuring-Bug bei props ist Wissen, das Claude bereits hat. Ob er beim Review aber zuverlässig darauf hinweist, hängt davon ab, ob der Skill eine entsprechende Beurteilungsregel enthält. Skills zu schreiben, um Framework-spezifische Stolperfallen zuverlässig abzudecken — das war mein Fazit.

Auf skills.sh veröffentlichen

Man erstellt ein Repository, das dem offenen Standard von skills.sh entspricht, und kann veröffentlichen. Dieselbe Struktur wie vercel-labs/agent-skills.

Repository-Struktur

agent-skills/
├── LICENSE
├── README.md
└── skills/
    └── solidjs-best-practices/
        ├── SKILL.md
        └── references/
            └── solidstart.md

Frontmatter vorbereiten

Vor der Veröffentlichung license, metadata.author und metadata.version hinzufügen.

---
name: solidjs-best-practices
description: ...
license: MIT
metadata:
  author: mktbsh
  version: "1.0.0"
---

Die Regeln für name sind im Detail etwas knifflig. Nur Kleinbuchstaben, Ziffern und Bindestriche. Muss mit dem Verzeichnisnamen übereinstimmen. Kein Bindestrich am Anfang oder Ende, keine aufeinanderfolgenden Bindestriche.

Validierung durchlaufen lassen, dann pushen

npx skills-ref validate ./skills/solidjs-best-practices

Frontmatter-Format und Namensregeln werden zusammen geprüft. Es empfiehlt sich, erst nach bestandener Validierung zu pushen.

README schreiben und fertig

# agent-skills

## Skills

### solidjs-best-practices

Sammlung von Best Practices für das Schreiben und Reviewen von SolidJS-Code.

## Installation

npx skills add mktbsh/agent-skills

Auf GitHub pushen und die Veröffentlichung ist abgeschlossen. Mehr braucht es nicht.

Fazit

Die Genauigkeit der description und der Prozess, Unterschiede durch Tests zu überprüfen, bestimmen die Qualität eines Skills. Vernachlässigt man beides, landet man in einem Zustand, in dem man einen Skill erstellt hat, aber nicht weiß, ob er überhaupt wirkt.

Je mehr man konkretes Know-how einbaut — Dinge, an denen man ohne dieses Wissen hängen bleibt — desto wirksamer wird der Skill. Allgemeinwissen bringt weniger.