> ## Content Index > Fetch the complete content index at: https://jonathancanales.com/llms.txt > Use this file to discover other available public pages before exploring further. # Files you need for vibe coding: give your AI context and order - URL: https://jonathancanales.com/en/files-for-vibe-coding-context-and-order/ - Published: 2026-10-05T14:00:00.000Z - Updated: 2026-10-19T01:02:30.000Z - Description: Tell an AI "build me an app" and nothing else, and it does what any new hire with no briefing would do: it guesses. Sometimes it guesses well. More often it guesses fast and with great confidence, which is worse. The fix is not a longer prompt. - Author: Jonathan Canales - Tags: Technology and tools, #en Files you need for vibe coding: give your AI context and order 0:00 /422 1× [![Listen on Spotify](https://jonathancanales.com/content/images/2026/10/image-ebade917.jpg)](https://open.spotify.com/show/1RbZ5C2DI8VFR4RA6paicv?ref=jonathancanales.com) [Read in Spanish →](https://jonathancanales.com/archivos-para-vibe-coding-contexto-y-orden/) Tell an AI "build me an app" and nothing else, and it does what any new hire with no briefing would do: it guesses. Sometimes it guesses well. More often it guesses fast and with great confidence, which is worse. The fix is not a longer prompt. It is a few plain text files that say what you are building, how, and under which rules. There is a list of files that solves exactly this. The idea is a good one, so here is a plain-language version. One caveat: it is not a standard; it is one content creator's practice, cited at the end. Below I separate what is truly useful from what is optional, and what the tools actually do with these files. The context on what vibe coding is and who it suits: [what vibe coding is, how to do it right and who it's for](https://jonathancanales.com/en/what-is-vibe-coding-how-to-do-it-right-who-its-for/). ## The core idea: memory for someone who forgets everything AI coding tools start each session nearly blank. Claude Code's documentation says it plainly: every session begins with a fresh context window, and CLAUDE.md files are how instructions carry over from one session to the next. Picture a brilliant colleague with amnesia. Every morning you have to leave a note on the desk. These files are the note. Some of those tools run on your own computer: [AI that codes on your own computer: local LLMs](https://jonathancanales.com/en/ai-that-codes-on-your-own-computer-local-llms/). ## The files, one by one The list has these documents inside a `docs` folder. Here is what each one tries to solve: - **PRD.md** (product requirements document): what you are building, for whom, and which problem it solves. The "what" and "why." - **TRD.md** (technical requirements): how it should work technically. In the original example it lists the tech stack, technical goals, integrations and constraints. The "with what." - **APP\_FLOW.md**: how a user moves through the product, screen by screen. - **IMPLEMENTATION\_PLAN.md**: the build order in phases and milestones, including a post-launch stage. - **TESTING.md**: how to verify everything works, with test cases and a checklist. - **BACKEND\_SCHEMA.md**: the structure of the data (what is stored and how it relates). - **README.md**: the project's front page, for humans. - **AGENTS.md**: direct instructions for the AI agent. - **DESIGN\_SYSTEM.md**: colors, fonts and components, so the interface does not change personality every third screen. - **ARCHITECTURE.md**: how the system is organized inside. - **SECURITY.md**: security rules, handling of keys and data. - **CODE\_STYLE.md**: coding conventions. Twelve files sounds like an office with a lot of paperwork. Here comes the important part. ## What is required and what is habit No tool forces you to have those twelve names. They are the convention of the source cited at the end, a good one, but a convention. What actually exists as a recognized format is shorter: - **AGENTS.md** is an open format, described at agents.md as "a README for agents": a predictable place for install commands, tests and style rules. Tools such as Cursor, Aider, Amp, Gemini CLI, Zed and Windsurf read it, among others. - **CLAUDE.md** is Claude Code's equivalent. Its documentation suggests keeping it under 200 lines and specific: the longer it gets, the worse it is followed. - **Cursor rules** live in the `.cursor/rules` folder and can be version-controlled with the project. The rest (PRD, TRD, plan, schema and so on) are ordinary documents. They work because the agent can read them when you point to them, or when your instructions file says they exist. Not because the tool recognizes them by name. That difference matters: if you think dropping a PRD.md in a folder means the AI "just knows," you are in for a letdown. 💡 And an honest warning from Claude Code's own documentation: these instructions are context, not enforced rules. The model takes them into account, but there is no guarantee. If something must never happen, it needs a technical control, not a polite sentence in a file. ## A sensible start for a small business If you are building an internal tool or a prototype, do not start with twelve files. Start with three and grow when it hurts: 1. **A short product document** (your PRD, one page): what it is, who it is for, what it will NOT do. The "will not" list is gold, because AI loves adding things nobody asked for. 2. **A short AGENTS.md or CLAUDE.md**: how to install, how to test, which conventions to follow, what never to touch. A few concrete lines. 3. **A phased plan**: build in small reviewable pieces instead of "do it all." As the project grows, add the rest where the pain is. Does the AI invent data? Write the schema. Does the interface look different on every screen? Write the design system. Same mistake again? It goes in the instructions file. Claude Code's documentation gives exactly that test: add a line when the AI makes the same mistake a second time. ![Whiteboard-style drawing: three connected files: what I build, how and rules, phases](https://jonathancanales.com/content/images/2026/10/4-vc-doodle-files-en-g.png) ## How to write them without making a mess - **Short and concrete.** "Use strict TypeScript and run the tests before finishing" helps. "Write quality code" helps nobody. - **Readable by a human.** If you do not understand your own document, the AI will not follow it better. - **Keep them current.** An outdated plan is worse than no plan: the AI obeys it with total seriousness. - **No keys or passwords.** These files travel with the code. Secrets live elsewhere. - **Let the AI help draft them, but you decide.** Asking for a first draft is fine. Accepting it unread is not. ## My take The valuable part of this list is not the file names. It is the habit: before asking an AI for code, write down what you want, how it will be built and how you will know it came out right. That is organizing your thinking, and it helps a human developer who joins next month just as much. Documenting feels like a chore until you realize there is now a reader who reads all of it, every time, without complaining. And if your project fits on one page, one page is enough. Nobody has won an award for the longest PRD. ## Sources and editorial note AGENTS.md format: [agents.md](https://agents.md/?ref=jonathancanales.com). Memory and CLAUDE.md files: [Claude Code documentation](https://docs.claude.com/en/docs/claude-code/memory?ref=jonathancanales.com). Project rules: [Cursor documentation](https://cursor.com/docs/rules?ref=jonathancanales.com). The document list and descriptions come from a productwithzeey reel; they are examples from her workflow, not requirements of any tool.