Promettre un résultat précis
« Automatiser mon travail » est difficile à évaluer. « Transformer des notes en un plan d’action Markdown » permet à quelqu’un de comprendre immédiatement ce qu’il pourra obtenir. Cette précision aide aussi à tester votre blueprint.
Expliquer le premier lancement
Listez les blocs, les outils à installer et les accès à configurer. Donnez un petit jeu de données et montrez le résultat attendu. Le lecteur doit pouvoir vérifier son installation sans connaître votre environnement.
Remplacez les chemins propres à votre machine et explicitez les variables. Indiquez le mode d’exécution prévu. Les commandes locales et les services externes doivent apparaître dans les prérequis, y compris leurs coûts possibles.
Partager une définition propre
Un workflow de travail peut contenir des secrets dans sa configuration, des chemins privés ou des résultats confidentiels. Inspectez l’export avant publication. Un export d’exécution demande une attention supplémentaire, car il peut inclure des logs et des fichiers.
Réimportez le blueprint avec des données de démonstration. Cette étape révèle souvent une dépendance implicite ou un paramètre qui n’existait que sur votre machine.
Choisir comment le distribuer
Vous pouvez partager gratuitement vos blueprints. Si vous choisissez de les vendre, leur vente passe par le store officiel. Présentez clairement la licence, les dépendances et ce que l’acquéreur reçoit.
Les blocs unitaires restent soumis à leurs licences open source, tandis que le studio possède sa propre licence. Un blueprint documenté permet à son utilisateur de distinguer ces différentes conditions.
Faire vivre la publication
Une modification d’agent ou de dépendance peut changer le comportement du workflow. Documentez les versions testées et conservez un exemple de référence. Les retours de la communauté sont d’autant plus utiles que chacun peut reproduire le même point de départ.
À votre tour de construire.
Créer mon premier blueprint