Hi,

I just created my account so I could post some modest feedback. I have my own custom LLM agent, built with Pydantic, but it could be any agent.

I have now spent about three hours trying to understand the OneDev integration. Here is a summary of the issues I ran into.

1. At first, I thought there was an MCP integration, until I learned that it had been removed.

2. I was then instructed to install tod and the companion skills.

My first reaction: this feels like the wrong approach to me. I do not want my agent to access shell commands, and I do not really understand this current trend of going full CLI when REST APIs are available almost everywhere.

3. Still, I hesitated and decided to have a look at the companion skills.

4. The main skill presents itself as an umbrella skill and immediately refers to several “sub-skills”. So, to interact with OneDev, I apparently need nine skills.

My feedback: this means I now need to edit the skill to remove what I do not need. Not ideal.

5. At that stage, I thought: my agent needs to know the list of my projects.

My feedback: apparently, this cannot be done with tod. That was a no-go for me, so I immediately gave up on using tod.

6. I then looked at the OneDev REST API.

My feedback: it seems excellent. This is the right direction. At least I can list my projects.

7. I wanted to copy and paste the Swagger/OpenAPI specification into Cursor so it could implement a Pydantic toolset.

But after looking everywhere, I could not find any specification. I asked ChatGPT. No success either. No machine-readable API spec. That was very frustrating.

8. Eventually, my LLM had to read the source code to understand the API.

It seems to work now, although I am not fully sure yet.

9. My LLM also told me that there is no endpoint to retrieve the possible status transitions for an issue. So, apparently, we need to retrieve the project settings to get the issue statuses. But those can be null if there are no custom statuses, so we then need to retrieve the global settings.

My feedback: that is a lot of requests just to manage issue statuses.

10. A request to ~/api/settings/issue showed something that I found really surprising:

{
  "name": "In Progress",
  "description": "The AI assistant should switch the working directory to the branch corresponding to the issue by running below command:\n\ngit fetch <onedev remote> main && git checkout -b <branch-name> <onedev remote>/main && git push -u <onedev remote> <branch-name>\n\nHere <branch name> should be derived from user instruction or issue title, and <onedev remote> should be retrieved by calling tool getCurrentRemote",
  "color": "#FFA700"
}

Am I misunderstanding something, or does the status description contain agent instructions exposed through the API? I do not understand this design choice.

I like OneDev. It has a unique value proposition. But the current AI-oriented integration feels messy to me.

What I would suggest, in the spirit of KISS:

• Integrate an MCP server directly into OneDev, with selectable tools. That would be much simpler. I do not understand the CLI-first trend when everything could be done through a cleaner decentralized architecture.
• Provide a one-click copy/paste or download option for the API specification.
• Include possible issue statuses or transitions directly in either: the issue endpoint and the project endpoint
• Avoid exposing AI-specific instructions through the regular API data model.

Obviously, I assume there may be good reasons for the current design that I do not understand, so please take this feedback with a grain of salt. I took the time to write it because I like the product and wanted to contribute a user perspective.

This is external feedback from a consumer, not expert advice.

Disclaimer: this post has been reviewed by AI, mainly for french to english translation