Up until now we've been working with PRDs on our file system which works but it 's not the best experience. For example we can't really add much context to every sub-task as there's no real hierarchy here. Everything just lives in this one flat file. We can improve this experience by introducing a dedicated issue tracking tool like linear. I've been using linear for a few years now in my product development flow and in my opinion this is really one of the better trackers

now in my product development flow and in my opinion this is really one of the better trackers out there. It's stable and reliable, it's simple and straightforward but at the same time it's powerful enough to adapt to your specific workflow. The benefit of using linear with 12 is that we can have a better hierarchy between our sub-issues and our parent PRD. For example we can see our parent issue called example issue on screen and then we have a sub-issue with a description as well

parent issue called example issue on screen and then we have a sub-issue with a description as well and this means we can add extra context to our sub-issues so we can steer the model output even better. Let me show you. First things first let's setup our environment by following the instructions in the RIMI file. If you haven't already create a linear account and then let's quickly grab an API key. In linear we can press command K we can go to settings then we can go to security and access

API key. In linear we can press command K we can go to settings then we can go to security and access and when we scroll down we can create an API key here. After we've created and copied our API key we have to install it as an environment variable and since I'm using a Z shell I ran this command to put it in my Z shell RC file. Next let's also make sure we're on the latest version of the RELV CLI by CDing into the RELV CLI directory then we can say BUN install we can say BUN RUN build

RELV CLI by CDing into the RELV CLI directory then we can say BUN install we can say BUN RUN build and finally we can say BUN RUN install CLI. We need to enter our password here because we're simlinking the RELV binary to our BIN directory and I hope you trust me here but let's quickly take a look at the install script just in case. Besides a RELV binary we're also outputting a linear CLI script and this script will also be mounted inside our YOLO box which I will use

linear CLI script and this script will also be mounted inside our YOLO box which I will use and other than that we're just removing the original sim link and creating a new one. We can check which version is installed by saying RELV-version and we can see 0 .11 is installed. Alright let's open up our project and let's take a look at our RELV configuration file. We have our workspace mode which is still copy and write our directory is going to be the lower cast directory

our workspace mode which is still copy and write our directory is going to be the lower cast directory and I will use YOLO box and then I added some new configuration parameters we can say tracker is linear to instruct RELV to look at linear inside of our file system. We also have to instruct RELV on which team to use in this case it's going to be SAP and we can grab the team from the URL as we can see here. Next we will instruct RELV to only pick up issues with the label agent RELV applied

can see here. Next we will instruct RELV to only pick up issues with the label agent RELV applied and I also added polling capabilities so we don't need to manually dispatch or issue. Instead RELV will just pull linear every 30 seconds and look for new issues. Linear as an API rate limit of 5,000 requests per hour so we should be fine here. And finally the RELV CLI can now also automatically create PRs with the flag how to create PR set to true. This requires us to be authenticated

create PRs with the flag how to create PR set to true. This requires us to be authenticated using the GitHub CLI. Since I'm using YOLO box we also have to modify the configuration a bit we have to forward the linear API key environment variable because that does not happen automatically. Now when we run RELV we can see it's running in linear mode and at the bottom we can see how long ago it pulled linear we can press R to force a refresh or we can still press C to dispatch

ago it pulled linear we can press R to force a refresh or we can still press C to dispatch an issue from the linear backlog. While RELV is running let's take a look at our PRD linear skill. I created the skill for us which is based on our previous PRD skill but it will now save the PRD in linear using the API. We instruct the skill to also just take a look at a RELV configuration file to extract the linear team. Since linear has no official CLI we just instruct the model here

file to extract the linear team. Since linear has no official CLI we just instruct the model here to do the API requests inline. So right here we will extract the linear team from our RELV configuration file. Using the API it will then get resolved to an ID. Here we then resolve the backlog state ID. Finally we instruct the model to create a parent issue and we instruct the model to create child issues for each implementation task. And other than that it's basically the same as our other

issues for each implementation task. And other than that it's basically the same as our other PRD skill. Let's create a new PRD together. Let's say you're a box plot and let 's say we want to add a highlighting feature to our shop in which we can highlight a specific item. We can say grill me which is a skill I will talk about soon. I want to use PRD linear to describe a new feature highlighting a product. Now grill me is a nice skill from matpokok and it's a pretty simple skill

highlighting a product. Now grill me is a nice skill from matpokok and it's a pretty simple skill that will grill us relentlessly about the feature we're about to introduce. Now as we can see here the skill is pretty simple. We just basically asked the model to interview me relentlessly about every aspect of the plan until we reach a shared understanding. And as we can see here we get our first question. What does highlighting a product actually mean to the user? I will say it's a

first question. What does highlighting a product actually mean to the user? I will say it's a dedicated section at the top of the shop with featured items and the featured item should have a badge featured. Question two, how is the product determined to be featured? I want to have an is featured flag in the menu. Next should feature products appear only in the featured section? I would say yes, only show the featured product once in the featured section. How many products do

I would say yes, only show the featured product once in the featured section. How many products do we expect to be featured at a time? Let's say see unbounded. Should the featured section use the same grid layout and card component as the main menu with just a featured badge added? And I would say yes, pay is fine. How should the featured badge look like and where should it sit? Let's say top left and amber is fine. What should the header text be and should there be any visual separation

left and amber is fine. What should the header text be and should there be any visual separation between the featured section and the main menu grid? For the header, let's say featured items is fine and add an additional heading for the regular menu. And question eight, what should a regular menu section be? A is fine. Question nine, if every product gets flagged as is featured, the main menu section would be empty. Should we handle that edge case? I mean, let's say C,

the main menu section would be empty. Should we handle that edge case? I mean, let's say C, don't worry about it. And I think our feature is complete. We can say continue with PRD linear. And as you can see, all went well, all of our issues have been created. We have our parent issue and our child issues. So let's quickly take a look. As you can see, the parent issue got created. And if all went well, we should have our three sub issues created as well. Now going

created. And if all went well, we should have our three sub issues created as well. Now going into the sub issue, we can see we have a whole lot of extra context for the sub issue as well, which is very interesting for steering the model. Now everything's looking fine . So there's only a single thing left for us to do. You will put the status in to do, and we will add a label agent Ralph. And as we can see, all went well and Ralph picked up the PRD and started working on it

Ralph. And as we can see, all went well and Ralph picked up the PRD and started working on it automatically. While it's working, let me quickly show you how I modified the Ralph CLI to support linear cloud as a CLI flag called append system prompt in which we can add extra instructions. Let me quickly show you, we can say cloud dash dash append system prompt talk like a pirate. Now when we say you, Claude will respond back to us as a pirate. Now, in the case of starting

Now when we say you, Claude will respond back to us as a pirate. Now, in the case of starting Ralph in linear mode, we construct a system prompt that makes our linear CLI known to Claude. So let's quickly take a look at how our system prompt is constructed. Ralph CLI exposes an environment variable called Ralph linear, which points to our linear script on the file system. And then we basically just instruct Claude how to work with it. We can say things like you can

And then we basically just instruct Claude how to work with it. We can say things like you can get an issue, you can update an issue, create a comment at a label, removal labels, swap labels, etc, etc. And this is actually a great way to basically inject a skill without having to rely on skill files. So Claude knows how to interact with linear in every directory when we call it fire Ralph, because we inject this system prompt. All right, and it looks like Ralph is done.

Ralph, because we inject this system prompt. All right, and it looks like Ralph is done. It created a pull request. So let's test it out. And there we go. We have a very nice featured item section at the top. We have three featured items or burger or pizza and our milkshake. And we can see the nice featured batch in the top left. And everything should still work as expected. Finally, let's take a look at the PR. We have three files changed. We have our batch

expected. Finally, let's take a look at the PR. We have three files changed. We have our batch being added. We have some CSS being added, which is fine. We have the flag is featured set to true on a few items. And finally, we update the menu page. We have featured item section and a regular menu section. This is looking fine. And let's go ahead and merge the pull request confirm. If you jump to linear, we can see the parent issue is set to done. And I expect child issues

If you jump to linear, we can see the parent issue is set to done. And I expect child issues to be set to done as well. All right. And because we have the GitHub integration set up, it also detected the pull request and a detected it got merged. This is pretty cool. All right. Now that we introduced linear, we're really starting to become a power user of our health. But there is one critical thing still missing. And that is the human in the loop. Let me show you in the next lesson.

one critical thing still missing. And that is the human in the loop. Let me show you in the next lesson.