
# Goals (Early)

We want to put together a base plan where we decide the order that we are going to build the skills and commands and test them. We're going to build them each individually so that we can put them through the ringer a little bit and then use that testing to improve the project. And then we will move on to the next stage, almost like we're building it in live real time so that we can use it and test it on many projects, creating examples and everything that we can put in our research to better improve the project in the future.

So I would say that the first couple of agents that we're going to need to build are the research agent and the interview agent. The research should be good at doing the web searches and reading of documentation of different types of projects and software that we need to implement into our code. And then the interview agent should be used best interviewing practices for talking to the people who are going to actually use the tool and how they would want it built, what features are most important, what are least important. And it should take you through a live interviewing process where you are asking me the questions and you are basing the next question off of my responses to the original questions.

Once we have those, we can test them out by trying to build the other agents, or a couple of the other agents based off of these two. And then we can iterate and make these better while building out each of the new agents and commands and process and connections and integrations that we need to build as well.

After we have those first two agents built, the first thing we're going to want to do is set up the plane integration so that we can build plans, tickets, and projects all in our project management software so that we can build that integration right from the ground as one of the first things that we do. Make sure that we are also able to make this modular enough that we can use this in linear as well as plane because one is for work and one is for personal projects.

Then I believe the next thing we should build is a performance metrics for the AI agents. This is a subset of the overall performance metrics that we want for any project, but I really need to understand the costs of building in terms of tokens, tasks, actual costs, different models being used, all of that information as early as possible in the building out of this project, so that we can study it for future projects.

Note that I am not married to PIV or SWARM or anything like that. We are building this as a new project with new research. Just giving you all the information that I have currently so that we can make the best kind of decisions that we need to for designing this project. Especially since the clog team agents already came out just now.

One of the first things I think we should do is actually building a design dock or design plan of some sort here. So if we could just walk through that, build it in Mermaid as best we can as a starting place, that'll be the perfect first stage before we move on to building the first couple of agents.

You tell me if you think we should do the interview or the design doc phase first.

Make sure to keep a running log of all the conversations that we have. So even if you're just numbering them in order that we have them as markdown files in a conversation log directory, we need to make sure that we are always doing that before we, or once we exit a conversation.


## Background Information

@initial-build-ticket-idea.md

This is my original build ticket idea. It basically is the inspiration for this whole project. It is not planned out over the course of an hour or two, so it is not to the level of verbosity that we need to get to, but it does show the overarching idea and plan of things that I think we want to build.

@research/
This folder is where all of my previous research for this style of project lives. These are just ideas, feedback, possible things that we can implement. They are not set in stone. They are just building blocks for us to start to build the perfect process.


@research/opus_first_ideas/
This was a dry run of this idea that Opus kind of built out. This is definitely not expansive enough, but it is thoughts in the first directions of what could be built. So we should take a peek at this and maybe use it as possible inspiration.

@research/hooks/
I have previously attempted to build some hooks into our workflow to make sure that we keep everything on track and don't get out of our shoes in terms of any issues either with errors or commit messages or all of those style of things that can really derail a project if you don't keep everything clean. And so we should look at this as inspiration for managing the projects as best we can.

@research/early-research/
This is my original idea research build out all of the above that we should that have led to the building out of this project. It has nothing finalized. It's just reading through ideas of how to build out a system that is all encompassing. It has specific software or folder structure requirements that we might want to consider, feedback loops, all of that. So if you're looking to understand what the inspiration beyond the initial build ticket idea is, this is where you would find that information.


@current_ai/
This is my current claude setup on most of my computers. I would say that It definitely needs adapted to be a better fit for what we're trying to do, but it is a starting place. We do not have to keep any or all of the skills. They're just there as placeholders for something that we might want to model off of or build or improve.

Remember that I want to be provider agnostic, so I want to get away from relying on Claude too heavily. Obviously at the start here we can have as much as we need in there, but the goal is to get completely away from depending on Claude and that we could use any models or providers that pop up in the future that might be better at whatever we happen to be working on.