Changelog
Source:NEWS.md
mizerAgents 0.3.2.2
New features
-
New
connect_mizer_agent()hands your R session to the agent. This is the one step of the setup you repeat every session, and it was the only one with no entry in this package’s reference index: you had to know the name of a second package to finish a job you started here. It wrapsbtw::btw_mcp_session(), which still does the work, and adds what btw cannot know because it knows nothing about your project — which agents are configured to reach the session you are handing over, and whether they may run code in it. If none are, it says so rather than connecting silently to nothing. btw stays inSuggests; you get an actionable error if it is not installed.The
.Rprofileline written byrprofile = TRUEstill callsbtw::btw_mcp_session()directly, so that a project starts cleanly for someone who does not have mizerAgents installed.It also refuses to connect a session that is already connected. Calling
btw::btw_mcp_session()twice does not refresh the connection but breaks it: the second call opens a second connection without releasing the first, after which the session stops answering agents and disappears from theirlist_r_sessions, while the connection it abandoned still counts as a live session and spoils the automatic choice for every other agent on the machine. Only restarting R clears it. A project set up withrprofile = TRUEmakes this easy to walk into, since every session there is connected before you type anything.Which session an agent ends up in is now documented, in
?connect_mizer_agentand in a new section of the Using AI Agents with Mizer article. In short: connected sessions are listed per user rather than per project, and an agent picks the one whose working directory is the directory it was started in, falling back to the only session there is and then to a scratch R process of its own — which is silent, and is the usual explanation for an agent that cannot see the objects you can see. New
update_mizer_agent()refreshes a project while keeping the settings it was set up with. Since the skills now come from the installed mizer, “upgrade mizer, then refresh” is the normal way to get new guidance — butsetup_mizer_agent()is declarative, so a bare re-run re-declares its arguments from the defaults for a new project: it would switch code execution back on in a project set up withrun_r = FALSE, drop the package tools from one set up withpkg_dev = TRUE, and write config files for agents you had narrowed away from withagents.update_mizer_agent()reads those choices back from what the last run wrote and replays them, so a refresh changes content and nothing else. Nothing had to be stored to make that work, so it works for projects set up by earlier versions too. Pass any argument ofsetup_mizer_agent()through...to override what was detected.setup_mizer_agent()now reports any setting it changes relative to how the project was already set up, so that a plain re-run meant as a refresh at least says what it did rather than switching things over silently. A first run has nothing to compare against and says nothing.-
New
remove_mizer_agent()undoes everythingsetup_mizer_agent()did. It deletesMIZER-AGENTS.md, the marked block inAGENTS.md,CLAUDE.mdandGEMINI.md, the bundled skills in.claude/skills/, ther-mizerentry in each agent’s MCP config, and thebtw::btw_mcp_session()call in the project.Rprofile, and cleans up the directories those left empty.It removes only what this package wrote, following the same boundary setup respects: your notes outside the markers stay, other MCP servers in those config files stay, and a file that held nothing but our block is deleted with it. A skill file that has been edited in the project is no longer ours to delete, so it is kept and reported, as is any
NOTES.md. Thebtwpackage itself is left installed. -
The skills now come from the installed mizer, not from this package.
setup_mizer_agent()reads them fromsystem.file("skills", package = "mizer"), so the guidance an agent follows always describes the version of mizer the project actually runs. Previously this package shipped its own copy, which had to be kept in step with mizer by hand — the reason for the separate@devbranch — and could describe functions the user’s mizer did not have.In mizer each
SKILL.mdis now also the source of the matchingcheatsheet-*article on the mizer website, so the agent-facing and human-facing documentation are one document rather than two that drift apart.Skills arrived in mizer 3.2.2. Against an older mizer,
setup_mizer_agent()still writes everything else and reports that it installed no skills.
Documentation
-
The documentation no longer assumes RStudio. Almost nothing here ever depended on it: the agent runs in a terminal and reads files in the project directory, and
connect_mizer_agent()hands over the session through a socket, which works from RStudio, Positron, a bare R console, Emacs/ESS, the VS Code R extension or R over SSH alike. But the README, the vignette and the help pages said “in your RStudio console” throughout, which invited readers using anything else to conclude the package was not for them. They now say what is actually required, and the README and the vignette each carry a short section saying that the editor does not matter.The one genuine exception is named where it applies rather than assumed everywhere: reading the document you have open goes through
rstudioapi, so it works only in RStudio and Positron.MIZER-AGENTS.mdnow tells the agent this, and tells it that the failure says nothing about the rest of the session and that it should ask which file you mean — previously it was instructed to read the open document with no hint that the call could fail by editor rather than by mistake. The tool is still requested unconditionally, since these config files get committed and the editor a collaborator uses is not knowable when they are written.Also documented:
rprofile = TRUEdepends on R starting in the project directory, which RStudio and Positron guarantee for a project and a shell does not; and the IDE name shown bylist_r_sessionsis just the command that started R, not a requirement.
mizerAgents 0.3.2
New features
-
What a project learns about mizer now has somewhere to go. Previously
setup_mizer_agent()deleted each bundled skill’s directory and copied a fresh one over it, so anything an agent had added there — the very thing it had just learned about your model — vanished on the next run, silently.Three changes, one per kind of finding:
- Every deployed
SKILL.mdnow ends by pointing at aNOTES.mdbeside it: read it too, treat it as taking precedence, and record what you learn about this project there rather than inSKILL.md. That file is never written by this package. The same pointer goes into the skills index inMIZER-AGENTS.md, for agents that do not discover.claude/skills/themselves. - Skills are refreshed file by file, so a
NOTES.md— or a skill of your own — is left alone. The MD5 sums of the files installed are recorded in.claude/skills/.mizerAgents.json, which is what makes a file you have edited distinguishable from one an older version of the package installed. An edited file is kept and reported, with the new version written beside it as<file>.newto merge by hand; delete the.newfile and the skill goes back under package management. Without the record, the choice would be between clobbering your edits and freezing the skills at whatever shipped first. A project set up by 0.3.2 or earlier has no record, so the first run after upgrading refreshes the skills as it always did, and starts keeping one. Skills that later versions stop shipping are now removed rather than lingering, unless they have been edited here. - A lesson that is true of mizer in general rather than of one project belongs upstream, where every project gets it in the next release, so the skills tell agents to say so and offer to report it at https://github.com/sizespectrum/mizerAgents/issues.
- Every deployed
-
AGENTS.md,CLAUDE.mdandGEMINI.mdare now all handled the same way: each gets the package-managed mizer block, refreshed in place on every run with your own notes around it left alone. Previously onlyAGENTS.mdwas managed, andCLAUDE.md/GEMINI.mdwere written as one-line@AGENTS.mdshims only when they did not already exist — so a project that already had aCLAUDE.mdgot no mizer context in Claude Code at all. Neither tool falls back toAGENTS.md: Claude Code readsCLAUDE.md, and Gemini CLI readsGEMINI.mdunless itscontext.fileNamesetting says otherwise.The block is the only thing added. No
@AGENTS.mdimport is written or removed, so which of your own instructions reach which agent is unchanged: aCLAUDE.mdthat did not importAGENTS.mdstill does not, and one that did — including the one-line shims written by earlier versions — is left exactly as it was, since the block reaches the agent through the import. setup_mizer_agent()now connects the agent to your live R session, by configuring an MCP server namedr-mizer. The server comes from the btw package (CRAN, from Posit), which you install yourself; it is listed inSuggests. Its docs tools read the mizer that is actually installed, so the agent can check a signature rather than recall it, and it also gains a view of the objects in your global environment and of the document open in RStudio.-
The server is registered for every agent that supports project-level MCP configuration, each of which uses a different file:
.mcp.json(Claude Code),.codex/config.toml(Codex),.gemini/settings.json(Gemini CLI),.agents/mcp_config.json(Antigravity),.cursor/mcp.json(Cursor),.vscode/mcp.json(VS Code and Copilot in the editor) and.posit/assistant/settings.json(Posit Assistant, which runs in RStudio as well as Positron). All seven are written by default — they are small, they sit in different places, and each agent ignores the others’ — so a project set up on your machine works for a collaborator using a different agent. The newagentsargument narrows this, e.g.agents = c("claude", "posit").The schemas are not interchangeable: VS Code nests servers under
serverswhere everyone else usesmcpServers, and only Claude Code and VS Code document atypefield, so it is omitted for the rest rather than guessed at. A config with the wrong top-level key parses cleanly and silently does nothing, so there is a test pinning the shape of each generated file.GitHub Copilot CLI is the exception: it reads MCP servers only from the user-wide
~/.copilot/mcp-config.json, which a project setup function has no business editing, so the snippet to paste there is printed instead.Only the
r-mizerentry of each file is package-managed, so other servers you have configured survive. The JSON files are parsed and merged; an unparseable one is left untouched with a warning rather than overwritten. Codex’s TOML is managed as a marked block instead, to avoid taking on a TOML parser, and that block is always written at the end of the file — a TOML table header claims every key below it, so anywhere else it would swallow config written after it. -
inst/llms-full.txthas been removed (173 KB of the package’s 227 KB of bundled documentation). Its reference pages and articles were a snapshot of what?helpandvignette()already return from the installed mizer, so they duplicated btw’s docs tools while being pinned to whatever mizer was current when this package was last built. That is the same failure the reference card warns about: an argument list that has moved on does not announce itself, it just produces a call that runs and returns plausible numbers.inst/llms.txtstays. It is a curated index — every exported function with a one-line description, grouped by workflow stage — which no tool can regenerate, and it carries no argument lists, so it ages gracefully: a renamed function shows up as a lookup that fails rather than a call that quietly does the wrong thing.MIZER-AGENTS.mdnow sets the two apart explicitly, under a “Finding the right mizer function” heading: grep the index for which function you need, then read the installed help page for how to call it — viabtw_tool_docs_help_pagewhen the R session is connected, andRscript -e 'help(...)'when it is not. For the server to see your session you must run
btw::btw_mcp_session()in the RStudio console. The newrprofile = TRUEargument appends a guarded call to the project.Rprofileso that this happens on every startup.The agent can evaluate R code in that session, which is what allows it to project or calibrate a model and then see the resulting plots as images — the mode in which it is most useful for calibration work. The code runs in your global environment with no sandboxing and can overwrite your objects, so keep your work under version control;
run_r = FALSEgives a read-only connection instead, andr_session = FALSEskips the MCP setup altogether.New
pkg_dev = TRUEargument for projects that are themselves R packages, such as mizer extensions. It adds btw’s package development tools, so the agent can runload_all(),document(),test(),check()and test coverage in your session rather than shelling out todevtools. Becauseload_all()then leaves the new code live in the same session, the agent can immediately exercise the rate function it has just written, closing the write–load–test loop by itself. Off by default, as these tools do nothing useful in an ordinary modelling project.MIZER-AGENTS.mdgains a “The user’s live R session” section telling the agent to look mizer functions up in the installed help pages before calling them, to check what objects the user already has before rebuilding them, and — when execution is enabled — to look at the plots it produces before reporting success, and to avoid assigning over the user’s work.The reference card (
inst/AGENTS.md) opens with a “Do not write mizer code from memory” section: mizer’s API has moved on, most mizer code in the training data predates the installed version, and outdated calls often still run and return plausible numbers. It names the parameters recollection is most often stale on (thew_inf/w_repro_max/w_maxdistinction, thespecies_params(params) <-setter, thesetBevertonHolt()arguments) and tells agents to treat the installed mizer as authoritative over the card, and to report any discrepancy rather than work around it.The
AGENTS.mdshim written bysetup_mizer_agent()is no longer a bare@MIZER-AGENTS.mdline: it now carries a short note telling agents what the file is and to read it before touching mizer code. Codex and Copilot do not resolve@imports, so for them the note is what gets the card read; the import is kept for Claude Code and Gemini CLI, which inline it at startup whether or not the agent thinks it needs it.That block is now delimited by
<!-- mizerAgents: start -->and<!-- mizerAgents: end -->comments and refreshed in place on everysetup_mizer_agent()run, so later improvements to it reach projects that are already set up — previously it was written once and then frozen. It is refreshed wherever in the file it sits, and everything outside the markers is left alone, so your own project notes are preserved. Shims written by earlier versions have no markers and are migrated automatically; a note you have reworded yourself is treated as yours and left in place. The file is not touched at all when nothing would change, so re-running setup no longer dirties it.setup_mizer_agent()now adds a “Task skills” index toMIZER-AGENTS.md, generated from the bundled skills’ own frontmatter (name, one-line description, and path). This makes the skills usable by agents other than Claude Code, which do not discover.claude/skills/natively: they read the index from the always-loaded reference card and open the relevantSKILL.mdon demand, mirroring Claude Code’s lazy loading. No skill content is duplicated, so the index cannot drift from the skills.
Updated for mizer 3.2
The reference card (
inst/AGENTS.md) and thechange-parametersskill now recommendspecies_params(params) <-as the setter for scripts. As of mizer 3.2 it records the change ingiven_species_paramsand triggers recalculation of dependent rates, so the old advice to avoid it (and use onlygiven_species_params(params) <-) no longer applies;given_species_params()is now framed as the interactive alternative that warns about overrides. A version note points users on mizer < 3.2 back to the old rule.Species-parameter documentation now distinguishes
w_max(the purely computational size-grid boundary) fromw_repro_max(mizer 3.2’s name for the asymptotic size, i.e. the oldw_inf).Replaced the stale
matchYields()reference withcalibrateYield().
Skills
- Captured lessons from dynamics/limit-cycle work:
inst/AGENTS.mdgains “Numerical scheme for dynamics” and “Gotchas” sections;run-simulationgains a “Numerical scheme: watch for numerical diffusion” section (upwind scheme silently damping real oscillations, thesecond_order_w/tr_bdf2fix, and freezing the resource to isolate the phantom-jam feedback);change-parametersgains “The feeding level is set byf0, noth”.
mizerAgents 0.1.0
New features
setup_mizer_agent()creates or updates agent context files (MIZER-AGENTS.md,AGENTS.md,CLAUDE.md,GEMINI.md) in a mizer project directory so that AI coding agents pick up the mizer reference card and API documentation automatically on startup.setup_mizer_agent()also installs bundled Claude Code skills into.claude/skills/—analyse-and-plot,build-multispecies-model,calibrate-model,run-simulation,set-up-fishing,change-parameters, andextend-mizer— giving task-triggered, step-by-step guidance for common mizer workflows. The skills are refreshed on every call.Bundled
inst/skills/— one sub-directory with aSKILL.mdper skill, deployed bysetup_mizer_agent().Bundled
inst/AGENTS.md— concise mizer reference card covering the core workflow, key objects, species parameters, plotting, and extending mizer.Bundled
inst/llms.txt— concise index of the full mizer API, with links to online reference pages.Bundled
inst/llms-full.txt— full prose documentation for every exported mizer function, intended for agentgrepsearches.