Summary

We built ArduinoIDE Agent, a Cursor-style fork of Arduino IDE 2.x where an AI agent writes sketches, compiles them, installs missing libraries, uploads, and reads serial output autonomously.

To wire the agent deeply into the IDE (live sketch context, build feedback, sidebar slot), we had to fork. We want to ask: would the maintainers be open in principle to a small set of generic extension points so plugins like ours can exist without forking?

Full RFC document: docs/rfc/0001-ai-assistant-extension-points.md

What we're proposing (in order of confidence)

1. BuildStateService — read-only snapshot of the last compile/upload outcome. Useful well beyond AI: "rerun last build", build history, CI integration. Already submitted as Expose last build outcome via BuildStateService #2903 since it stands alone.
2. Docs page under docs/contributor-guide/ showing how to build assistant-style plugins using existing Theia/Arduino IDE APIs (we found we didn't actually need new APIs for the panel + sketch context — only the build state).

Non-goals

• Bundling Claude / OpenAI / any AI provider into Arduino IDE
• Shipping an AI panel by default
• Changing existing services or default UI

Questions

1. Are you open in principle to small extension-point PRs like Expose last build outcome via BuildStateService #2903, even though no first-party feature uses them yet?
2. For Expose last build outcome via BuildStateService #2903 specifically — would you prefer a different name, different shape, or stronger API stability marking (e.g. @experimental)?
3. Would a docs PR explaining how to build assistant plugins be welcome?
4. Anything you'd want from us before reviewing further work (design doc, tests, sign-off, etc.)?

If the answer is "this isn't a direction the IDE wants to go," we'll keep our work as an independent distribution. Just wanted to ask before adding to your queue. Thanks!

Filed as an issue because Discussions isn't enabled on this repo. Happy to move if there's a preferred venue.