| type | Skill |
| name | self-improve |
| category | evolution |
| description | Improve the agent itself, or audit its recent performance - better skills, prompts, workflows, and config, plus a quality/reliability/memory-hygiene review of what it did and what failed |
| var | |
| tags | ["meta"] |
${var} — Mode selector, optionally with a focus area, as mode or mode:focus.
- empty or
improve → improve mode: find and fix the highest-impact issue from recent logs, then propose + apply the fix via PR (default).
improve:<area> (or a bare area like notifications) → improve mode focused on that specific area (e.g. heartbeat, notifications, memory).
audit → audit mode: review what the agent did, what failed, and what to improve; save a full review and apply safe, obvious fixes directly.
audit:<area> → audit mode focused on that specific area (e.g. reliability, memory).
Setup (both modes)
Parse ${var} into a mode and an optional focus area:
- Split on the first
: — the part before is the mode, the part after is the focus.
- If the mode is
audit → run the Mode: audit branch below (focus = optional area to concentrate the review on).
- If the mode is
improve or empty → run the Mode: improve branch below (focus = optional area to fix).
- If the token is neither keyword but non-empty (e.g.
notifications) → treat it as improve mode with the whole ${var} as the focus area (backward compatibility).
Then:
- Read
memory/MEMORY.md for high-level context and goals.
- Read recent
memory/logs/ (improve mode: last 2 days; audit mode: last 7 days) for errors, failures, and quality issues.
If a focus area is set, concentrate the run on that area.
Mode: improve (default)
Improve the agent itself based on recent performance. ONE change per run.
Steps
-
Check for open improvement PRs — don't pile up unreviewed work:
OPEN_PRS=$(gh pr list --state open --json title,number --jq '[.[] | select(.title | test("^(fix|feat|chore)\\("; "i"))] | length')
If there are already 3+ open improvement PRs, log "self-improve: 3+ open PRs, waiting for review" and exit. Don't create more debt.
-
Identify what to improve. If the focus area is empty, scan for issues:
- Read
memory/logs/ from last 2 days — look for:
- Skills that failed or produced low-quality output
- Errors, timeouts, "zero output", rate limiting
- Notifications that didn't send or were truncated
- Memory consolidation problems
- Read
memory/cron-state.json for skills with low success rates
- Read
output/articles/repo-actions-*.md from last 7 days for self-improvement ideas
- Pick the highest-impact, smallest-effort fix. One change per run.
-
Understand the area you're fixing. Read the relevant files:
- Skills:
skills/{name}/SKILL.md
- Config:
aeon.yml
- Workflows:
.github/workflows/*.yml
- Agent instructions:
CLAUDE.md
- Dashboard:
apps/dashboard/ (if UI-related)
Understand the current behavior before changing anything.
-
Implement the fix. Make minimal, targeted changes:
- If a skill prompt is unclear → rewrite the ambiguous section
- If a skill is hitting rate limits → add backoff logic or reduce frequency
- If output quality is low → tighten the prompt, add examples, clarify format
- If a notification is broken → fix the formatting or truncation
- If a config is wrong → fix aeon.yml
Do NOT:
- Rewrite entire skills from scratch
- Add new features (that's create-skill's job)
- Change the core architecture
- Modify secrets or environment variables
-
Create a branch and PR:
git checkout -b fix/self-improve-${today}
git add -A
git commit -m
Guidelines
- ONE fix per run. Don't bundle unrelated changes.
- Smallest viable fix. A one-line prompt tweak > a full rewrite.
- If you can't find anything to improve, that's fine. Log "self-improve: everything looks healthy" and exit.
- Never modify workflow files (.github/workflows/) — only skill files, CLAUDE.md, and aeon.yml.
- Don't create circular improvements (e.g. don't improve self-improve).
Mode: audit
Audit what the agent did, what failed, and what to improve. Produce a full review, apply safe fixes, and surface recommendations.
Steps
Read memory/MEMORY.md for context and goals. Read ALL memory/logs/ entries from the last 7 days.
- Audit quality of outputs:
- Read recent articles in
output/articles/ — are they substantive or formulaic?
- Check recent notifications in logs — were they useful or noisy?
- Review any PR comments posted — were they actionable?
- Audit reliability:
- How many skills ran vs expected?
- Any repeated errors or patterns of failure?
- Are monitors catching real issues or always returning OK?
- Audit memory hygiene:
- Is
MEMORY.md current and under 50 lines?
- Are logs structured consistently?
- Any stale data that should be cleaned?
- Generate improvement recommendations:
- Skills to add, modify, or disable
- Schedule adjustments
- Config changes (feeds, repos, addresses to add/remove)
- Quality improvements (better prompts, new data sources)
- Save the full review to
output/articles/self-review-${today}.md.
- Apply any safe, obvious improvements directly:
- Prune stale
MEMORY.md entries
- Update
feeds.yml if feeds are dead
- Send a summary via
./notify:
*Self Review — ${today}*
Quality: assessment
Reliability: X/Y skills ran
Actions taken: what was fixed
Recommendations: top 2-3 suggestions
- Log (see the shared
## Log section below).
Log
After completing the run, append a log entry to memory/logs/${today}.md under a single ### self-improve heading, with a discriminator line naming the mode that ran:
### self-improve
- **Mode:** improve (or: audit)
Then, for improve mode:
- **Target:** [what was improved]
- **Problem:** [what was failing]
- **Fix:** [what was changed]
- **PR:** [url]
For audit mode:
- **Review:** output/articles/self-review-${today}.md
- **Quality:** [assessment]
- **Reliability:** [X/Y skills ran]
- **Actions taken:** [what was fixed directly]
- **Recommendations:** [top 2-3]
Network note
Write mode. Both branches touch the repo (improve opens a PR via git/gh; audit writes output/articles/self-review-${today}.md and may prune MEMORY.md/feeds.yml). For the GitHub API, use the gh CLI (gh pr list, gh pr create) — it handles auth internally, so no $SECRET ever touches the command line (a bare secret on the line is what the Bash permission layer refuses; there is no network sandbox). No pre-fetch or post-process side-channel is needed.