Evolve
Audit one part of the code and rank what to improve. Changes nothing.
$ npx skills add tonygorb/skills --skill evolvePick your agents from a list.
$ npx skills add tonygorb/skills --skill evolve -g -a claude-code -yInstalls into ~/.claude/skills/.
Open CustomizeSkills and upload it.
$ npx skills add tonygorb/skills --skill evolve -g -a codex -yInstalls into ~/.agents/skills/.
$ npx skills add tonygorb/skills --skill evolve -g -a cursor -yInstalls into ~/.agents/skills/.
$ npx skills add tonygorb/skills --skill evolve -g -a github-copilot -yInstalls into ~/.agents/skills/.
$ npx skills add tonygorb/skills --skill evolve -g -a gemini-cli -yInstalls into ~/.agents/skills/.
$ npx skills add tonygorb/skills --skill evolve -g -a opencode -yInstalls into ~/.agents/skills/.
$ npx skills add tonygorb/skills --skill evolve -g -a windsurf -yInstalls into ~/.codeium/windsurf/skills/.
Your agent uses it when you say
- “is this outdated”
- “how could X be better”
What it does
Propose upgrades; never apply them in the same run. The output is a ranked list the user picks from.
How it works
- 1Baseline
- 2Current practice
- 3Disqualify
Evolve
Propose upgrades; never apply them in the same run. The output is a ranked list the user picks from.
Scope
One area per run (UI, data layer, auth, testing, caching, one flow). Asked to evolve "everything": ask which area first.
Process
- Baseline. Read the project's own rules for that area (AGENTS.md, a design doc, an ADR) and the actual code. The current way is intentional: an upgrade has to beat it, not just differ.
- Current practice. Check the docs of the versions actually installed (your training data may be older than the code), and the codebase's own newest screens: often the best idea already exists in one place and should spread.
- Disqualify anything that breaks a hard rule of the project. Breaking an invariant isn't an upgrade.
Output: always this table, ranked by value for cost
| # | Upgrade | Benefit | Cost (S/M/L) | Risk | Files touched |
|---|
Under it, at most three sentences per row: what changes, why it beats the current way, what could break. End with your recommended pick and what you'd do first once it's approved.
After approval (a separate run)
Implement it the normal way, then verify (build, tests, a look at the UI if it changed), then update the doc that describes the area.