(upbeat music) I created a PRD skill that instructs the model on how I like to format my Agent Ready PRDs. And in our example project, let's go ahead and ask it to help us create one. (upbeat music) All right, I have cloud open here and I prepared a prompt. So let's say I need a PRD, clean up the view project and create a small web shop for a snack bar.

So let's say I need a PRD, clean up the view project and create a small web shop for a snack bar. Allow me to add a few items to the cart, for example, burgers, fries, pizza, et cetera. And no need to focus on the checkout flow. Only the homepage and cart functionality is fine. If we execute this prompt, cloud is gonna plan this feature for us and make them back with questions and decisions we have to make.

and make them back with questions and decisions we have to make. This is essentially plan mode, but a bit more structured. If you take a look at the output here, we'll see our PRD skill is loaded and cloud knows to use this skill because we prompted it by saying I need a PRD. While it's running, let me show you the actual skill. (upbeat music) So we can go in cloud skills prd skill dot MD.

(upbeat music) So we can go in cloud skills prd skill dot MD. We have some front matter here. We call the skill PRD, we have a description where we say create a product requirement document for handoff to an AI agent. We can talk a bit about the usage. If no description is provided, cloud will have to ask for clarifying questions to understand the feature.

cloud will have to ask for clarifying questions to understand the feature. In here, we define the behavior. For example, it has to gather requirements, ask for clarifying questions. Now, the fact that we say ask clarifying questions will make it basically behave like plan mode. We say ask for clarifying questions to fully understand. The features scope, research, the code base, explore relevant parts, et cetera,

The features scope, research, the code base, explore relevant parts, et cetera, create the PRD directory, create a new folder in PRD to refine. And this is a pattern I really like to use. So I'll have the model output, it's PRD in this directory. And after I reviewed the PRD, I may drag it in a backlog directory. So our Ralph loop can pick it up. So in here, we talk about the PRD directory structure. So PRD to refine.

So in here, we talk about the PRD directory structure. So PRD to refine. As I said before, this is where the model will output its product requirement documents. After we refine it as a human, I will drag it to the backlog. And I actually modified the Ralph.js script behind the scenes with a small interactive picker. So it will list everything in the PRD slash backlog directory and we can pick the PRD we want to execute.

So it will list everything in the PRD slash backlog directory and we can pick the PRD we want to execute. Finally, when it's complete for reference, we can keep the PRDs in a complete directory. Then we will talk about the project.md template. So our actual PRD, we will talk about the features, overviews, goals, user stories, requirements, et cetera, et cetera. We may talk about database changes, API endpoints, testing strategies. And finally, at the bottom, we have our implementation tasks

API endpoints, testing strategies. And finally, at the bottom, we have our implementation tasks that are prioritized. We have high, medium, and low priority. And finally, we have some guidelines. Like we specific fake requirements lead to misaligned implementations. That's not something we want. Include context, explain why, not just what reference existing codes,

Include context, explain why, not just what reference existing codes, consider edge cases, define success criteria, keep the scope bounded. So it's not gonna go spiral off and create some random things the scope has to be bounded and use project conventions. And then we define some examples. And Cloud is able to interpret this skill and create a PRD for us in the format we asked it to.

And Cloud is able to interpret this skill and create a PRD for us in the format we asked it to. And if you take a look at our terminal, we'll see that the PRD has been created. Let's quickly read through this. We'll have a homepage menu that looks good. We have a card page. All right, we have a shared card, logic use card composable. I mean, that's interesting.

logic use card composable. I mean, that's interesting. I would have probably said to use Pina, but a use card composable is fine as well. And a persistent header, that looks good. Let's open up the PRD and let's briefly skim through it. Our functional requirements look good. Responsive, clean, that's good, smooth, lightweight. Obviously, I may want it to be accessible. That's great.

Obviously, I may want it to be accessible. That's great. Let's clean up our old codes. That's fine. State management, like I said before, I would have assumed it was gonna be using Pina, but I think like the built-in reactivity system is fine for now. And it also, it even said like Pina or Vuex is too complex for this scope. So I mean, that kind of makes sense.

is too complex for this scope. So I mean, that kind of makes sense. So I'll leave it for now. Then our affected areas, they seem fine. We will not need any database changes. That's fine. API endpoints, nope. Moving on to the front-end components, we'll see we'll have a menu.js with ID name emoji description and price.

we'll see we'll have a menu.js with ID name emoji description and price. What's with emoji? Like every time. I think it's really interesting that AI is so biased to use emoji. For now, I will leave it, but you may wanna go in and update this to be an image instead of an emoji, because the biggest giveaway that something is AI

to be an image instead of an emoji, because the biggest giveaway that something is AI is if it's riddled with emoji. But as I said, for this exercise, it's gonna be fine. Minimum items, that's fine. We'll have our card composable, looks good. And by the way, if you wanna learn more about Vue, state management, I have an entire course here on LaraCasts where we do a deep dive on Vue state management. So you can look for that if you're interested.

where we do a deep dive on Vue state management. So you can look for that if you're interested. The header looks fine. The menu page card item and card page look fine. We'll make a separate right for the card. That all looks good. So let's move to the to-dos. And let's take a look here, clean up the boilerplate. That's fine. We write a style CSS with clean-based styles

That's fine. We write a style CSS with clean-based styles and custom CSS properties for the Snackbar team. That's fine. Update the title is fine. Create the files that looks good. And then the card item component to quantity controls. I mean, I think that's pretty high priority. The card page as well. Then the visual feedback on add to card

The card page as well. Then the visual feedback on add to card that can be something that's medium priority. Style the card batch with item count. Yeah, that's fine as well. And finally, add hover effects, subtle transitions, mobile responsiveness across all views and polish empty cards, yeah. That can be a low priority. That looks good.

That can be a low priority. That looks good. Now I'm gonna go in and move the Snackbar web shop PRD to the backlog. So now we can run our modified rel.js script, which as I said before, I modified to support our new PRD format. And I modified it basically with this prompt. I said modify rel.js from our previous lesson to support the new PRD structure,

I said modify rel.js from our previous lesson to support the new PRD structure, allow me to choose a PRD. And if there's only one, we should bypass the selection. So now when we say node rel.js, it's gonna start our Snackbar web shop rel-loop. (upbeat music) And for fun, while it's running, let's duplicate this. So now we can see the selection in action, but let's improve this with an interactive selection.

So now we can see the selection in action, but let's improve this with an interactive selection. So let's say Claude in rel.js, I want to be able to select PRD's interactively instead of entering a number. All right, look at us being productive. It's done, let's test it, rel.js, and now we can interactively select a project. How cool is that? Let's monitor our rel-loop

How cool is that? Let's monitor our rel-loop and everything's actually looking fine. We see some errors because I'm always trying to delete things and we don't allow that, which is pretty good. Let's remove our duplicated PRD. And then let's meet back when the rel-loop is completed. (upbeat music) All right, we are done. So initially I started the rel-loop

All right, we are done. So initially I started the rel-loop and it actually reached the max iterations because it defaults to 10 and we had more than 10 tasks. So I restarted it again, and then it was able to complete everything. So what we actually should have done was not rel.js, like maybe 20 iterations. And then it would have run continuously. Anyways, let's take a look at what it built.

And then it would have run continuously. Anyways, let's take a look at what it built. Let's go to the app. We are in dev. And let's open this in a browser, right? This is not bad. Let's see if it works. All right, we have some interactions. We have some hover states. We can add things to the cart.

We have some hover states. We can add things to the cart. We have our cart page. We can modify prices. All right, we can delete things. Great. We can see our total that update. Yes, it does. This is looking pretty good. We have a nice empty state.

This is looking pretty good. We have a nice empty state. I mean, I'd say this is a pretty successful rel-loop. And let's actually dive into the code and see what it produced on our index.html. It updated the title that looks good. As our see, we have our components. That's, I didn't clean up the hella world, which kind of makes sense because it cannot do RM. So that's actually fine.

which kind of makes sense because it cannot do RM. So that's actually fine. Menu item, this looks great. Choose just a view three setup tag, great. Our cart composable, curious to see how that works. It's reactive, that's fine, quantity. So this is actually very interesting what the model does here because it's first gonna look for a cart item that matches the item we are trying to add.

because it's first gonna look for a cart item that matches the item we are trying to add. And if we have one, we will increase the quantity. And otherwise, we will push the item to the cart. And this way, we won't have two lines of the same articles. We won't have hamburger, hamburger. Instead, we would have hamburger with a quantity of two, which is pretty cool. Removing from the cart looks fine, incrementing the quantity looks fine, decrementing as well.

Removing from the cart looks fine, incrementing the quantity looks fine, decrementing as well. We cannot go below zero. That's great, calculating the total is fine, peering the cards is fine. So this is actually looking pretty decent. Let's look at the data, that's fine. The hello agent component is also not deleted, but that makes sense. Because again, we disallow deleting files.

but that makes sense. Because again, we disallow deleting files. So destructive actions are disallowed. So it makes sense that these files are still here. Overall, this is looking good, both from a functional perspective, as well as from a coding perspective. And that's all thanks to the product requirement document we fed the model. In this document, we were very clear about the scope.

document we fed the model. In this document, we were very clear about the scope. We had guardrails in place, and we instructed the model what it could and could not do. And the result is pretty neat. In the next lesson, we'll take a look at how we can run these loops in the background. I'll see you there.