agentleFS
subarnasaikiasubarnasaikia/kaggle-skills/.claude/skills/improve-agent/SKILL.md

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
  1. Very specific:

    Iron rule: No new version without a written hypothesis FIRST (log-experiment).

    line 12
  2. Distinctive:

    After reading ladder replays that reveal a pattern

    line 18
  3. Very specific:

    After a submission regresses (post-submission-review pointed at a root cause)

    line 19
  4. Distinctive:

    Ask: what did the opponent do that we couldn't answer?

    line 37
  5. Very specific:

    Read experiments/strategy_evolution.md or equivalent if it exists.

    line 45
  6. Distinctive:

    No prints or logging to stdout inside the agent — kaggle-environments may reject it.

    line 86
  7. Very specific:

    If submitting → invoke submit-competition, then post-submission-review after warmup.

    line 111
  8. Very specific:

    If something surprised you (positive or negative), invoke capture-learning immediately.

    line 115
  9. Very specific:

    If a version regresses, keep the folder, mark it in LOG.md, and branch next iteration from the last winner.

    line 130

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-review pointed 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-experiment

Fill 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 hypothesis

Key invariants for simulation agents:

  • The entry-point function (e.g. def agent(obs):) must be the last top-level def in 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-eval

Minimum benchmark matrix:

  • vN vs v(N-1): must win > 55% (if not, hypothesis likely failed)
  • vN vs v1_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 resultDecision
Wins > 60% vs prior bestCandidate for submission
Wins 50–60% vs prior bestInvestigate why — iterate first
Wins < 50% vs prior bestAbort. 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

MistakeFix
Coding before diagnosingAlways diagnose → hypothesize → code
Submitting without local evalLocal eval catches crashes and regressions
Compound changes ("fixing a few things")One hypothesis per version
Entry-point function not last in fileMove it to end; imports and helpers above
Missing fallback moveAdd default action in every branch
Forgetting multi-player/FFA branchTest with all supported player counts
Skipping log-experimentLog it first — even one sentence
Stdout/print inside agentRemove all prints; use a debug flag gated by a variable

Download now (ZIP)

  • Other versions8 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 8

    1. agno-agi/agentos-docker★ 9same name
    2. duvoai/skills★ 8same name
    3. agno-agi/agentos-render★ 4same name
    4. stempeck/agentfactory★ 3same name
    5. agno-agi/agentos-fly★ 2same name
    6. agno-agi/agentos-helm★ 1same name
    7. mahdimor/AIK★ 1same name
    8. 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-agiSkill

      create-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-agiSkill

      deploy-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

    • MicrosoftSkill

      create-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.

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.