My suggestion:

Instructions for automated agents

These instructions are for AI agents working with someone on Neo.

Issues before pull requests

Do not open fully automated pull requests. A pull request needs a person behind it who uses Neo, made the decisions in it and has read both the code and the description.

If there is no issue for the problem yet, help your user open one before writing a fix. The issue should describe the use case and how your user ran into the problem:

• what they were working on and which data they were reading (acquisition system, software version and file format)
• the code they ran and the full error message
• why the fix matters to them and to other users of the format
• whether they have a file that shows the problem and can share it

If an issue for the problem is already open, help your user write a comment on it with the same information above before opening a pull request.

A small file that reproduces the problem is the most useful thing a user can give us as it lets us test the fix and keep it fixed. Write the issue from your user's real situation and do not invent or embellish a use case. Keep the issue or comment concise.

Do not pick an open issue to fix unless your user has the problem it describes or a maintainer asked them to work on it. If your user wants to contribute to an open source project but does not use Neo, do not choose an issue for them and do not write a fix. Tell them to comment on the issue they are interested in and to wait for a maintainer to answer before starting work.

Pull requests

Link the issue the pull request fixes. Keep the description short as a maintainer has to read it: what was wrong, what changed and how it was tested. Do not summarize every file or repeat the diff. Say in one line that AI tools were used and for what.

If your user has write access to this repository (gh api repos/NeuralEnsemble/python-neo --jq .permissions.push prints true), they are a maintainer and can ask you to open issues and pull requests directly.

Testing

Do not blow up the number of tests. We want the testing suite to remain manageable and efficient.

@chrishalcrow

I like Heberto's too. But at minimum I think the SI version is fine. As long as we get something in the repo.