Building an AI Agent with Subagents and Skills

Every time you ask AI for help, it agrees. Fast, confident, and it never tells you your plan has holes. That's the problem Arete is built to fix.

Jesus built a brainstorm agent on Claude Code skills that guides you through five phases -- Ground, Explore, Decide, Stress, Ship -- before you commit to anything. The output is an architectural decision record and an implementation plan you actually own.

In this episode he demos it live, shows how parallel subagents work without polluting your main context, and answers the honest questions: tokens burned, vendor lock-in, debugging subagents, and whether this works with a team.

Resources:
- Install Arete: https://github.com/jesgarram/arete
- Demo code: https://github.com/datamindedbe/demo-technology-exploration

---

Click here to watch a video of this episode.
Full playlist: https://www.youtube.com/playlist?list=PLJ_da7qdfL80rA7byzC_CmyrfJWjcCTnb

• (00:00) - Intro & meeting Arete
• (01:38) - The 5-step brainstorm workflow
• (04:05) - Meta: This video was made with an AI skill
• (06:02) - The demo: ground, explore, decide, stress, ship
• (14:56) - Example results: ADR and Plan
• (17:23) - Subagents and context engineering
• (21:12) - Demo: the Researcher Agent
• (22:48) - Practical concerns: vendor, files, big projects
• (25:30) - How many tokens does it burn?
• (26:51) - Control, agents vs skills, multi-human
• (29:44) - How to install Arete
• (30:44) - Wrap-up

---

Data & AI: Technology Explorations is a biweekly show from Dataminded. Each episode a Dataminded engineer demos a tool or technique worth knowing about -- working code, honest takes, no hype.

Music by Aleksandr Karabanov from Pixabay

Creators and Guests

Host

Jonny Daenen

Head of Knowledge at Dataminded

Guest

Jesús García Ramírez

Data Engineer at Dataminded

What is Technology Explorations in Data & AI?

Deep dives and practical demos on the technologies shaping modern data and AI development. Join the Dataminded team as we explore, unbox, and critically review the latest tools, from building AI agents and RAG systems to optimizing cloud costs and accelerating data pipelines. We cut through the hype to show you what actually works in real data engineering practice, complete with demo code!

Jonny Daenen (00:00)
The problem with using LLMs or AI for brainstorming is that they jump to solutions, they don't challenge you, they lose structure, and they overwhelm you with text. What if instead of getting instant answers, you can get an AI that guides you through a structured process? In this video, we have a look at one type of agent that uses skills, sub-agents to turn vague ideas into architectural decision records and implementation plans. Let's have a look.

Jonny Daenen (00:33)
everyone. Welcome to Technology Explorations at Dataminded. LLMs are quite good to give long answers, and they're not really good at challenging you during your process.

And my colleague Jesus, who I brought in today, has developed an agent for that Welcome Jesus. you made us a cool demo based on the skills we did last time. can you explain a bit on what you built and why you build it?

Jesus (00:49)
Hello, Jonny

Yes. So I built a plugin called Arete which it's a Greek word that means excellence through effort and not given. And basically it's a brainstorming plugin for agents. And why I build it? Because I've been a heavy user of LLMs in my workflow every day And I realized that LLMs are great at giving you answers, but not at challenging what you are doing.

So I was missing this kind of, you know, like annoying senior engineer challenging your decisions. So I was like, I'm going to build one. And that's what I did. And it's quite easy to do using skills and agents.

Jonny Daenen (01:32)
Okay, and so you have a brainstorm agent. Could you walk us through how you use it maybe at the top level?

Jesus (01:38)
Yes. So there are two things. There is a workflow and there are helping agents. The workflow is quite simple. You start a conversation, you say, okay, I want to brainstorm about this problem. And it's going to guide you through different phases. The first one is ground, you need to make sure that the problem that you're trying to fix exists. What is the pain? What happens if you don't fix it? Explore. So we go into a divergent phase. We are going to not try to go into one focused solution, but

try to explore a few different directions. What is possible? What are different ways of solving the same problem? We do this iteratively until one of these directions seems to be the one that is winning, the one where we want to make the solution. Then we decide, this is a phase where we put every direction into a matrix with pros and cons. And here we're going to be like, OK, this is the decision that I want to make. This is the solution that I want to go for. Once that you have that, then

the more difficult part comes, which is stress. This is the annoying engineer poking holes. What about edge cases, What happens if this? What happened if that? Then you have to give answers to that. Once all of that is done, we go to the final phase where, luckily, we don't have to do anything. just ship. Ship basically is a phase where the agent is going to recapitulate what you've done, the decisions that you've taken, and it's going to write two things, one, an ADR, like a record of

what happened, decisions, the context, the good things and the bad things, and a plan that you can feed it into an agent to implement the features that you want.

Jonny Daenen (03:06)
Okay, cool. So this is basically targeted to getting architectural decision records, ADRs, you want to make decisions that are verifiable and traceable, and you get a plan that you can feed to a human or an AI to implement that decision and the next steps. so is it tied to those kinds of use cases only, the technical use cases?

Jesus (03:24)
No, that's a good question. I am someone that works also creating presentations and having some difficult meetings and these kinds of things. Sometimes I feel like I would benefit if I would have like a structured approach to my brainstorming.

So then there is a conceptual track the agent would see, ⁓ now you're trying to do something conceptually. So it's going to ask you and stretch you about directions that are basically about presentation or the writing. So you are going to get different questions and the output is going to be different. In this case, we're not going to have an ADR on a plan. We're only going to have kind of a record of the decision that you made it.

Jonny Daenen (04:04)
Okay, very nice. I'm looking forward to seeing it in action. Before we do so, I think you made quite a cool showcase video with your video editing skills.

Jesus (04:13)
indeed, I struggled to show the value of this because there's a lot of words, you know, and until you don't use it, you don't see it. So then I was like, can I make a video? But I don't have any video editing skills. However, I found a library called Remotion that you can use to create videos programmatically. And because it's programmatically, you can use LLMs to create them. So was like, okay, I want to use Arete to brainstorm the structure and the skill to use Remotion. And this is what I came up with.

Jonny Daenen (05:29)
Right, very nice. I'm quite impressed with what you were able to showcase here, Jesus. I'm actually looking forward to trying this out myself to make some better videos. But this also shows that skills, because you use a skill for this, are more than just generating documents. It can even help you do amazing things like this, actually. Very cool.

Jesus (05:47)
Indeed, it's

insane to be fair. I mean, of course, this can be improved vastly, but I feel like with my zero knowledge of both Remotion and video editing skills, I spent one hour and I think the result is quite decent.

Jonny Daenen (06:01)
Very nice. Now maybe let's dive into a demo of your plugin.

Jesus (06:05)
Yes, so we are going to use what we discussed in the other session. So we are going to try to improve this explain codes skill. So the idea is that we are going to start with Claude, because I use Claude code. And then it's really simple. We say, arete brainstorm. And we just say the problem that we want to brainstorm about.

I want to improve the explain codes skill that we did before. So I'm going to start the brainstorm. Hey, I want to prove.

So now it's calling the ground. So now it's first, let's look at the problem before exploring the solutions. OK, that's what we said. And it's going to ask you, first it's going to understand the code.

You see now I have the full picture it's reading Okay.

And here you have comments. So it's like, this is what I see. OK, what are the questions? Let's start with the most important question. Who is the audience? Because indeed, it's like, I have an explaining team, but it's different if you're explaining to a senior than to a junior, for example, or to someone that is on boarding. For example, on boarding.

Jonny Daenen (07:11)
yeah, okay.

Jesus (07:21)
OK, goods on board. More questions. What kind of code will this skill typically explain? A function, a module, a full repo. I care mostly about architecture.

For example, so this is C. So then we can fine tune what the explain codes means, These more questions, what diagram format do you want? I like a lot mermaids because LLMs are really good at creating. Before we were using ascii , and I don't think that is good enough. So I would say A.

Last grounding question. What should the output look like when someone invokes a skill? Should the output be response? No, I want a summary. Yeah. Inline and a file.

Jonny Daenen (07:55)
Yeah.

into a file.

Jesus (08:02)
And now it's going to say, OK.

Jonny Daenen (08:02)
And so this was for

the model to understand like what do you actually want to have a better understanding. And now it will actually move forward to I see the explore phase where it goes a bit broader.

Jesus (08:12)
Indeed. So we started with this abstract vague problem. And I was like, okay, I want this skill for onboarding and architecture and mermaid diagrams. And then it asks you, Hey, let's explore. This is a conceptual track.

We are building a teaching tool for needs to care? Is the backend engineer, is the full stack developer, is data engineer? Let's say that it should work for everyone. That's going to also define a bit the solution. do or feel after reading the outputs?

I would say understand the code base.

OK, what is the main thing that they find hard today, for example? And I would say.

I don't know, for example, like scattered docs.

What mermaid diagrams do you want? I want C4, for example, because it's I only care about architecture, even though that's not true. OK, C4. Should the skill always generate all the useful levels or start at one level and then the user has to zoom in?

all

defining.

OK, a different direction now. As I was saying, you don't go tunnel vision into one. You explore a few parts of the solution. How should the skill discover what to explain? That's a good one. Should it point to a directory? Should it point at nothing? No. It should have as inputs a natural language query.

Like I don't, I want that the LLM is the one in control. Okay.

Something like this, that's a good thing. Should the skill also accept no inputs? No. It needs an input. We cannot explore code if we don't say which part of the code. So this is, it keeps going. Another direction. Where should the generated Markdown be saved? Docs, architecture. So these are a lot of small details that we didn't think about in the beginning.

Jonny Daenen (10:12)
Yeah, all of the decisions that you actually need to make that will be good in ADR and for a plan to be executed.

Jesus (10:18)
Yeah.

This is also a dummy example to be fair because yeah, we are writing a skill, here's another direction. What tone should you use these are good direction. Should it be more textbooks? Should it be conversational? want conversational. are, that's what I want. Okay.

we are finding the moment where we should start deciding. This is summary, again, of the decisions that we've taken. I say, OK, let's decide. And now it's going to give me, again, a summary of the decisions and the one that I want to go forward with. If there are points that are not

Jonny Daenen (10:50)
Yeah, so each time

in each step it will actually call your specific skill that you made for every block of this process, right?

Jesus (10:57)
Indeed, OK, so there are three open options to work from the Explorer.

One thing that I like a lot is that it gives you the table and you can read like, are the good things? What are the bad things? But also it says, let's run what matters the most for you. So then you order in priority. Is it completely simplicity or discoverability? And I would say completeness, then discoverability, and then simplicity, And then based on that is going to fine tune those decisions that were not super clear

Okay. So this is the recommendation. Good. And now it's going to challenge. see, referencing and accessing docs means the skill needs to search for README ADRs. That's a lot of context. you willing to accept a slower? Yes. For me, I'm okay. I don't care about being fast. I care about being complete.

One thing that I like is that it tells you, are there other things that we have not touched that you would like to touch? Like, ⁓ the generated file could get long. No, I want to go and stress test it for the sake of the video. Because now,

Jonny Daenen (11:54)
So here you will

be challenged by an expert on your solution.

Jesus (11:58)
Yes. So now it's like you've decided on this, blah, blah. Fine. The skill does a lot. C4, container, components, reading. And then it's like, is it something that you could remove? Let's remove something, related file section. It's true. I'm over-engineering the solution for now. Should we cut it entirely from the design or keep it optional? No. Cut it entirely. We don't want that.

maybe for the future. And this is also something that is going to be reflected in the ADR. Like this was considered, but it's not used. Data flow. The skill takes natural language. What happens when the question is too vague? Claude is quite smart, so he should be able to find it. If not, ask back.

Okay. Fair. Good. Where does truth live? The skill generates a file. You know, if the code base gets stale, what happens? What happens about that document? We need updates and a disclaimer.

Because this is truth today, but maybe in a week that's not so.

Jonny Daenen (12:57)
Indeed.

It might not be relevant anymore indeed over time.

Jesus (13:00)
Yeah.

So it's more for onboarding. Okay. The grinds. Should the skill use native mermaids use standard mermaid. think standard mermaids renders everywhere. So it's, it's quite successful. We don't need to use this fancy C4 syntax. Let's go.

And this is kind of an edge case that if I would not have thought about this, I would have used the C4. Then see that in GitHub it doesn't look good, and then go back Next challenge, scope control. Will you have a large monorepo? This can be huge. Should the skill limit components? Well, yes, of course. It should only limit things to what is relevant to the question. OK.

Jonny Daenen (13:23)
And then

Jesus (13:36)
Good constraint. it's not a real senior engineer because it's always like I'm making good decisions. a tiny repo scenario. Someone uses a skill on a three-file hobby project.

Jonny Daenen (13:37)
Feedback, yeah.

Jesus (13:48)
Should the skill add up the number of? No. It's OK. If I'm working on a hobby project and I have made three files, I don't need a skill to explain my own code. So it's not a case that we are going to find in reality, let's say. The skill itself, OK.

I'd say that it's a personal skill. I want it to work in every repo. this is a summary. now finally.

This is the moment that I always liked because like, we have the decisions. It's gonna call the ship.

Jonny Daenen (14:14)
The ship

skill, yeah.

So this should result in an ADR and a plan, right?

Jesus (14:18)
Yes.

So now it's reading the file.

So here we have the outputs that I can quickly show you. let's go to the output first. So here we have this new folder called context that has some structure that is based on the Arete plugin.

We have the exports, and here we have the outline. So if we read preview, it's like, this is the problem. These are the decisions made. And why we made the decisions, you see here. And what was cut altogether. Like, these are things that are cut because we decided that these are not important. When you do something that is more complicated, you get a better

ADR, say, for example, I want to show. Yeah. Even like diagrams it's a bit meta, but I created an agent for arete teach agent because at some point I realized that, Hey, there are concepts that sometimes appear that I'm unfamiliar with. I don't want to derail the brainstorm, but I want to actually get an explanation for them. like, can I add.

Jonny Daenen (15:02)
with different options or so.

As during your brainstorm, you mean.

Jesus (15:23)
here you see a good ADR, like the context, the decision you see, like these drawings. And this is something that Arete creates for you. there is a architect agent, subagent, that is going to make these nice mermaid diagrams. So this is a flow between you are the user, you run the teach, and then what happens? The main agent calls the teach agent.

The teach agent then is going to make drawings, then is going to call the architect subagent, and then is going to store the teachings in this folder. So it's like all of this has been decided in the ADR. Here you see key decisions, the structure. then something I really like is these like positive consequences, negative consequences, and mitigations. is no decision that is perfect.

Jonny Daenen (16:05)
And so in this case, you help structure your thoughts, you get challenged outcomes in ADR and a plan. Could you show such a plan maybe?

Jesus (16:13)
so it's like, okay, these are the steps. First, create the agent definition, create a template for the teaching, modify the brainstorm because it needs to know that there is a new agent, create the context teaching for outputs and update the readme document. And then here you have the of how to...

To be fair, this is quite small because It's not really like, you are creating a new networking setup and you need to do this and that. And then you have these huge plans with a lot of phase, a lot of verification, a lot of steps.

Jonny Daenen (16:39)
Indeed.

but you also use it for that, right?

Jesus (16:47)
Yeah, of course, of course. That's where it shines for me.

I feel like it took me three times less than what I would have taken in the beginning without this.

Jonny Daenen (16:56)
this has become

your mentor essentially to navigate your daily workflow.

Jesus (17:01)
Indeed. Of course it doesn't, replace, you know, a super good senior, let's say I've had a brainstorm sessions with actual colleagues at Dataminded that are way more senior than me. there is still a gap, but when you don't have that for the day to day for me, it's accelerated in me a lot.

Jonny Daenen (17:17)
I have a few questions still on the setup Jesus, so unless there's more things you'd like to show.

Jesus (17:21)
No, of course not. Shoot.

Jonny - Take 1 (17:23)
so depending on how you interact with your agent, it will spin up a new one that will actually do a specific task.

Jesus - Take 1 (17:29)
⁓ Yes, there are three ⁓ agents that can appear depending on how you are working with the brainstorm. So one is this teaching agent that you trigger when you ask, teach me about a concept.

You don't need to even call it. It's just say, teach me about a concept and it's going to be triggered. You have the research agent, which is super important. sometimes LLM, they struggle with context. They don't know everything that you know. But that's why you can trigger a research agent either to research part of your code base or research online.

Look for it and then put it back. Don't derail the brainstorm.

Jonny - Take 1 (18:05)
And so these

agents are triggered in your main conversation whenever you do something and you have some technical machinery to do that, I guess, some hooks or whatever, to actually spawn these sub-agents.

Jesus - Take 1 (18:16)
Yes, exactly.

here you have the definition of your agent. But one thing that is super important is these three lines. So this is the metadata. Your agent is going to have this information. It's going to know, ⁓ there is a researcher agent that I can trigger if I need to. Why and when, that is informed by the description. So it knows that if you ask about research, it's going to trigger the research agent. And then to enforce it even more,

Once you start in the brainstorm, which starts with the brainstorm, of course, then here you talk to the agent about the subagents. So here, for example, it says, spawn the researcher subagent when the user says this. So you even enforce it even more, that if the user asks, how do others do this, it's going to automatically spawn this subagent.

Jonny - Take 1 (19:04)
And so that is the description in your main agent that you put there. Like if the user asks something like this, you spawn a sub agent. And spawning a sub agent, is that a technical thing or does it run separately or is it just like adding things to your context?

Jesus - Take 1 (19:19)
It is a technical thing, but we are really lucky with Claude Code because they handle this for you in the background. So basically what happens is that it's going to open a new agent with fresh context window. And it's going to also decide which model to use. So you can say, because I don't want to burn my tokens. For this research agent, it's going to be a smaller model. And also I'm going to use.

particular set of context, not the whole conversation of the brainstorm, but only the topic to research. The research agent is going to do something alone, in parallel, and then once it finishes, it's going to feed back the information, the output of the research to the main agent.

Jonny - Take 1 (19:48)
Yeah.

Yeah, I see. And so then you don't pollute the context of the main agent. So it keeps smaller than when you would have done everything in that context. And then you also wouldn't lose track of your history.

Jesus - Take 1 (20:08)
Yeah, think that's the beauty of it. LMs are super powerful. However, yeah, they get lost when you bombard them with context. So before, a couple of years ago, people talk about prompt engineering, like how do you craft the instructions? But nowadays we have more. We have tools, MCPs, skills. So it's more about context engineering, they call it. Like, what do you put in the context at every particular step so the agent has the correct tools?

Jonny - Take 1 (20:18)
Yep.

Exactly, you cannot put your whole database in that context window. You have to be mindful of how to fill that up. Context windows are big, as I recall, but they're not as big to put everything you want in there.

Jesus - Take 1 (20:46)
No, and even they are quite big. You can fit books there. However, there are a lot of studies that say they are like humans. You know, we have limited memory. If I asked you to store 20 numbers in your mind, probably you're only going to be able to recall five or six. So the same is with LLM. If you ask them to, even if you fit everything in the context window, the more information, the more hallucinations and removal of information that is going to happen.

Jonny - Take 1 (21:02)
Yep.

Okay. And so you decided to split the responsibilities into multiple sub-agents to architect your agent. And then there is one main agent that you then call and interact with continuously. Is that something you could demo on a specific case? Unless you want to dive a

Jesus - Take 1 (21:23)
Yes.

I could.

for example, if I say, Hey, I want to research online how people implement these kinds of skills.

Jonny - Take 1 (21:37)
And that will kick off another specialized agent,

Jesus - Take 1 (21:39)
the researcher

now it says I'll expand the researcher to find real world examples and best practices. And then the good thing is like all this research is not going to pollute your context. It's only the output of your research. So here you see that it does a lot of web search. And it's going to read a lot of tokens, but this is not going to be in your context window. It's only the outputs of it.

Jonny - Take 1 (21:42)
⁓ yeah.

How do you know? Because you cannot debug this, I Or can you follow up what the subagent is doing?

Jesus - Take 1 (22:07)
in Claude, in particular, if you run control-O, you can see what's going on. So here is the prompt that the researcher is getting. You see? So this is written by the main agent. questions are an important context from our brainstorm, which is really nice because it's going to guide the research better.

Jonny - Take 1 (22:15)
Yeah.

Jesus - Take 1 (22:25)
This is also important. Use web search, because I said to research online and not in the code. Query to try output format. So this is really good. This is described in the sub-agent. And now you see what it's doing. So now it's doing this web search, which you can see. But apart from that, you cannot see much more, because Claude doesn't give you the output of it, because it would pollute a lot.

Jonny - Take 1 (22:29)
yes, indeed.

what I hear now is that these are quite some technical concepts that you should master to architect your agent. That's essentially what you're doing. And it feels to me, they're very specifically related to the vendor. Like in this case, you're using cloud code. Is that also the reason you're using Claude code? Because Anthropic has quite a few of these advanced concepts implemented.

Jesus - Take 1 (23:06)
Yes and no. think Anthropic is leading the way to be fair in this kind of integrations. However, everyone is catching up. For example, we use GitHub Copilot also in Dataminded and they are also quite advanced. They have like 80 % of the features that you have in cloud codes. You also have OpenCode, which is an open version of

this kind of, they call it the agentic harness. And for example, then they implement all of these patterns like hooks and skills and subagents. And so you can find your way, but indeed, Claude code. would say right now is the most advanced.

Jonny - Take 1 (23:41)
Yeah.

And then the second question I had was how do you keep this organized? I was trying myself to do a few things I quickly fell into the trap of having a bunch of folders and markdown files that are difficult to keep organized.

Jesus - Take 1 (23:42)
Yeah.

Yeah, so that's something that is enforced that there is going to be a context folder All of the plans go there. I know that this is disposable. I implement the plan and I remove the plan. That's like ephemeral. Then I have the...

Jonny - Take 1 (24:06)
Yeah.

Jesus - Take 1 (24:08)
exports that is going to be the ADRs. This is the one that is important to keep track and I put it in GitHub. And then the teachings is a bit the same. It's something that it's nice to have, but it's not something to keep a lot of track of I have it privately. but I don't keep it for long because it's not that important. What is important is

The decision is taken.

Jonny - Take 1 (24:28)
Exactly. So basically the information you're storing, it's not like a real database. It's metadata, it's architectural decisions. So these you do keep, but you're not managing your repository with all kinds of different information in Markdown. What I tried to do, for example, was have some context on the project and also have that context in the repository, but that quickly becomes very convoluted to manage, I find.

Jesus - Take 1 (24:52)
Actually, we do that also in this big project there are a few guidelines. So first of all, if you use Claude, or even actually if you use another kind of provider, they all have this pattern of markdown files that are specially treated. For example, in Claude, you have the Claude.md, which is going to give

kind of a scaffold of how your project works. one thing that I discovered recently is that You can have this Claude.md, not only in the root, but also in subfolders. So for example, imagine that I have a folder for infra, I have a folder for logic of my code, I have a folder for drawings, for example. You can put a small Claude.md there, and then you get pointers.

Jonny Daenen (25:30)
What I was wondering, how many tokens do you burn a month giving all this setup?

Jesus (25:35)
That's a good question.

I use a lot, but not as many as you think. Why? Because for the brainstorm itself, you use a big model, the smartest that you can. use Opus 4.6. However, for these subagents, you use token efficient models. So this, if you go and dig in the repo, you say architects. Here you see the definition of the agent, whatever, but you see model. I'm not using Opus for this. I'm using Sonnet.

For the researcher, because it's going to even read a lot more, I use Haiku that is five times cheaper than Opus. For the teacher, because it's also more important, use Sonnet. If you have a good plan, you can use cheaper models to implement the plan. But the plan needs to be really good. So I don't use Opus for implementation. If I would do that.

Jonny Daenen (26:04)
Yeah.

Jesus (26:24)
my cost would be three times more expensive. I've seen now workflows where people, yeah, set up agents that are talking to agents on multiple Claude code sessions and what not.

those kinds of setups are more for people that really don't look at the code But for me it's like, no, no, I want to be in control of my decisions. I want to own the ADR. I own the plan. And then I am technical so I can make adjustments to the outputs. I don't need 50 sub agents. And I also want to understand what I'm doing.

Jonny Daenen (26:43)
Yeah.

and so you use it basically really as a mentor or as a peer to reflect with, but you are still in control of every step and every decision.

Jesus (27:00)
Indeed,

I am the one that says, let's go here, let's go there. But yeah, so for me, it's different than that vibe code. It's like, I would say a structured way of doing spec-driven development,

Jonny Daenen (27:11)
I see you have your agents, which are the architect, researcher and teacher. And then you use skills for the five steps of your overall agent. How did you choose what to use an agent or a skill and how does that differ?

Jesus (27:22)
That's a good question. So in this case, I use skills for the fases because I want that they all go in the same brainstorm, in the same context session. Let's say I don't want to start a new conversation every time that I go to a new face, at least not me. So that's why they are skills because skills, are black in the current conversation by default, except for the sheep skill where what I do is I trigger agents in parallel.

So it's a skill that is going to trigger other agents. Why do I use super agents for teacher research and architect? Because these are all things that are important, but they need to go outside. They don't need to pollute the context. They don't need to derail the conversation. Like, ⁓ go and look for something in the internet, but don't do it in the same conversation. Do it in parallel. And once I do it, don't give me a summary. Don't give me the whole.

Jonny Daenen (28:05)
Yeah.

Jesus (28:11)
you know, like 50 pages that you have read the same for a drawing. Like the architect is like, I don't need the drawings to be made in the same brainstorm. need them to be in parallel and I didn't need them to be written in a, document.

Jonny Daenen (28:24)
But for the skills you also fork so that is also happening in parallel, right?

Jesus (28:28)
only the final ship, which is I am not doing the brainstorm. It's just like the ship is a skill, is a phase that is just output. I am not part of the brainstorm anymore, let's say. That's why it's okay that it's figured outside. ⁓

Jonny Daenen (28:39)
Okay.

And so the other skills

are not forked and they're still in the main context that they remain.

Jesus (28:45)
Indeed. Yeah,

because I need to give outputs. So that's why they are in the main context.

Jonny - Take 1 (28:50)
How would you see this working with multiple people?

because we do that as well as organizations right we are a group of people a few maybe it's five people you need to refine or decide whatever you will implement currently when not using agents we do that in group how do these two things mix together

Jesus - Take 1 (29:07)
For me, I actually do it in my work. I work really closely with a colleague together in an important project, and we use it as a third colleague in our brainstorm or a way of structuring our brainstorm. We are sitting down in the same room and we discuss the problem. Then we kick up this, and then we both discuss, read the outputs, discuss our answers together, and then we...

Jonny - Take 1 (29:24)
Yeah.

Jesus - Take 1 (29:33)
How this would scale up to five people in the room? That is a different question, I would say.

Jonny - Take 1 (29:39)
Yeah, I see. So you actually treat it as a third colleague and you look at it together, huh? That's interesting.

you actually open sourced this plugin that you showed us and this is installable in Claude code. And there's a quick way to do it. saw, right. It's in the read me.

Jesus - Take 1 (29:50)
Yes.

So because the skills spec now is open source, it's not only for Anthropic. You can actually install it quite easily, not only in Claude Code, but also in Open Code or in GitHub or even in Codex. So if you want it Claude Code, it's straightforward. You just add it to your marketplace and then you install the plugin. This is also going to keep track of the versions. So if I update the version of the plugin,

Jonny - Take 1 (30:07)
Okay.

Jesus - Take 1 (30:18)
It's going to automatically be installed in your Claude Code. You don't have to worry about anything. However, indeed, if you want to install it, for example, in GitHub, then I provide a markdown file that you can use to install it. But then you have to, indeed, manually manage the versions, for example, yourself.

Jonny - Take 1 (30:22)
Okay, cool.

Yeah, I see. They don't have this marketplace in place yet that does the versioning and does the distribution in the same way as Anthropic does. Okay.

Jesus - Take 1 (30:43)
Yeah, and it's,

Jonny - Take 1 (30:44)
Okay, very nice Jesus.

Any concluding remarks from your side

Jesus - Take 1 (30:49)
one thing that I really like is that because you have basically markdowns is that it's really easy to start. I open source these, which is nice because I like to share what I do. However, every, every person programs differently. Every person has a different workflow. So the idea is that make the workflow yours.

You can change the skills, you know, can add more context, can add better questions. You can add a difference subagent and like make it yours. Like we are now in a moment where it's quite easy to do this. that's what I would say.

Jonny - Take 1 (31:20)
Yeah, so you

can start really simple. So I recommend everybody to check out the other video on how to get started with the skills because this is already quite an evolved agent, let's say

Jonny Daenen (31:31)
Thanks a lot for this demo. think it's really cool. I actually tried one of the previous versions, so I will need to upgrade using the marketplace of Claude Code. So thanks a lot for showing us this demo. To all the viewers, please check out Jesus's repository and his installation script in the readme. If you have any questions, drop them in the comments.

thanks a lot everybody for watching and we'll see you next time. Bye bye!

Jesus (31:52)
Bye.