Rédaction de royaume
Un royaume indique à un agent quand il est de service, quoi faire ensuite et comment savoir que cela a fonctionné. Donnez à cette discipline une voix de maison mémorable.
Avant d'écrire
Lisez le guide cible et la table des déclencheurs de la charte. Préservez l'affectation de maison convenue et distinguez-la des royaumes voisins. Travaillez à partir de situations de développement réelles que l'utilisateur souhaite traiter. Nommez des techniques reconnaissables : "mocks, stubs et fakes" aide à la découverte plus que "doubles contrôlés" seul.
Mettre la sélection dans le skill principal
Le SKILL.md principal de Realms of Code possède quand utiliser chaque royaume. Sa table doit permettre à un agent de choisir avant de charger un guide. Utilisez des situations concrètes : tester la suppression de fichiers, choisir un standard d'API, ou protéger une amélioration du comptage de requêtes. Gardez les déclencheurs là une seule fois, plutôt que de les répéter dans chaque guide.
Mettre les bonnes pratiques dans le guide du royaume
- Nom, discipline, devise : un titre, une ligne de périmètre concrète et la devise.
- Les traditions : un court paragraphe vivant reliant la faction à son rôle d'ingénierie. Faites en sorte que la métaphore explique le travail.
- Axiomes : quelques principes compacts qui guident les décisions. Préservez les engagements établis lors de la révision d'un royaume existant.
- Que faire : des étapes pratiques commençant par des verbes. Identifiez quoi inspecter ou modifier, comment choisir une approche, et quoi vérifier. Utilisez des noms de techniques explicites et réutilisez les outils du projet. Expliquez les alternatives pertinentes et les pièges.
- Preuves : le résultat observable ou l'artefact qui soutient l'achèvement, ainsi que toute limite importante sur ce que cette preuve démontre.
Les axiomes expliquent le jugement ; les étapes le rendent exécutable. Évitez de répéter le même conseil dans les deux. Gardez chaque section aussi courte que son travail le permet. Les fichiers de référence d'un royaume sont en Markdown simple : pas d'identifiants, de champs YAML en double, d'étiquettes d'origine de devise ou de bavardage d'attribution. Seul un SKILL.md découvrable a besoin d'un frontmatter de skill.
Correction travaillée
Pour les Faceless Men, "contrôler les dépendances" est trop abstrait. Un déclencheur utile est "tester un travail qui supprime des fichiers ou appelle un service de paiement externe." L'action suivante est d'isoler cette frontière, choisir un mock/stub/fake, et exercer les comportements de succès, d'échec et de relance sans effets live non intentionnels. Les preuves incluent la cible visée et l'état résultant, ainsi qu'une preuve d'intégration lorsque le contrat réel compte. Un espion qui appelle encore le service live est un piège qui mérite d'être nommé.
Lorsque le skill compagnon realms-of-code est disponible, son references/realms/faceless-men.md est l'exemple travaillé complet.
Pour Arryn, "choisir des protocoles" appartient à la table des déclencheurs principale. Son guide doit indiquer de trouver les standards et technologies existants, vérifier l'état de maintenance et de dépréciation actuel, évaluer la viabilité, réutiliser l'implémentation prise en charge et tester l'interopérabilité.
Enseignez la protection pendant l'implémentation : encodez les règles importantes comme des garde-corps et les améliorations vérifiées comme des cliquets. Un cliquet enregistre une base de référence reproductible, rejette les régressions et se resserre après amélioration. Citadel construit la protection ; Iron Bank l'applique. Ne résolvez jamais un échec de vérification en l'affaiblissant silencieusement.
Relecture avant publication
Essayez deux tâches de correspondance réalistes et une tâche proche appartenant à un autre royaume. Choisissez le royaume depuis la table principale, puis identifiez la première action concrète et la preuve requise depuis son guide. Si l'une ou l'autre étape reste ambiguë, révisez le fichier responsable. Évitez les garde-fous généraux sans rapport avec la tâche.
Gardez la saveur vivante dans une devise, des traditions et une phrase de travail occasionnelle comme "Que disons-nous aux bugs ? Pas aujourd'hui." Associez-la à des conseils d'ingénierie utiles. Supprimez les mots qui n'ajoutent ni une décision ni du caractère. Suivez le workflow de publication du dépôt et vérifiez les liens relatifs et la découvrabilité du skill lorsqu'ils sont affectés.