RFC Collecting "AI infrastructure" for work on scikit-learn

This issue is the result of a discussion at the monthly maintainer meeting. The goal is to collect ideas and practices from people who use AI tools to work on large projects like scikit-learn. I will call the collection of these ideas and practices "infrastructure" for this issue.

Once we have an overview of ideas and practices we will consider what to do next. One possibility is to create a separate repository that contains the "infrastructure" distilled from the ideas and practices in this issue. People can then checkout that repo "on top" of their scikit-learn checkout and benefit from the content for their AI workflows. Another option is that we add the "infrastructure" directly to the main repository. There are pros and cons to either of these options. There might even be more options, or a compromise.

Here are some of my inputs to the collection:

• https://jacobtomlinson.dev/posts/2026/guiding-your-contributors-agents-to-better-behaviours/ a blog post by @jacobtomlinson that talks about exactly this topic. It proposes adding skills to your repository the encode behaviour/limits that you want to be respected. For example, do not work on issues that are missing a "ready" label.
• "design documents" - When working with Cursor to convert an estimator to the array API I found that it got much better after spending some time creating "design documents" like these. I asked cursor to look at existing "array API'ified" estimators, the testing infra, etc and create documents that explain how things work. I then went over them quite carefully to see what it had found. Some of it was pretty good, some of it seemed made up (so I fixed it). In my AGENTS..md I refer to agents/designs/*.md as a place where it can find relevant information that it should read. I remind myself to ask the agent to keep these up to date with new things it learnt.
• I ask it to make plans and store these in agents/plans/ with a current.md that gives an overview of current and future work. This works semi well, Cursor seems to insist on storing plans somewhere in ~/.cursor/ instead.
• AGENTS.md - I use a variation of https://gist.github.com/betatim/4b205de0b762f8c7865ea2e0ea5c65b4. I recently noticed that for a project the whole section on core principles was missing, but I was sure that it was present (aka I could not really tell the difference in behaviour compared to another project where it was present).
• https://agents.md/ - many examples of AGENTS.md files
• https://www.humanlayer.dev/blog/writing-a-good-claude-md opinions on AGENTS.md files

My take away/thoughts: a fairly simple AGENTS.md seems to be good, it should not contain too much information because that means the fraction of it that is relevant to a task is lower, which "the internet says" reduces the chances of it being followed. Instead it should refer to other documents and state when to read them. While I haven't tried them skills seem to be a good way to help AI users to do the right thing in a repo (eg a "select an issue to work on" skill that encodes the label rules of the repo). There seems to be no need to explain how the scikit-learn build system works, it just works.

What do you think?

cc @AnneBeyer @adrinjalali @ogrisel

Start by reviewing the issue discussion and the referenced AGENTS.md examples, design documents, and plans in agents/designs/ and agents/plans/. The work is not yet defined: it needs an agreed direction for collecting AI-workflow practices and deciding whether they belong in a separate repository or scikit-learn before implementation can be considered done.