# KhazP/vibe-coding-prompt-template: A Prompt Chain for Planning Before Your AI Agent Builds

> The repository turns a vague app idea into a research brief, a PRD, a tech design, and an AGENTS.md file, then hands the build to your AI IDE. It is a process, not a code generator, and its value depends on whether you actually follow the steps in order.

**KhazP/vibe-coding-prompt-template** — Templates and workflow for generating PRDs, Tech Designs, and MVP and more using LLMs for AI IDEs

- Repository: https://github.com/KhazP/vibe-coding-prompt-template
- Website: https://vibeworkflow.app/
- Stars: 3,120 · Forks: 385
- Language: TypeScript
- License: MIT
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/khazp-vibe-coding-prompt-template

## The problem is not code generation, it is deciding what to generate

An AI IDE will happily write a thousand lines for an idea you have not thought through. The failure mode is not syntax errors, it is building the wrong feature set for three days and discovering the mismatch only when you try to demo it. This repository is aimed at that gap. It is a set of prompt files plus a CLI, and its stated purpose is to help you "decide what to build, check what works, and recover when it breaks." The audience is people using Claude Code, Cursor, Codex, or Gemini CLI who want a paper trail before the agent starts editing files. The README names Claude, Gemini, ChatGPT, Cursor, and VS Code as supported surfaces, and the workflow is designed to run in a plain chat tool for the first three steps, with no repository required. That split matters: you can do the thinking phase in a browser tab, then move into the IDE for execution. It is not a framework and it does not generate application code. It generates the documents that tell your agent what code to write.

## Five steps, three phases, and a CLI that routes you

The flow is linear and the README presents it as a table. Deep Research produces a document with sources when browsing is available, or a research prompt when it is not. The PRD step turns that into scope, and the Tech Design step picks the surface, stack, and deployment. Those three live in the chat tool and correspond to part1-deepresearch.md, part2-prd-mvp.md, and part3-tech-design-mvp.md at the repository root. Step four is where the repository becomes tooling: running the CLI generates AGENTS.md and an agent_docs/ directory, which is the file AI IDEs read for project context. Step five is the build itself, done in your IDE in "small, verified passes." The CLI adds routing on top of the static prompts. According to the README, it inspects what already exists in the folder and then routes to one of three paths: start something new, continue my project, or something broke. Planning depth is also selectable, with Quick, Guided, and Deep modes, so the number of questions scales with project size. Version 0.3.0 of the vibeworkflow package adds slash commands for existing apps: /vibe-change, /vibe-debug, and /vibe-verify. Those three commands are the recovery half of the promise, and they only make sense if AGENTS.md and agent_docs/ were generated first, because that is the context the agent reads when it runs them.

## Installing vibeworkflow and running the first planning pass

There is no build step and no global install described in the README. The documented entry point is npx, run from inside your project folder, and it is meant to be invoked by your AI agent rather than typed by hand. Open Claude Code, Cursor, Codex, or Gemini CLI in the project directory and give it this instruction:

```bash
Run `npx vibeworkflow` and follow its instructions.
```

The README says to start either in a clean folder or in your existing app. The CLI inspects the directory first, then asks you to choose a route. If you pick the new-project path, expect questions about the idea before any file is written, and expect the number of questions to depend on whether you chose Quick, Guided, or Deep planning. When the planning phase finishes, the workflow writes AGENTS.md and an agent_docs/ directory into the repository. That is the artifact worth checking before you continue: open AGENTS.md and confirm the stack, commands, and constraints match what you actually intend to build, because every later agent step reads from it. If you would rather not use the CLI at all, the README documents a manual path: paste part1-deepresearch.md into a chat tool, save the output as research-[YourAppName].md, then paste part2-prd-mvp.md below it in the same chat, or start a fresh chat and paste the saved research first. The repository also ships a runnable reading-list example under examples/reading-list/ if you want to see the output shape before committing your own idea to it.

## The prompt files are the product, and prompts drift

Everything here is text. The CLI is TypeScript and the templates are markdown, which means the quality of your output depends on the model reading them and on your willingness to answer the questions honestly. The README itself flags the weak point of step one: if your chat tool has no web search, source grounding, URL context, or deep research mode, the Deep Research step cannot research anything. It degrades into producing a research prompt for you to run elsewhere. That is a real limitation, not a footnote, because the PRD step is supposed to be grounded in the research output. There is a second constraint the README does not resolve: nothing in it describes what happens when you run the CLI against a repository that already has an AGENTS.md written by hand. The routing logic inspects what exists, but the README does not document whether an existing file is merged, overwritten, or skipped. Treat that as unknown until you check it in a throwaway directory. The larger caveat is structural. A prompt template is only as good as the model version interpreting it, and the repository has no test suite that verifies a given model still follows part2-prd-mvp.md the way it did when the file was written. If your agent starts ignoring sections of the PRD prompt, that is a model change, not a bug you can report.

## How this differs from spec-driven tooling like GitHub Spec Kit

GitHub Spec Kit is the closest comparison and the difference is where the artifacts live. Spec Kit installs a set of slash commands into your repository and drives the whole loop from inside the coding agent, with specifications, plans, and tasks as files the agent reads and updates as it works. This repository splits the loop in two: the first three steps are designed to happen in a chat tool with no repository at all, and the CLI only enters at step four to write AGENTS.md. That makes it friendlier to someone who has not set up an agent workflow yet, and it makes the planning artifacts portable across tools, since a PRD saved as a markdown file does not care which IDE produced it. The trade-off runs the other way too. Spec Kit keeps specification and implementation in one system, so a change to the spec is visible to the agent immediately. Here, if you edit your PRD after generating AGENTS.md, nothing in the documented flow tells you to regenerate it. You have to remember. The repository also ships a Claude Code specific path under .claude/, described as built-in skills, which suggests the maintainers are willing to add per-tool integrations rather than stay strictly tool-neutral.

## Licence, releases, and what maintenance actually looks like

The project is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is permissive enough that embedding the prompt files in an internal template library is within the terms, though the usual caveat applies: this is a description of the licence text, not legal advice, and if you redistribute the files inside a product you should read LICENSE yourself. Maintenance signals are recent. The last push to main was on 2026-09-05, and the release history shows v3.1.0 on 2026-08-20, v3.0.0 on 2026-07-18, and v2.4.0 on 2026-04-09. The release names carry meaning: v3.0.0 is called the Contracts Release and v3.1.0 the Agent-First Release, which suggests the AGENTS.md and agent_docs/ mechanism arrived in the 3.x line. Upgrade cost is low in the mechanical sense, because npx pulls the current version and the prompts are markdown you can diff. The real upgrade cost is re-running planning against an existing project when the template's question set changes, and the README does not document a migration path for projects generated under 2.x. If you pinned output from an older version, diff the generated AGENTS.md against the new template before trusting it.

## Where the workflow gets in the way

The five steps assume you are building something new enough that research and a PRD are worth writing. For a bug fix, a small internal script, or a feature added to a codebase you already understand, the planning phase is overhead you will skip, and the README's own recovery commands are the only part that applies. The manual path has a subtler cost: it depends on you keeping a chat session open or saving intermediate files with the exact naming convention the README gives, research-[YourAppName].md. Lose that file and step two has nothing to ground itself in. There is also no documented answer for teams. The workflow is written in the second person singular, and nothing in the README describes how two engineers share a PRD, who owns AGENTS.md, or how the CLI behaves when run twice in the same repository. If your team already has a spec review process, this repository adds a parallel one rather than replacing it. The honest framing is that this is a personal workflow that happens to be packaged well enough to share, and the parts that scale to a team are the generated markdown files, not the CLI.

## Conclusion

Adopt it if you are starting a new app with an AI IDE and keep losing the thread between chat sessions, because the numbered prompt files give you a fixed sequence and a place to store each output. Skip it if you already have a PRD and a tech design you trust, since the workflow will mostly ask you to redo work. Before committing, read part3-tech-design-mvp.md to check whether its stack assumptions match yours, and confirm that the AGENTS.md file the CLI writes into your repo is something your team wants version-controlled.

## FAQ

### What is vibe coding and how do you do it with KhazP/vibe-coding-prompt-template?

The repository frames it as a workflow in which your AI writes the code but you decide what to build and verify what works. You do that by running the five steps in order: Deep Research, PRD, Tech Design, agent file generation, then building in small verified passes.

### What are examples of vibe coding projects built with this template?

The README names vibeworkflow.app, moneyvisualiser.com, caglacabaoglu.com, and the RealDex App as projects used with the workflow. The repository also includes a runnable reading-list example under examples/reading-list/.

### What are prompts in coding, in the context of KhazP/vibe-coding-prompt-template?

Here they are markdown files at the repository root, part1-deepresearch.md through part4-notes-for-agent.md, that you paste into a chat tool or that the vibeworkflow CLI uses to generate AGENTS.md and agent_docs/.

### How is vibe coding different from regular coding with KhazP/vibe-coding-prompt-template?

The README draws the line at who writes the code versus who decides the scope: the AI can write code, and the workflow exists to help you decide what to build, check what works, and recover when it breaks. In practice the first three steps happen in a chat tool with no repository, and only the build step runs in your IDE.

## Sources

- [KhazP/vibe-coding-prompt-template on GitHub](https://github.com/KhazP/vibe-coding-prompt-template)
- [License: MIT](https://github.com/KhazP/vibe-coding-prompt-template/blob/main/LICENSE)
- [Project website](https://vibeworkflow.app/)
- [README](https://github.com/KhazP/vibe-coding-prompt-template/blob/main/README.md)
- [Releases](https://github.com/KhazP/vibe-coding-prompt-template/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/khazp-vibe-coding-prompt-template