I open-sourced the prompt workflow I use to plan my own projects. It sat at 77 stars for six months, then gained 628 in a single month. Here is what the repo actually contains and what the star curve really shows.
I kept re-typing the same four prompts. Every time I started a project I would ask a chat model to research the idea, then write a PRD, then pick a stack, then explain all of it again to whatever coding agent I had open. The answers were fine. The re-typing was not, and each fresh chat lost everything the previous one had decided.
So I wrote the four prompts into markdown files, added the docs a coding agent should read before it touches anything, and put the whole thing on GitHub in April 2025. It was housekeeping for one person. I did not expect anyone else to use it, and for six months nobody much did.
Every number below comes from the GitHub REST API for KhazP/vibe-coding-prompt-template, read on 4 August 2026. Nothing here is an estimate of usage, because stars are not usage.
GitHub REST API, 4 August 2026
Plus a "Use this template" button, which GitHub does not count as a fork
v1.0.0 (27 Nov 2025) through v3.0.0 (18 Jul 2026)
First commit 14 April 2025
Source: gh api repos/KhazP/vibe-coding-prompt-template, fetched 2026-08-04
Two contributors, zero open issues at the time of that snapshot, MIT licence. That is the whole scoreboard. I have no download counts, no analytics on who clones it, and no way to tell how many of those 2,806 accounts ever opened a file. I would rather say that than guess.
It is a repository of markdown. There is no package to install and nothing to run, apart from one Python script that checks your files are where they should be.
The core is four prompts you paste into a chat model, in order:
Alp Yalaypart1-deepresearch.md asks the model to pressure-test the idea: demand, competitors, whether the scope is realistic. Twenty to thirty minutes.part2-prd-mvp.md turns that into a product requirements document scoped to an MVP.part3-tech-design-mvp.md walks through stack choices against your budget, timeline and tolerance for complexity.part4-notes-for-agent.md is the one you give to your IDE agent. It tells the agent to read the first three outputs and fill in the templates.The first three run in ChatGPT, Claude.ai or Gemini before you have a repo at all. Only the fourth needs an IDE.
Around that core there are three things I added later because people asked:
Tool adapters. templates/tool-adapters/ has thin pointer files for each tool — CLAUDE.md for Claude Code, .cursor/rules/vibe.mdc for Cursor, .agent/rules/vibe.md for Antigravity. Codex reads AGENTS.md natively and needs nothing. Each adapter is a pointer rather than a copy, so the instructions live in one place. Cursor commands, Antigravity workflows and Codex prompts are included for the same six stages.
Claude Code skills. .claude/skills/ contains six: /vibe-research, /vibe-prd, /vibe-techdesign, /vibe-agents, /vibe-build, and /vibe-workflow as an orchestrator that runs the other five in sequence. They install individually with npx skills add.
A worked example. examples/reddit-to-ai/ is a full set of outputs — research doc, PRD, tech design, AGENTS.md, MEMORY.md — so you can see what good output looks like instead of guessing.
There are three GitHub Actions workflows, and they are smaller than that phrase suggests: a first-time contributor greeting, a PR size labeller, and a lint job that checks the required template files still exist, that no placeholder email survived in SECURITY.md, and that nothing references a filename or skill that was renamed. It is a guard against my own broken links, not a build pipeline.
There is also a website version of the template, which walks through the same stages in a browser. This case study is about the repository.
The failure mode I was solving for is specific. If you describe a feature to a coding agent in chat, the agent has to infer the parts you left out — folder layout, naming, what counts as done, which of your earlier decisions still hold. It infers plausibly and often wrongly, and by the time you notice, the wrong assumption is in twelve files.
Writing the decisions down first does two things. The agent reads a file instead of guessing, and you get to disagree with the decision before any code exists, when disagreeing is free. The PRD stage is where I have killed the most bad ideas, including several of my own.
The other half is the loop the README pushes: plan, get the plan approved, execute one feature, verify, repeat. Nothing about that is novel — it is how you would brief a junior developer. The template's contribution is that it produces the brief for you in about an hour, instead of you writing it by hand every time or, more realistically, skipping it.
I use it on my own work. The README lists the projects built this way, including the RealDex mobile app and vibeworkflow.app itself.
For six months the repo gained between 5 and 24 stars a month and finished October 2025 at 77 total. That is the honest baseline: a public folder of markdown that a handful of people found.
November 2025 added 628 stars, more than eight times the entire preceding total. I published v1.0.0 on 27 November, and the month the repo got found is the month it got a version number. I cannot prove which caused which. Releases do not generate 628 stars on their own, and I have no referrer data — GitHub does not give traffic history to a repo owner beyond a rolling two-week window, and I did not capture it at the time. What I can say is that the release gave the repo something to link to, and that the growth held afterwards rather than spiking and dying: 488 in December, 394 in January, then a slow decline into a floor of roughly 120 to 250 stars a month that has not broken since.
Webapp Release. The first tagged version, published in the month the repo was found.
Enhanced Tool Ecosystem & Webapp Integration. Support for more IDEs and agents.
2026 workflow refresh. Reworked prompts for the model generation then current.
Claude Code Skills & Hooks. The six /vibe-* skills land.
Agentic Era. Multi-agent orchestration and artifact-first memory guidance.
Audit & Hardening. Governance, security policy, and the repo lint workflow.
The Contracts Release. AGENTS.md as the single instruction contract, with thin adapters pointing at it.
The shape of that list is the actual lesson. Two thirds of the releases came after the audience did. Everything up to v1.0.0 was me solving my own problem; everything after was maintenance work for other people's tools, other people's editors, and other people's questions. The v2.4.0 hardening release exists because a public repo with a [your-email] placeholder in its security policy is embarrassing, and the lint job exists so I cannot make that mistake twice.
Publishing early cost me nothing and taught me nothing for six months. That is fine — the repo was useful to me during those six months regardless of whether anyone starred it, which is the only reason it survived to November. If it had needed an audience to justify the effort, I would have deleted it in July.
The version number mattered more than I expected. Not because v1.0.0 changed the content much, but because it gave the project a surface people could point at and a moment worth mentioning. Six months of quiet commits gave nobody a reason to link to anything.
And the maintenance is real. Seven releases, a governance file, an issue template set, a code of conduct and a lint workflow are not what I set out to build when I got tired of re-typing four prompts. If you put a workflow in public and it lands, you have taken on a second project.