executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
evolve-agentEvoluciona una definición de agente existente refinando su persona en el lugar o creando una variante avanzada. Cubre la evaluación del agente actual frente a las mejores prácticas, la recopilación de requisitos de evolución, la elección del alcance (refinamiento vs. variante), la aplicación de cambios a las habilidades, herramientas, capacidades y limitaci…
Independent GitHub snapshot · Automated classification · Original documentation governs
Mejora, extiende o crea una variante avanzada de un agente que fue creado originalmente con create-agent. Este procedimiento cubre el lado de mantenimiento del ciclo de vida del agente: evaluar brechas frente a las mejores prácticas, aplicar mejoras específicas a la definición de la persona, actualizar versiones y mantener sincronizados el registro y las referencias cruzadas.
r-developer y r-developer-advanced)agents/r-developer.md)Leer el archivo de agente existente y evaluar cada sección frente a la lista de verificación de calidad de guides/agent-best-practices.md:
| Sección | Qué verificar | Problemas comunes |
|---|---|---|
| Frontmatter | Todos los campos requeridos presentes (name, description, tools, model, version, author) | Falta tags, version obsoleta, priority incorrecta |
| Purpose | Declaración de problema específica, no genérica "ayuda con X" | Vaga o superpuesta con otro agente |
| Capabilities | Capacidades concretas y verificables con encabezados en negrita | Genérico ("maneja el desarrollo"), sin agrupación |
| Available Skills | Coincide con la lista skills del frontmatter, todos los IDs existen en el registro | IDs obsoletos, faltan nuevas habilidades, lista habilidades por defecto innecesariamente |
| Usage Scenarios | 2-3 escenarios realistas con patrones de invocación | Texto de marcador, ejemplos poco realistas |
| Examples | Muestra la solicitud del usuario y el comportamiento del agente | Faltantes o triviales |
| Limitations | 3-5 restricciones honestas | Muy pocas, demasiado vagas o completamente faltantes |
| See Also | Referencias cruzadas válidas a agentes, guías, equipos | Enlaces obsoletos a archivos renombrados o eliminados |
# Read the agent file
cat agents/<agent-name>.md
# Check frontmatter parses
head -20 agents/<agent-name>.md
# Verify skills in frontmatter exist in registry
grep "skills:" -A 20 agents/<agent-name>.md
# Check if agent is referenced by any team
grep -r "<agent-name>" teams/*.md
Esperado: Una lista de brechas específicas, debilidades u oportunidades de mejora organizadas por sección.
En caso de fallo: Si el archivo del agente no existe o no tiene frontmatter, esta habilidad no aplica — usar create-agent en su lugar para crearlo desde cero.
Identificar y categorizar qué desencadenó la evolución:
| Disparador | Ejemplo | Alcance típico |
|---|---|---|
| Comentario del usuario | "El agente no detectó XSS en la revisión" | Añadir habilidad o capacidad |
| Nuevas habilidades disponibles | La biblioteca ganó analyze-api-security | Actualizar lista de habilidades |
| Cambio de herramienta | Nuevo servidor MCP disponible | Añadir a tools/mcp_servers |
| Solapamiento de alcance | Dos agentes reclaman "revisión de código" | Afinar propósito y limitaciones |
| Integración en equipo | Agente añadido a un nuevo equipo | Actualizar Ver También, verificar capacidades |
| Actualización de modelo | La tarea requiere razonamiento más profundo | Cambiar el campo model |
| Reducción de privilegios | El agente tiene Bash pero solo lee archivos | Eliminar herramientas innecesarias |
Documentar los cambios específicos necesarios antes de editar. Listar cada cambio con su sección objetivo:
- Frontmatter: añadir `new-skill-id` a la lista de habilidades
- Capabilities: añadir capacidad "API Security Analysis"
- Available Skills: añadir `new-skill-id` con descripción
- Limitations: eliminar limitación desactualizada sobre habilidad faltante
- See Also: añadir enlace al nuevo equipo que incluye este agente
Esperado: Una lista concreta de cambios, cada uno mapeado a una sección específica del archivo del agente.
En caso de fallo: Si los cambios no están claros, consultar al usuario para aclaración antes de proceder. Los objetivos de evolución vagos producen mejoras vagas.
Usar esta matriz de decisión para determinar si refinar en el lugar o crear una variante:
| Criterios | Refinamiento (en el lugar) | Variante Avanzada (nuevo agente) |
|---|---|---|
| ID del agente | Sin cambios | Nuevo ID: <agent>-advanced o <agent>-<specialty> |
| Ruta del archivo | Mismo archivo .md | Nuevo archivo en agents/ |
| Incremento de versión | Parche o menor | Comienza en 1.0.0 |
| Modelo | Puede cambiar | A menudo más alto (p.ej., sonnet → opus) |
| Registro | Actualizar entrada existente | Nueva entrada añadida |
| Agente original | Modificado directamente | Intacto, gana referencia cruzada en Ver También |
Refinamiento: Elegir al actualizar habilidades, corregir documentación, afinar alcance o ajustar herramientas. El agente mantiene su identidad.
Variante: Elegir cuando la versión evolucionada serviría a una audiencia sustancialmente diferente, requeriría un modelo diferente o añadiría capacidades que harían al original demasiado amplio. El original permanece como está para casos de uso más simples.
Esperado: Una decisión clara — refinamiento o variante — con justificación.
En caso de fallo: Si no estás seguro, por defecto optar por refinamiento. Siempre puedes extraer una variante más tarde; es más difícil fusionarla de vuelta.
Editar el archivo de agente existente directamente:
skills, tools, tags, model, priority, mcp_servers según sea necesarioSeguir estas reglas de edición:
skills del frontmattermeditate, heal) al frontmatter a menos que sean fundamentales para la metodología del agentegrep "id: skill-name" skills/_registry.yml# Copy the original as a starting point
cp agents/<agent-name>.md agents/<agent-name>-advanced.md
# Edit the variant:
# - Change `name` to `<agent-name>-advanced`
# - Update `description` to reflect the advanced scope
# - Raise `model` if needed (e.g., sonnet → opus)
# - Reset `version` to "1.0.0"
# - Expand skills, capabilities, and examples for the advanced use case
# - Reference the original in See Also as a simpler alternative
Esperado: El archivo del agente (refinado o nueva variante) pasa la lista de verificación de evaluación del Paso 1.
En caso de fallo: Si una edición rompe la estructura del documento, usar git diff para revisar los cambios y revertir ediciones parciales con git checkout -- <file>.
Obligatorio cuando existen traducciones. Este paso se aplica tanto a autores humanos como a agentes de IA que siguen este procedimiento. No omitir — los valores obsoletos de
source_commithacen quenpm run validate:translationsinforme advertencias falsas de obsolescencia en todas las localizaciones.
Comprobar si existen traducciones para el agente evolucionado y actualizarlas para reflejar el nuevo estado de la fuente:
# Check for existing translations
ls i18n/*/agents/<agent-name>.md 2>/dev/null
npm run validate:translations
source_commit en el frontmatter de cada archivo traducido:npm run check:fence-propagation -- --id <agent-name>
node tools/provenance-field.mjs --field fence_basis_commit --set $(git rev-parse --short HEAD) <mirror paths>
evolve-agent(<agent-name>): <descripción de los cambios>
Translations flagged for re-sync: de, zh-CN, ja, es
Changed sections: <lista de secciones que cambiaron>
npm run translation:status
No se requiere ninguna acción. Continuar al Paso 5.
Aplazar la traducción de nuevas variantes hasta que la variante se estabilice (1-2 versiones). Traducir una variante v1.0 que puede cambiar sustancialmente para v1.2 desperdicia esfuerzo. Añadir traducciones después de que la variante haya sido refinada al menos una vez.
Esperado: Todos los archivos traducidos tienen source_commit actualizado al commit actual. El mensaje de commit indica qué localizaciones necesitan re-traducción y qué secciones cambiaron. npm run translation:status sale con 0.
En caso de fallo: Si sed no coincide con el campo del frontmatter, el archivo traducido puede tener un formato no estándar. Abrirlo manualmente y verificar que tiene source_commit en su frontmatter YAML. Si el campo falta, el archivo no se generó correctamente — regenerar con npm run translate:scaffold -- agents.
Incrementar el campo version en el frontmatter siguiendo el versionado semántico:
| Tipo de cambio | Incremento de versión | Ejemplo |
|---|---|---|
| Corrección tipográfica, aclaración de redacción | Parche: 1.0.0 → 1.0.1 | Limitación poco clara corregida |
| Nuevas habilidades añadidas, capacidad expandida | Menor: 1.0.0 → 1.1.0 | 3 nuevas habilidades añadidas de la biblioteca |
| Propósito reestructurado, modelo cambiado | Mayor: 1.0.0 → 2.0.0 | Alcance reducido, actualizado a opus |
También actualizar:
updated a la fecha actualtags si la cobertura de dominio del agente cambiódescription si el propósito es materialmente diferentepriority si la importancia del agente relativa a otros cambióEsperado: version y updated del frontmatter reflejan la magnitud y fecha de los cambios. Las nuevas variantes comienzan en "1.0.0".
En caso de fallo: Si olvidas incrementar la versión, la próxima evolución no tendrá forma de distinguir el estado actual del anterior. Siempre incrementar antes de confirmar.
Actualizar la entrada existente en agents/_registry.yml para que coincida con el frontmatter revisado:
# Find the agent's registry entry
grep -A 10 "id: <agent-name>" agents/_registry.yml
Actualizar los campos description, tags, tools y skills para que coincidan con el archivo del agente. No se necesita cambio de recuento.
Actualizar las referencias cruzadas en otros archivos si las capacidades o nombre del agente cambiaron:
# Check if any team references this agent
grep -r "<agent-name>" teams/*.md
# Check if any guide references this agent
grep -r "<agent-name>" guides/*.md
Añadir el nuevo agente a agents/_registry.yml en posición alfabética:
- id: <agent-name>-advanced
path: agents/<agent-name>-advanced.md
description: One-line description of the advanced variant
tags: [domain, specialty, advanced]
priority: normal
tools: [Read, Write, Edit, Bash, Grep, Glob]
skills:
- skill-id-one
- skill-id-two
Luego:
total_agents al inicio del registro.claude/agents/ a agents/ significa que la variante es automáticamente descubribleEsperado: La entrada del registro coincide con el frontmatter del archivo del agente. Para variantes, total_agents es igual al número real de entradas de agentes.
En caso de fallo: Contar entradas con grep -c "^ - id:" agents/_registry.yml y verificar que coincide con total_agents.
Ejecutar la lista de verificación de validación completa:
version fue incrementada (refinamiento) o establecida en "1.0.0" (variante)updated refleja hoyskills/_registry.ymlmeditate, heal) no están listadas a menos que sean fundamentales para la metodologíatotal_agents coincide con el recuento real en discogit diff no muestra eliminaciones accidentales del contenido original# Verify frontmatter
head -20 agents/<agent-name>.md
# Check skills exist
for skill in skill-a skill-b; do
grep "id: $skill" skills/_registry.yml
done
# Count agents on disk vs registry
ls agents/*.md | grep -v template | wc -l
grep total_agents agents/_registry.yml
# Review all changes
git diff
Esperado: Todos los elementos de la lista de verificación pasan. El agente evolucionado está listo para confirmar.
En caso de fallo: Abordar cada elemento fallido individualmente. Los problemas más comunes tras la evolución son IDs de habilidades obsoletos en la sección Available Skills y una fecha updated olvidada.
version refleja los cambios realizadosupdated es actualskills del frontmatter coincide con la sección Available Skillsskills/_registry.ymlagents/_registry.yml con la ruta correctatotal_agents actualizadogit diff confirma que no se eliminó contenido accidentalmenteversion y updated en el frontmatter antes de confirmar.skills del frontmatter y la sección ## Available Skills deben mantenerse sincronizados. Actualizar uno sin el otro crea confusión tanto para humanos como para las herramientas.meditate o heal al frontmatter cuando ya se heredan del registro. Solo listarlas si son fundamentales para la metodología del agente (p.ej., mystic, alchemist).Bash o WebFetch durante una evolución "por si acaso". Cada adición de herramienta debe justificarse por una nueva capacidad específica.agents/_registry.yml debe actualizarse para que coincida. Las entradas de registro obsoletas causan fallos de descubrimiento y de herramientas.create-agent — base para la creación de nuevos agentes; evolve-agent asume que esto se siguió originalmenteevolve-skill — el procedimiento paralelo para evolucionar archivos SKILL.mdcommit-changes — confirmar el agente evolucionado con un mensaje descriptivo