Development in this space never truly

stops. Every month we get new models and

with Anthropic, every new model released

brings new qualities and new features

that make us think of AI coding in a

completely new way. Today we'll be

looking at a new agentic framework for

AI coding that actually takes advantage

of a new feature that Claude Code just

released. This framework relies heavily

on a sub aent structure with agents from

Claude Code, knowledge persistence to

actually record learnings for next time

and many other things. Many people in

the AI labs Discord community DM'd me

about this new framework and I just had

to test it out. So, let's get into the

video and find out if it's truly worth

it. At its core, this framework follows

a simple philosophy. Each unit of

engineering work should make the next

unit much easier. The workflow consists

of multiple steps and several tools you

can use to apply this framework. There

are distinct stages. First, there's the

plan stage where you provide your PRD

and details about what you want to

build. For example, in my case, I told

it I wanted to make a GitHub repo

research manager and gave it a PRD

outlining the basic features I wanted. I

also listed the tech stack. This

framework works through custom/comands.

You can see that we have the plan

command from compound engineering. At

this stage, you give it everything about

what you want to build. It then plans it

out and launches several agents. For

instance, there's a research agent, a

best practices agent, and a framework

agent as well. What I really like about

this is that it uses everything from sub

agents to slash commands and integrates

it all seamlessly. The framework

researcher which researched the

frameworks we were using such as Nex.js

and fast API for the back end ran for 6

minutes and used around 50k tokens while

conducting its research. What it does

next is create a new work tree. Inside

that it creates a new GitHub issue in

AMD file. It compiles all the research

there detailing which files need to be

created. Essentially, it pre-engineers

the context. Based on this documentation

and the outlined features, it creates

phases for us. Each phase contains

everything that needs to be set up for

both the backend and front end. Right

now, it has created a total of six

phases, each with all the necessary

components for execution. This completes

the plan part of the workflow. Before

continuing further, let me explain how

to install it. This involves just two

steps. You need to run Claude and add

this marketplace plugin. For those

wondering what this plugin is, it's

actually the new feature recently

released by Claude Code. You can now

customize Claude code with different

plugins. Plugins essentially serve as

collections of /comands, sub aents, MCP

servers, and hooks. You can create a

plug-in and share it with your team or

anyone else. This is really useful

because it provides a standardized way

of sharing configurations. First, run

this command to add the marketplace.

Then, to install the actual plug-in, run

this command. As you can see, I already

have it installed. The next phase in

this workflow is using delegate.

Delegate takes the tasks that have been

created and executes them one by one

using the work command. When I ran the

work command, it first created a

separate git work tree for the repo

manager and then started working within

that. When you first run the plan

command, a detailed GitHub issue is

generated. It breaks everything down and

makes all the architecture decisions.

Right after running the plan command, it

doesn't actually write the details into

markdown files. Instead, it writes them

inside the agents to-do tool and sets

them up. There you can see everything

has been planned. Phase 1, phase 2, all

the way up to phase 6. Each one is

written as a task inside the to-do list.

To show you all this, I had to exit and

then resume my session so that the

compactation feature wouldn't erase the

data. This allowed me to actually show

what it had done. It went ahead and

executed all the phases one by one,

setting up the database, backend, and

front end within these tasks. Once a

phase was completed, it paused and

displayed what it had achieved for that

phase. This allowed me to review each

phase before moving forward. An

interesting thing I noticed is that even

after compacting, the to-dos persisted

across sessions. For instance, in the

snippet I showed earlier, phase one was

only half completed before I ended the

session. The rest was completed

afterward. This persistence happens

because the to-do items remain stored

even when the session is compacted. In a

way, this approach makes sense. Instead

of keeping everything in separate

markdown files, it lists them directly

in the to-do tool. While the GitHub

issue file serves as the context base,

it also continues editing that issue as

each phase completes. What I usually do

before implementing a new phase is run

the context command from claude code.

This helps me visualize how much context

remains before reaching the buffer

limit, ensuring I don't need to compact

midworkflow. Running one phase across

two separate compacted sessions isn't

ideal for implementation. So this check

helps maintain continuity. This is what

it actually came up with. If I go in,

you can see that our repositories have

been added. There are still some errors

in here and the framework handles that

as well. I did realize one thing.

Because of the lack of proper

requirements, some features weren't

implemented correctly. For example, this

export button exports all the repos

combined into one MD file. What I

actually wanted was for it to extract

data from each repository individually.

That was a requirements mistake on my

part. I was also thinking of adding the

git ingest library here directly since

it's an open-source tool that can be

added anywhere. It converts a git

repository into an LLM readable format,

which is how I actually dove deeper into

this project. I converted the compound

engineering repo into an LLM readable

format and gave it to Claude so I could

ask detailed questions about how

everything worked and demonstrated it

properly. It's a really neat approach.

The next step is the assess phase which

is basically about reviewing whether the

code written is correct or not. When you

run the review, it triggers another

custom command with custom context. As

it runs, it verifies everything that was

created and then fires up multiple sub

aents. Kieran, the author of this repo,

has created several of his own custom

agents for this process. He has

implemented agents for Python,

TypeScript, and even Rails. These agents

run in parallel, each reviewing specific

aspects such as language specific

correctness security performance

architecture, and data integrity. Once

the review is complete, the agents list

all the critical issues they find

organized by priority. After this, you

run the triage command, which takes all

the identified issues and asks whether

you want to implement them or not. If

you choose to fix them, it adds them to

a to-dos folder, and each issue is

listed individually inside markdown

files. This part really surprised me.

The issues themselves are properly

documented in MD files, but the

implementation tasks are not. Each issue

file contains a detailed breakdown of

what was wrong and how to fix it. This

is where the framework comes full

circle. After you're done with the

review, it moves into the codify step,

recording all the learnings inside those

issue files. Then it loops back to plan

and delegate, allowing you to iterate

continuously. If you want to add new

features, you can do that, too. And the

cycle starts all over again. After

review, there's a resolve command which

enables parallel execution. When you run

it, it helps resolve the to-dos

simultaneously to save time. It analyzes

all the to-dos and automatically builds

a dependency graph to determine what can

be done in parallel and what can't. One

thing I really like about this is that

all the work happens inside work trees,

meaning everything runs in isolated

environments. Each new feature you add

creates a new work tree, and every

feature also raises a new GitHub issue.

This makes it especially useful for

adding new features to existing code

bases, provided you have a

well-consolidated context of the

codebase. Another thing I discovered

while working with this framework is

that naming conventions are extremely

important when you're dealing with

multiple components and pages. Clear and

consistent naming really makes a

difference. We'll be dropping another

video soon on best context engineering

conventions with cloud code, so stay

tuned for that. Once everything's done,

it commits your changes to the GitHub

repo online, and that's how your project

gets built. If you're wondering how this

differs from the BMAD method, the

difference lies mainly in approach. The

BMAD method is much more thorough and

heavily focused on planning. For

example, the export command error I

mentioned earlier wouldn't have happened

if I had followed BMAD. However, BMAD

can feel too detailed and time-conuming

for smaller projects. While this

approach is far more efficient, partly

because of the built-in to-do system

inside Claude Code. Other than that, I

don't think it offers anything

drastically new or groundbreaking. Its

biggest strength is that it's a plug-in,

easy to set up, and convenient to use.

That brings us to the end of this video.

If you'd like to support the channel and

help us keep making videos like this,

you can do so by using the super thanks

button below. As always, thank you for

watching and I'll see you in the next