improve-agent
Skill2 starsChanged 6 months agoMITView on GitHub
Use when asked to improve, iterate, or build a better version of an existing Kaggle simulation/agent competition bot. Triggers on "improve the agent", "make a better version", "vN", "iterate on agent", "what should we try next", or any request to advance beyond the current best submission.
We split this skill into the rules it gives an agent
9 rules. 0 are common, 3 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 8 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Iron rule: No new version without a written hypothesis FIRST (log-experiment).
- Distinctive: line 18
After reading ladder replays that reveal a pattern
- Very specific: line 19
After a submission regresses (post-submission-review pointed at a root cause)
- Distinctive: line 37
Ask: what did the opponent do that we couldn't answer?
- Very specific: line 45
Read experiments/strategy_evolution.md or equivalent if it exists.
- Distinctive: line 86
No prints or logging to stdout inside the agent — kaggle-environments may reject it.
- Very specific: line 111
If submitting → invoke submit-competition, then post-submission-review after warmup.
- Very specific: line 115
If something surprised you (positive or negative), invoke capture-learning immediately.
- Very specific: line 130
If a version regresses, keep the folder, mark it in LOG.md, and branch next iteration from the last winner.
“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
improve-agent
Overview
Systematic agent improvement loop for simulation competitions. Each iteration is one scientific cycle: diagnose → hypothesize → implement → verify → decide.
Iron rule: No new version without a written hypothesis FIRST (log-experiment). No submission without local eval FIRST (run-local-eval).
When to Use
- User says "improve", "make it better", "next version", "iterate", "vN", "what should we try"
- Current agent has a known failure mode or rating ceiling
- After reading ladder replays that reveal a pattern
- After a submission regresses (
post-submission-reviewpointed at a root cause)
Step-by-Step Improvement Loop
1. Orient — understand current state
cat competitions/<slug>/submissions/LOG.md
cat competitions/<slug>/experiments/EXPERIMENTS.md
ls competitions/<slug>/agents/Then invoke recall-learnings — cite any learning IDs that apply to the proposed direction.
2. Diagnose — find the real failure mode
For simulation competitions, do ladder forensics before coding:
- Download or review recent episode replays (via MCP or stored in
replays/). - Ask: what did the opponent do that we couldn't answer?
Diagnostic questions to ask about any simulation agent:
- Is the agent losing early (first N turns) or late? → early = setup/defense; late = scaling/endgame
- Is it losing by a small margin or getting crushed? → small = tune; crushed = structural flaw
- Does it lose to specific strategies or broadly? → specific = exploit; broad = fundamentals
- Does it fail on certain seeds / map states? → seed-dependent = brittle heuristic
Read experiments/strategy_evolution.md or equivalent if it exists.
Do NOT skip diagnosis. Coding before knowing the root cause creates compound regressions.
3. Pick ONE hypothesis
One change per version. Compound changes make it impossible to attribute outcomes.
Good hypotheses (direction + magnitude):
- "Increasing fleet floor from 12 to 20 will raise capture success rate and prevent intercepts"
- "Adding reinforcement dispatch before attack selection will reduce first-planet-loss rate"
- "Lead-targeting fast units will add 5-8% win rate on maps with high mobility"
Bad hypotheses:
- "Rewrite the strategy to be smarter" (unmeasurable)
- "Fix a few things and see if it helps" (compound, unattributable)
4. Log the experiment FIRST
invoke: log-experimentFill in: hypothesis, setup (seeds, match format), success criteria (numeric), abort condition.
Do not write any agent code until log-experiment is done.
5. Implement in a new versioned folder
# Name pattern: vN_<short_descriptor>
cp -r competitions/<slug>/agents/v<N-1>_<prior>/ \
competitions/<slug>/agents/v<N>_<descriptor>/
# Edit agent.py — make only the change in the hypothesisKey invariants for simulation agents:
- The entry-point function (e.g.
def agent(obs):) must be the last top-leveldefin the file — kaggle-environments picks the last one. - Time budget: stay at or below 80% of the per-turn actTimeout.
- Handle all player-count variants the competition supports (1v1, FFA, etc.).
- Define a fallback move for every code branch — never let the agent return
None. - No prints or logging to stdout inside the agent — kaggle-environments may reject it.
6. Run local eval — compare against prior versions
invoke: run-local-evalMinimum benchmark matrix:
vNvsv(N-1): must win > 55% (if not, hypothesis likely failed)vNvsv1_baseline: sanity floor — should always beat the original- FFA or multi-player variant: vN should lead or not regress
Record per-seed win/loss, key game metrics (fleet size, turn of first loss, etc.).
7. Decide: submit / iterate / abort
| Local result | Decision |
| Wins > 60% vs prior best | Candidate for submission |
| Wins 50–60% vs prior best | Investigate why — iterate first |
| Wins < 50% vs prior best | Abort. Document lesson in EXPERIMENTS.md. Try a different hypothesis. |
Never submit a version that regresses against the prior best in local eval.
If submitting → invoke submit-competition, then post-submission-review after warmup.
8. Capture learning
If something surprised you (positive or negative), invoke capture-learning immediately.
Versioning Convention
agents/
v1_baseline/ # first working agent
v2_<change>/ # one change from v1
v3_<change>/ # one change from v2 (or best-so-far)Version name = v<N>_<2-3 word descriptor of the ONE change>.
If a version regresses, keep the folder, mark it in LOG.md, and branch next iteration from the last winner.
Common Mistakes
| Mistake | Fix |
| Coding before diagnosing | Always diagnose → hypothesize → code |
| Submitting without local eval | Local eval catches crashes and regressions |
| Compound changes ("fixing a few things") | One hypothesis per version |
| Entry-point function not last in file | Move it to end; imports and helpers above |
| Missing fallback move | Add default action in every branch |
| Forgetting multi-player/FFA branch | Test with all supported player counts |
Skipping log-experiment | Log it first — even one sentence |
| Stdout/print inside agent | Remove all prints; use a debug flag gated by a variable |
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- agno-agi/agentos-docker★ 9same name
- duvoai/skills★ 8same name
- agno-agi/agentos-render★ 4same name
- stempeck/agentfactory★ 3same name
- agno-agi/agentos-fly★ 2same name
- agno-agi/agentos-helm★ 1same name
- mahdimor/AIK★ 1same name
- farzanmrz/meta-dev★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use create-evals, deploy-platform and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
agno-agiSkillcreate-evals
Author eval coverage for an agent in this AgentOS — map what the agent promises, mine real sessions and eval history from Postgres for scenarios, propose capabilities worth testing, then write, run, and audit Case entries in evals/cases.py. Use when the user wants evals created, coverage added, or an agent's behavior pinned down as tests. For failing suites or agent hardening, use improve instead.
Also in 5 projects that use this
agno-agiSkilldeploy-platform
Deploy this AgentOS using its own provider instructions, configure JWT verification, and verify the public service. Use for first deployment, redeployment, or production configuration changes.
Also in 5 projects that use this
MicrosoftSkillcreate-agent
Create a new MCS2 Copilot Studio agent and PAC-connected local workspace with `pac copilot init`, then optionally add modern instructions, skills, tools, knowledge, and settings before synchronizing it. Use when the user asks to create, scaffold, initialize, or build a Copilot Studio agent.
Also in 6 projects that use this
- +3 more from agno-agi
In this repository14 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- capture-learningSkill
- debug-agentSkill
- eda-auditSkill
- ensemble-blendSkill
- leaderboard-checkSkill
- log-experimentSkill
- new-competitionSkill
- post-submission-reviewSkill
- preflight-consultSkill
- recall-learningsSkill
- retrospect-sessionSkill
- run-local-evalSkill
- submit-competitionSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

