Criação de reinos
Um reino diz a um agente quando ele está em serviço, o que fazer a seguir e como saber que funcionou. Dê a essa disciplina uma voz de casa memorável.
Antes de escrever
Leia o guia alvo e a tabela de gatilhos do estatuto. Preserve a designação de casa acordada e distinga-a dos reinos vizinhos. Trabalhe a partir de situações reais de desenvolvimento que o usuário deseja tratar. Nomeie técnicas reconhecíveis: “mocks, stubs e fakes” ajuda na descoberta mais do que “duplos controlados” sozinho.
Coloque a seleção no skill principal
O SKILL.md principal de Código dos Reinos define quando usar cada reino. Sua tabela deve permitir que um agente escolha antes de carregar um guia. Use situações concretas: testar exclusão de arquivos, selecionar um padrão de API ou proteger uma melhoria de contagem de consultas. Mantenha os gatilhos lá uma vez, em vez de repeti-los em cada guia.
Coloque as melhores práticas no guia do reino
- Nome, disciplina, lema: um título, uma linha de escopo concreta e o lema.
- A lore: um parágrafo curto e vívido conectando a facção ao seu papel de engenharia. Faça a metáfora explicar o trabalho.
- Axiomas: alguns princípios compactos que orientam decisões. Preserve compromissos estabelecidos ao revisar um reino existente.
- O que fazer: passos práticos começando com verbos. Identifique o que inspecionar ou alterar, como escolher uma abordagem e o que verificar. Use nomes de técnicas explícitos e reutilize as ferramentas do projeto. Explique alternativas e armadilhas significativas.
- Evidências: o resultado observável ou artefato que suporta a conclusão, mais qualquer limite importante sobre o que essa evidência prova.
Os axiomas explicam o julgamento; os passos o tornam executável. Evite repetir o mesmo conselho em ambos. Mantenha cada seção tão curta quanto seu trabalho permitir. Os arquivos de referência do reino são Markdown simples: sem IDs, campos YAML duplicados, rótulos de origem do lema ou ruído de atribuição. Apenas um SKILL.md que possa ser descoberto precisa de frontmatter de skill.
Correção trabalhada
Para os Homens Sem Rosto, “controlar dependências” é abstrato demais. Um gatilho útil é “testar um trabalho que exclui arquivos ou chama um serviço de pagamento externo.” A próxima ação é isolar esse limite, escolher um mock/stub/fake e exercitar comportamento de sucesso, falha e repetição sem efeitos vivos não intencionais. As evidências incluem o alvo pretendido e o estado resultante, além de prova de integração onde o contrato real importa. Um espião que ainda chama o serviço vivo é uma armadilha que vale a pena nomear.
Quando o skill companheiro Código dos Reinos estiver disponível, seu references/realms/faceless-men.md é o exemplo completo trabalhado.
Para Arryn, “escolher protocolos” pertence à tabela principal de gatilhos. Seu guia deve dizer para encontrar padrões e tecnologia existentes, verificar o status atual de manutenção e depreciação, avaliar a viabilidade, reutilizar a implementação suportada e testar a interoperabilidade.
Ensine proteção durante a implementação: codifique regras importantes como guardrails e melhorias verificadas como ratchets. Um ratchet registra uma linha de base reproduzível, rejeita regressões e aperta após melhoria. A Cidadela constrói a proteção; o Banco de Ferro a impõe. Nunca resolva uma verificação com falha enfraquecendo-a silenciosamente.
Revise antes de publicar
Tente duas tarefas realistas de correspondência e uma tarefa próxima pertencente a outro reino. Escolha o reino na tabela principal, depois identifique a primeira ação concreta e a evidência necessária em seu guia. Se alguma etapa permanecer ambígua, revise o arquivo responsável. Evite barreiras genéricas não relacionadas à tarefa.
Mantenha o sabor vivo em um lema, lore e uma frase de trabalho ocasional, como “O que dizemos aos bugs? Hoje não.” Combine com orientação de engenharia útil. Remova palavras que não adicionam nem uma decisão nem caráter. Siga o fluxo de trabalho de publicação do repositório e verifique links relativos e a descoberta do skill quando afetados.