evolve-agent
Evolve an Existing Agent
Improve, extend, or create an advanced variant of an agent that was originally authored with create-agent. This procedure covers the maintenance side of the agent lifecycle: assessing gaps against best practices, applying targeted improvements to the persona definition, bumping versions, and keeping the registry and cross-references in sync.
When to Use
- An agent's skills list is outdated after new skills were added to the library
- User feedback reveals missing capabilities, unclear purpose, or weak examples
- Tool requirements have changed (new MCP server, tool removed, privilege reduction needed)
- An agent's scope needs sharpening — it overlaps with another agent or is too broad
- An advanced variant is needed alongside the original (e.g.,
r-developerandr-developer-advanced) - Related agents or teams were added and cross-references in See Also are stale
Inputs
- Required: Path to the existing agent file to evolve (e.g.,
agents/r-developer.md) - Required: Evolution trigger (feedback, new skills, tool change, scope overlap, team integration, discovered limitations)
- Optional: Target version bump magnitude (patch, minor, major)
- Optional: Whether to create an advanced variant instead of refining in-place (default: refine in-place)
Procedure
Step 1: Assess the Current Agent
Read the existing agent file and evaluate each section against the quality checklist from guides/agent-best-practices.md:
| Section | What to Check | Common Issues |
|---|---|---|
| Frontmatter | All required fields present (name, description, tools, model, version, author) |
Missing tags, stale version, wrong priority |
| Purpose | Specific problem statement, not generic "helps with X" | Vague or overlapping with another agent |
| Capabilities | Concrete, verifiable capabilities with bold lead-ins | Generic ("handles development"), no grouping |
| Available Skills | Matches frontmatter skills list, all IDs exist in registry |
Stale IDs, missing new skills, lists default skills unnecessarily |
| Usage Scenarios | 2-3 realistic scenarios with invocation patterns | Placeholder text, unrealistic examples |
| Examples | Shows user request and agent behavior | Missing or trivial examples |
| Limitations | 3-5 honest constraints | Too few, too vague, or missing entirely |
| See Also | Valid cross-references to agents, guides, teams | Stale links to renamed or removed files |
# 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
Expected: A list of specific gaps, weaknesses, or improvement opportunities organized by section.
On failure: If the agent file does not exist or has no frontmatter, this skill does not apply — use create-agent instead to author it from scratch.
Step 2: Gather Evolution Requirements
Identify and categorize what triggered the evolution:
| Trigger | Example | Typical Scope |
|---|---|---|
| User feedback | "Agent missed XSS in review" | Add skill or capability |
| New skills available | Library gained analyze-api-security |
Update skills list |
| Tool change | New MCP server available | Add to tools/mcp_servers |
| Scope overlap | Two agents both claim "code review" | Sharpen purpose and limitations |
| Team integration | Agent added to a new team | Update See Also, verify capabilities |
| Model upgrade | Task requires deeper reasoning | Change model field |
| Privilege reduction | Agent has Bash but only reads files | Remove unnecessary tools |
Document the specific changes needed before editing. List each change with its target section:
- Frontmatter: add `new-skill-id` to skills list
- Capabilities: add "API Security Analysis" capability
- Available Skills: add `new-skill-id` with description
- Limitations: remove outdated limitation about missing skill
- See Also: add link to new team that includes this agent
Expected: A concrete list of changes, each mapped to a specific section of the agent file.
On failure: If the changes are unclear, consult the user for clarification before proceeding. Vague evolution goals produce vague improvements.
Step 3: Choose Evolution Scope
Use this decision matrix to determine whether to refine in-place or create a variant:
| Criteria | Refinement (in-place) | Advanced Variant (new agent) |
|---|---|---|
| Agent ID | Unchanged | New ID: <agent>-advanced or <agent>-<specialty> |
| File path | Same .md file |
New file in agents/ |
| Version bump | Patch or minor | Starts at 1.0.0 |
| Model | May change | Often higher (e.g., sonnet → opus) |
| Registry | Update existing entry | New entry added |
| Original agent | Modified directly | Left intact, gains See Also cross-reference |
Refinement: Choose when updating skills, fixing documentation, sharpening scope, or adjusting tools. The agent keeps its identity.
Variant: Choose when the evolved version would serve a substantially different audience, require a different model, or add capabilities that would make the original too broad. The original stays as-is for simpler use cases.
Expected: A clear decision — refinement or variant — with rationale.
On failure: If unsure, default to refinement. You can always extract a variant later; it is harder to merge one back.
Step 4: Apply Changes to the Agent File
For Refinements
Edit the existing agent file directly:
- Frontmatter: Update
skills,tools,tags,model,priority,mcp_serversas needed - Purpose/Capabilities: Revise to reflect new scope or added functionality
- Available Skills: Add new skills with descriptions, remove deprecated ones
- Usage Scenarios: Add or revise scenarios to demonstrate new capabilities
- Limitations: Remove constraints that no longer apply, add new honest ones
- See Also: Update cross-references to reflect current agent/team/guide landscape
Follow these editing rules:
- Preserve all existing sections — add content, do not remove sections
- Keep the Available Skills section in sync with the frontmatter
skillslist - Do not add default skills (
meditate,heal) to frontmatter unless they are core to the agent's methodology - Verify each skill ID exists:
grep "id: skill-name" skills/_registry.yml
For Variants
# 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
Expected: The agent file (refined or new variant) passes the assessment checklist from Step 1.
On failure: If an edit breaks the document structure, use git diff to review changes and revert partial edits with git checkout -- <file>.
Step 5: Update Version and Metadata
Bump the version field in frontmatter following semantic versioning:
| Change Type | Version Bump | Example |
|---|---|---|
| Typo fix, wording clarification | Patch: 1.0.0 → 1.0.1 | Fixed unclear limitation |
| New skills added, capability expanded | Minor: 1.0.0 → 1.1.0 | Added 3 new skills from library |
| Restructured purpose, changed model | Major: 1.0.0 → 2.0.0 | Narrowed scope, upgraded to opus |
Also update:
updateddate to the current datetagsif the agent's domain coverage changeddescriptionif the purpose is materially differentpriorityif the agent's importance relative to others changed
Expected: Frontmatter version and updated reflect the magnitude and date of changes. New variants start at "1.0.0".
On failure: If you forget to bump the version, the next evolution will have no way to distinguish the current state from the previous one. Always bump before committing.
Step 6: Update Registry and Cross-References
For Refinements
Update the existing entry in agents/_registry.yml to match the revised frontmatter:
# Find the agent's registry entry
grep -A 10 "id: <agent-name>" agents/_registry.yml
Update description, tags, tools, and skills fields to match the agent file. No count change is needed.
Update cross-references in other files if the agent's capabilities or name changed:
# 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
For Variants
Add the new agent to agents/_registry.yml in alphabetical position:
- 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
Then:
- Increment
total_agentsat the top of the registry - Add See Also cross-reference in the original agent pointing to the variant
- Add See Also cross-reference in the variant pointing to the original
- The
.claude/agents/symlink toagents/means the variant is automatically discoverable
Expected: Registry entry matches the agent file frontmatter. For variants, total_agents equals the actual number of agent entries.
On failure: Count entries with grep -c "^ - id:" agents/_registry.yml and verify it matches total_agents.
Step 7: Validate the Evolved Agent
Run the full validation checklist:
- Agent file exists at the expected path
- YAML frontmatter parses without errors
-
versionwas bumped (refinement) or set to "1.0.0" (variant) -
updateddate reflects today - All required sections present: Purpose, Capabilities, Available Skills, Usage Scenarios, Examples, Limitations, See Also
- Skills in frontmatter match the Available Skills section
- All skill IDs exist in
skills/_registry.yml - Default skills (
meditate,heal) are not listed unless core to methodology - Tools list follows least-privilege principle
- Registry entry exists and matches frontmatter
- For variants:
total_agentscount matches actual count on disk - Cross-references are bidirectional (original ↔ variant)
-
git diffshows no accidental deletions from the original content
# 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
Expected: All checklist items pass. The evolved agent is ready to commit.
On failure: Address each failing item individually. The most common post-evolution issues are stale skill IDs in the Available Skills section and a forgotten updated date.
Validation
- Agent file exists and has valid YAML frontmatter
-
versionfield reflects the changes made -
updateddate is current - All sections present and internally consistent
- Frontmatter
skillsarray matches the Available Skills section - All skill IDs exist in
skills/_registry.yml - Default skills not listed unnecessarily
- Registry entry matches the agent file
- For variants: new entry in
agents/_registry.ymlwith correct path - For variants:
total_agentscount updated - Cross-references are valid (no broken links in See Also)
-
git diffconfirms no accidental content removal
Common Pitfalls
- Forgetting to bump version: Without version bumps, there is no way to track what changed or when. Always update
versionandupdatedin frontmatter before committing. - Skills list drift: The frontmatter
skillsarray and the## Available Skillssection must stay in sync. Updating one without the other creates confusion for both humans and tooling. - Listing default skills unnecessarily: Adding
meditateorhealto the frontmatter when they are already inherited from the registry. Only list them if they are core to the agent's methodology (e.g.,mystic,alchemist). - Tool over-provisioning during evolution: Adding
BashorWebFetchduring an evolution "just in case." Every tool addition should be justified by a specific new capability. - Stale See Also after variant creation: When creating a variant, both the original and the variant need to reference each other. One-directional references leave the graph incomplete.
- Registry entry not updated: After changing an agent's skills, tools, or description, the
agents/_registry.ymlentry must be updated to match. Stale registry entries cause discovery and tooling failures.
Related Skills
create-agent— foundation for authoring new agents; evolve-agent assumes this was followed originallyevolve-skill— the parallel procedure for evolving SKILL.md filescommit-changes— commit the evolved agent with a descriptive message