Improving Mudlet with AI agents

From Mudlet
Jump to navigation Jump to search

Mudlet ships ready-made Agent Skills that put an AI coding agent to work on quality: growing test coverage, fuzzing for crashes, and making the client faster. They live in .agents/skills/ in the source tree, and Claude Code, GitHub Copilot, Cursor and OpenAI Codex all read that directory automatically. Each skill is a step-by-step procedure ending in a concrete deliverable - a pull request or a well-reproduced bug report - and carries the measurement discipline and pitfalls learned doing this work by hand, so your agent does not rediscover them at your expense.

If work got you an AI coding agent subscription, this is a great way to spend it on open source.

What you need

  • A Mudlet checkout and an agent that reads Agent Skills: Claude Code (CLI or web), GitHub Copilot, Cursor, or OpenAI Codex.
  • On Claude Code on the web, nothing else - the repository provisions its own toolchain (Qt, compilers, test harnesses, coverage tools) when a session starts.
  • Locally, the agent sets itself up by reading the repository's build-mudlet skill. Linux is the smoothest ride; the coverage and fuzzing recipes are Linux-first.

The skills

The /name invocations below are Claude Code's spelling; Codex spells the same thing $name, and asking in plain words works in every agent.

improve-test-coverage

Measures Mudlet's real C++ line coverage, ranks files by how much untested weight they carry, and grows the suite - with Lua specs where possible, C++ functional tests where a spec cannot reach. It aims for a reasonable level rather than a vanity number, and proves every new test fails without the behavior it pins, because both test harnesses silently go green when miswired.

/improve-test-coverage ctelnet

Or just ask: "improve Mudlet's test coverage". Name a subsystem, or let it show you the ranking and pick from it.

fuzz-apis

Runs Mudlet's seeded, replayable in-process fuzzers against a sanitizer build to shake crashes and undefined behavior out of the telnet parser, trigger engine and scripting API. Whatever falls out gets reduced to a minimal reproduction and filed - or fixed on the spot with a regression test. A clean run extends the fuzzers to a surface nobody has hit yet.

/fuzz-apis the buffer API

improve-performance

Picks a subsystem with you - telnet throughput, the trigger engine, the 2D mapper, pathfinding, startup - then measures before touching anything, finds where the time actually goes, and proves the win with honest A/B numbers a reviewer can reproduce, including against past Mudlet releases.

/improve-performance the 2D mapper

What comes out the other end

Usually a branch and a pull request. Mudlet's policy for AI-assisted work applies: commits carry an Assisted-by trailer, and you - the human - build and test the change yourself before providing the Signed-off-by. Your agent knows this and will ask you. Bugs found along the way are filed as GitHub issues with an empirical reproduction, never from code reading alone.

See also