Skill Builder

# Skill Builder

## Objectif

La bibliothèque compte 65 skills, mais elle ne couvrira jamais tous les besoins spécifiques d'un client — son ERP cible, sa devise, ses entités, le format de sortie exact qu'il attend. Ce skill n'a qu'un but : transformer un besoin métier exprimé en langage naturel en un **nouveau skill sur mesure**, testé en direct sur les vraies données du client, prêt à être sauvegardé et réutilisé.

Ne jamais générer un skill sans l'avoir testé sur des données réelles au moins une fois. Un skill non testé n'est qu'une hypothèse.

## Phase 0 — Cadrer le besoin

Poser des questions structurées, sans en sauter aucune même si le client est pressé — un skill mal cadré produit un résultat décevant :

1. **Le besoin métier précis** : quelle question veut-on pouvoir poser, et à quel rythme ? ("un rapport mensuel d'accrual sur mes bons de commande" est précis ; "aide-moi avec mes achats" ne l'est pas encore)
2. **Le contexte et les contraintes** : quel ERP cible (NetSuite, SAP, autre) ? quelle devise fonctionnelle ? une ou plusieurs entités ? des seuils ou exclusions spécifiques (ex. exclure les PO de test, exclure une entité) ?
3. **Le format de sortie attendu** : une réponse conversationnelle, un tableau dans le chat, un export Excel/CSV avec une structure précise (combien d'onglets, quelles colonnes), ou une alerte Slack ?
4. **Qui l'utilise et à quelle fréquence** : ponctuel, quotidien, hebdomadaire, mensuel — cette réponse conditionne si le skill devra être transformé en routine (voir Phase 4).

Si le client ne sait pas répondre à une question, proposer un exemple concret plutôt que de rester abstrait : "par exemple, pour un export mensuel prêt pour NetSuite, on parle d'un fichier avec plusieurs onglets, ou d'un tableau simple dans la conversation ?"

## Phase 1 — Repérer les bons outils MCP

Le MCP Spendesk expose aujourd'hui 24 outils de lecture en production (factures, fournisseurs, bons de commande, cartes, trésorerie, centres de coûts, transactions...) et 4 outils d'écriture encore en démo (`archive_supplier`, `create_supplier`, `mark_payable_as_ready`, `update_payable` — voir la page [outils à venir](/#upcoming) avant de les mentionner à un client, ils ne sont pas encore en production).

Pour le besoin cadré en Phase 0, identifier :
- Les outils qui répondent directement au besoin (ex. `get_purchase_orders` pour un besoin sur les bons de commande, `get_payables` pour vérifier les factures rattachées)
- L'ordre dans lequel les appeler (ex. lister d'abord, puis creuser sur les cas à fort enjeu plutôt que tout détailler)
- Les limites connues à respecter (ex. montants en centimes sur certains outils, filtres à combiner pour éviter les réponses trop volumineuses — voir `scenarios/mcp-gap-analysis.md` pour les bugs connus du MCP)

Ne jamais deviner un nom d'outil ou un filtre — si un doute existe sur le comportement exact d'un outil, l'appeler une fois en test avant de l'inscrire dans le skill généré.

## Phase 2 — Générer le skill

Rédiger le fichier skill au format standard de la bibliothèque, avec :
- Un frontmatter complet (`name`, `description`, `tags`, `when_to_use`, `personas`, `use_cases`, `frequency`, `complexity`, `tools_used`) — cohérent avec le besoin cadré en Phase 0
- Un objectif clair en une ou deux phrases
- Des étapes numérotées, chacune nommant l'outil MCP appelé et le résultat attendu
- Une section "Points d'attention" listant les limites connues et les pièges (devises, cache, filtres obligatoires)
- 2-3 exemples de prompts que le client pourra réutiliser tel quel

Toujours présenter le skill généré comme un artefact concret (un bloc de texte que le client peut copier), pas seulement le décrire.

## Phase 3 — Tester en direct

Faire tourner le skill généré tout de suite, sur les vraies données du client, avant de le considérer "prêt" :
- Annoncer ce qu'on va faire ("je lance le skill qu'on vient de créer sur vos vraies données...")
- Comparer le résultat obtenu à ce que le client avait décrit en Phase 0 — est-ce que le format correspond ? est-ce que les bons filtres ont été appliqués ?
- Si le résultat ne correspond pas, ajuster le skill généré et retester, plutôt que de livrer un skill non validé

## Phase 4 — Sauvegarder et, si récurrent, planifier

Expliquer comment sauvegarder le skill généré :
- **Claude Code** : déposer le fichier `.md` dans le dossier `.claude/` du projet
- **Dust** : coller le contenu du skill comme instructions d'un agent

Si le besoin exprimé en Phase 0 est récurrent (quotidien, hebdomadaire, mensuel), proposer explicitement de le transformer en routine planifiée plutôt que de le laisser comme une action manuelle à refaire chaque fois — renvoyer vers le guide [Automatiser un rapport avec les routines](/guide/routines-rapports-periodiques) pour la mise en place exacte.

## Points d'attention

- Le skill généré n'est aussi bon que le besoin exprimé en Phase 0 — être précis sur le format de sortie change beaucoup le résultat final.
- Toujours tester avant de considérer un skill généré comme fiable pour un usage récurrent — ne jamais sauter la Phase 3 même si le client est pressé.
- Générer un skill reste une opération de lecture et d'écriture de texte : aucune action irréversible n'est prise côté Spendesk pendant la génération elle-même — les seuls appels MCP réels sont ceux du test en Phase 3.
- Un skill généré ainsi reste un simple fichier texte, comme tous les autres skills de la bibliothèque — rien de magique, juste des instructions claires.

## Exemples de prompts

- "Aide-moi à créer un skill pour un export mensuel d'accrual sur mes bons de commande, au format Excel avec plusieurs onglets prêts pour NetSuite."
- "Je veux un skill qui m'alerte chaque semaine si un fournisseur dépasse le budget de son centre de coût."
- "Crée-moi un skill qui compare mes dépenses carte par département sur les 3 derniers mois, avec un tableau en sortie."