J'ai publié les bonnes pratiques SolidJS en tant que skill sur skills.sh

J’utilise régulièrement skills.sh. Pouvoir gérer sous forme de skills les connaissances transmises à l’agent est pratique, et j’en ai progressivement ajouté pour mon usage personnel et en équipe.

Comme j’écris de plus en plus de SolidJS, le besoin d’un skill s’est fait sentir. Le cas où la destructuration des props casse la réactivité, les situations où il faut utiliser <For> plutôt que .map() — j’en avais assez de compléter le contexte à chaque fois.

J’en ai profité pour le créer avec Claude Code et le publier directement sur skills.sh. Je laisse ici un mémo de la procédure de publication.

Créer le skill

On lance /skill-creator et on répond aux questions pour obtenir un brouillon.

/skill-creator

À quoi sert le skill, quand doit-il se déclencher, qu’attend-on en sortie. En répondant à ces trois questions, un brouillon de SKILL.md est généré. C’est incomparablement plus rapide que de partir de zéro.

Retoucher la description soi-même

Une fois le brouillon obtenu, il vaut mieux retoucher la description sans faute. Sa précision détermine directement la précision du déclenchement.

# Trop vague, le skill ne se déclenche presque jamais
description: Aide pour SolidJS

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

Au-delà d’une simple liste de mots-clés, décrire aussi les situations d’utilisation permet au skill de se déclencher même dans des scénarios implicites.

Limiter SKILL.md à 500 lignes

SKILL.md est systématiquement chargé dans le contexte. S’il devient trop long, il empiète sur les autres tâches. J’ai donc adopté une structure où les détails sont séparés dans references/ et consultés uniquement en cas de besoin.

## En cas d'utilisation de SolidStart

Voir [`references/solidstart.md`](references/solidstart.md) pour les détails.

Vérifier la différence par des tests

/skill-creator dispose d’une fonctionnalité qui exécute en parallèle with-skill et without-skill pour les comparer.

J’ai préparé trois cas de test.

Test	Ce que je voulais vérifier
Création d’une Todo list	Utilise-t-il `<For>` ? Recommande-t-il `createStore` ?
Revue de code	Détecte-t-il le bug de destructuration des props ?
Récupération de données asynchrone	Utilise-t-il le pattern `createResource` + `Suspense` ?

En lançant les tests, même sans skill, <For> et createResource étaient raisonnablement bien utilisés. Les différences sont apparues sur les points suivants.

En revue de code, avec le skill, la destructuration des props en argument cassant la réactivité a été détectée comme Critical. Sans le skill, le problème a été manqué.

Pour la création de Todo, avec le skill, createStore + produce ont été proposés, tandis que sans le skill, cela s’arrêtait à createSignal<Todo[]>.

Pour la récupération asynchrone, avec le skill, le duo Suspense et ErrorBoundary a été proposé. Sans le skill, c’était une vérification manuelle de users.loading.

	with_skill	without_skill
Pass rate	100%	80%

Le bug de destructuration des props est une connaissance que Claude possède déjà. Cependant, le comportement change selon que le skill contient ou non le critère de toujours le signaler en revue. Écrire des skills pour couvrir de manière fiable les pièges spécifiques au framework — voilà la conclusion à laquelle je suis arrivé.

Publier sur skills.sh

Il suffit de créer un dépôt conforme au standard ouvert de skills.sh. C’est la même structure que vercel-labs/agent-skills.

Structure du dépôt

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

Soigner le frontmatter

Avant la publication, ajouter license, metadata.author et metadata.version.

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

Les règles pour name sont subtilement strictes. Uniquement des lettres minuscules, des chiffres et des tirets. Le nom doit correspondre au nom du répertoire. Pas de tiret en début ou fin, pas de tirets consécutifs.

Valider avant de push

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

Cela vérifie d’un coup le format du frontmatter et les règles de nommage. Je recommande de passer cette validation avant de push.

Rédiger le README et c’est terminé

# agent-skills

## Skills

### solidjs-best-practices

SolidJS のコードを書いたりレビューするためのベストプラクティス集。

## インストール

npx skills add mktbsh/agent-skills

Un push sur GitHub et la publication est terminée. C’est tout ce qu’il y a à faire.

En résumé

La précision de la description et le processus de vérification des différences par des tests déterminent la qualité du skill. Négliger l’un ou l’autre mène à une situation où l’on a créé un skill sans vraiment savoir s’il est efficace.

Plus on y intègre des connaissances concrètes du type « sans ça, on est bloqué » plutôt que des savoirs génériques, plus le skill devient efficace.