Suggestion

[jdelon02]

Hello,

Let me preface this by saying I really like what you have created, and I think it is an opportunity to close a big loophole problem I have with the normal copilot/claude instructions that I have been generating for each project I work on. I do want to give some context to my reality, since I suspect that it is very different than many others. I work for an agency that does a lot of different types of development; Drupal, Wordpress, NeonCRM, N8N workflows, Salesforce custom code, and the list goes on. Because of that, it is very difficult for me to define my "default" tech stack in any meaningful way. I do know that I can customize on a per project basis, so that is great.

My first suggestion is to create an ability to have nested "defaults" in the ~/.agent-os folder, so that someone can define different "default" tech stacks depending on what they are building. So, I could have a folder "drupal10", with the corresponding docs within that. Then, I can have another called "Wordpress" etc... with some mechanism (maybe just an interactive question when project is setup with agent-os) that would let me pick the specific "default" I want to use.

My second issue (and this is true when I write instructions.md files so please don't think it is only a problem in agent-os) is that I am essentially recreating documentation that should already exist elsewhere in a different format. For example, the solution approach, the tech spec, the roadmap, etc... all, potentially, exist in the project space in confluence, or google drive, etc... In order to make full use of agent-os, I have to maintain duplicate documentation, while also ensuring that my local project documentation maintains synchronization with the agency documentation that the PMs and others have developed. What would be great would be an ability to reference those files that exist on the cloud by url, and then have the AI fetch them. I don't even know if it is possible, but I thought it would be worth mentioning. Maybe leveraging a .env file for login creds/API keys for whatever sources needed. Originally I had the thought of an OOP approach where a "confluence" class could be a child of a "sources" class and it knows what values to look for in the .env file in order to make the connection, but I don't really think that will work with bash scripts.

I hope you don't take these suggestions in any way as criticism of what you have created. I got super excited at the premise while I watched your video, and am taking it out for a test drive right now, and think it is awesome.

[CasJam]

My first suggestion is to create an ability to have nested "defaults" in the ~/.agent-os folder, so that someone can define different "default" tech stacks depending on what they are building.

I've heard a few people mention this. I too often shift between different stacks for different types of projects. Worth considering! If you or anyone else starts organizing your Agent OS this way, I'd love to hear how it goes.

[aretrace]

Yeah, the support for multiple tech stacks is crucial. Most dev's today are polyglot, a single standards/ does not make a lot of sense.

[deonvdv]

We use Notion and I was able to use Notion'a MCP to pull in documents. We still create local copies/duplicates, but at least the MCP helps. Maybe you can MCP into Confluence? Create a custom claude command to "sync" a cloud PRD.

[jdelon02]

I split the idea up into two pieces. One, extends the agent-os to allow for custom directories to be defined and a couple pages get created in each. (https://github.com/jdelon02/agent-os) Two, a way to setup defaults on a per project basis that references the project type instructions. (https://github.com/jdelon02/projectai)