Initialize Lovable project with custom knowledge

We are now ready to start implementing the front-end. We'll open Lovable and paste the PRD into it. You'll notice it does a very good job. It got very close to what we described in our PRD. We have the landing page, the authentication search page, results page, all of it implemented in one go. And this is actually the problem, lovable just one shot at it. We already know that this is exactly how you end up with layers of patches and broken code. To avoid this, we need to instruct the coding agent to first break down the PRD into individual pages, just like in our PRD. To avoid this, we need to instruct the coding agent to first break down the PRD into each page, just like the recipe results page, or recipe detail page, and ask it to implement each page one by one. It is called decomposition, and it is one of the ground rules of vibe coding. In Lovable, you add these ground rules in the project settings under the Knowledge tab. Anything you write here is remembered and applied across every single conversation and future edit. If you go to the documentation page in Lovable, you can find guidelines on what you could include in your custom knowledge, like user personas, design assets, coding conventions, and things like that. Some are project specific. Others are general software development principles that apply to most projects. I've prepared a custom knowledge file for this project that you can use or adjust it to use on your own project. I've listed 10 software development principles for our brilliant intern to follow. One note here, as we learned, LLMs are non-deterministic in nature, so you can expect that they won't always follow these instructions. That is why I like to remind Lovable to use TDD as we implement features. We add these principles to the knowledge file to limit the number of issues down the road, but we won't be able to completely avoid them. Don't let these technical terms scare you. Let me explain the three most important. You can learn more about the other seven principles in the included PDF handout. First, let's talk about don't repeat yourself rule. AI will happily duplicate some logic across multiple places to move faster. And that's a trap. If something changes, you don't want to fix it five times. Write it once and reuse it. When it comes to web application security, there is one critical rule. Never trust the client. We'll discuss it later, but for now, think of it this way. Imagine you work at the post office and the customer wants to pick up their package. You don't just give them the key to the back room so they can do it themselves. It is the same in software. And finally, the rule we already talked about, decomposition. We build software like we're using Legos. We snap one block in, test it to ensure it's solid, and then add the next one. If the tower starts to wobble, we know exactly which block caused it. Let's start with a new lovable project to do this right. You want to add these instructions to the knowledge tab before generating code. But there is a catch. You can't access the custom knowledge tab until a project exists. This is a lovable specific quirk. To get around this, we use a blank slate prompt. Go to lovable main page and type this into a chat. Initialize this project in a paused, empty state. Do not generate features, files, or code. Do not infer a goal. Acknowledge and wait for my instructions. This wakes the project up without generating code. Now, we can access the settings and paste our ground rules into custom knowledge. Now we are ready to implement the front-end. Knowledge is meant to be a living document. As you progress through the development, there may be new rules that you want to add here, like the design rules to ensure it's consistent throughout every page.