Vibe prompt

Vibe-Prompt — App Build Kickoff Generator

Turn a vibe coder's rough app idea into a complete, optimized kickoff package they can paste straight into Claude Code. Built on Anthropic's official prompting best practices (see Sources). The goal is not just a good prompt — it's getting the user to build the app properly instead of one-shotting a vague request and fighting the results.

What this skill produces

A kickoff package, not a single prompt. Four parts:

1. SPEC — a concise PRD: problem, users, MVP feature list, tech stack, success criteria.
2. INITIAL BUILD PROMPT — the optimized first message to paste while in plan mode.
3. FEATURE PROMPT SEQUENCE — ordered follow-up prompts, one per vertical slice.
4. WORKFLOW CHECKLIST — the build-it-properly steps, copy-paste ready.

Plus a short WHY THESE CHOICES rationale so the user learns the technique.

The build-it-properly workflow (teach this first)

Before generating anything, make sure the user understands the process. These are the steps a vibe coder should follow to build an app well. Surface them early and bake them into the WORKFLOW CHECKLIST output.

1. Always start in plan mode. Press Shift+Tab until you see "plan mode on" before sending the initial build prompt. Let Claude explore and propose a plan; read it and approve before a single line of code is written. This is the single highest-leverage habit — it catches wrong assumptions before they become wrong code.
2. Write the spec before code. Paste the SPEC first so the agent shares your mental model. Clear, complete, upfront task descriptions maximize quality and minimize churn.
3. Pin the tech stack explicitly. Never let the agent guess the framework, language, or styling. Underspecified stacks cause rewrites. If the user doesn't care, recommend a sensible default and state it.
4. Create a CLAUDE.md at the project root. Put the stack, conventions, run/test commands, and "don'ts" there so every future session starts grounded.
5. git init and commit after every working slice. Cheap checkpoints. When a vibe- coding turn goes sideways, roll back instead of fighting it.
6. Build one vertical slice at a time. Use the FEATURE PROMPT SEQUENCE — one feature, end to end, then the next. Never "build the whole app" in one shot.
7. Verify each slice in the real app before moving on. Run it, open it in the browser, click the thing. Don't trust "done" you haven't seen working.
8. Edit conversationally, don't re-roll. When something is 90% right, ask for the specific change rather than regenerating from scratch.
9. Keep it minimal. Tell the agent not to add unrequested abstractions, files, or "improvements." Scope creep from the agent is real — the INITIAL BUILD PROMPT guards against it.

Step 1 — Thorough discovery interview

Interview the user before generating. Ask 2-3 questions per round, not all at once. Start with the biggest gaps in what they already told you. Walk every dimension below before producing the package (thorough discovery):

Dimension	What to find out
Problem / purpose	What does the app do and what problem does it solve?
Target users	Who uses it? Solo tool, team, public consumers?
Core features (MVP)	What's the must-have v1 vs. the later wishlist? Separate them.
Key screens / flows	The main pages and the primary user journey through them.
Data & persistence	What data is stored? Local, file, database? Roughly what shape?
Auth	Do users log in? Single user, accounts, roles?
Tech stack	Preferred framework/language/styling. If none, recommend a default.
Design direction	Look and feel, brand, any reference sites/screenshots.
Integrations / APIs	Third-party services, payments, AI, email, etc.
Success criteria	"Done looks like…" — concrete, testable.
Constraints	Deadline, hosting target, budget, must-use tools.

If the user is non-technical and has no stack preference, recommend a simple, well- trodden default (state it explicitly in the SPEC) rather than leaving it open.

Step 2 — Read the reference

Before assembling output, read reference.md in this skill directory. It contains the prompting best-practices cheatsheet, the verbatim copy-paste blocks (frontend anti-slop, scope control, investigate-before-answering), and the fill-in templates for all four package parts plus a worked example. Apply those techniques when generating.

Step 3 — Emit the kickoff package

Produce four clearly labeled blocks, in order. Use the templates in reference.md.

• SPEC — concise PRD. Problem, users, MVP feature list (numbered), explicit stack, success criteria. Keep it scannable.
• INITIAL BUILD PROMPT — the optimized first message. It MUST:
  • Open with a role line ("You are a senior engineer building…").
  • Use XML-tagged sections: <context>, <stack>, <requirements>, <constraints>, <success_criteria>.
  • Explicitly instruct: "Start in plan mode. Explore the relevant code, then propose a plan and wait for my approval before writing any code."
  • Include an "above and beyond" modifier where a fuller implementation is wanted.
  • Drop in the <frontend_aesthetics> anti-slop block when the app has a UI.
  • Include the anti-over-engineering scope-control block.
  • Include an investigate-before-answering line.
  • State the stack and success criteria concretely — say what to do, not what not to do.
• FEATURE PROMPT SEQUENCE — an ordered list of follow-up prompts, one per vertical slice. Each is self-contained, names the feature, and ends with how to verify it.
• WORKFLOW CHECKLIST — the section-2 steps condensed into a checkbox list the user can paste into their notes or CLAUDE.md.

Then add WHY THESE CHOICES — a few bullets explaining the key technique decisions (why plan mode, why XML structure, why the scope block) so the user learns.

Step 4 — Offer refinement

After presenting the package, invite changes:

"Want to adjust anything? I can change the stack, re-scope the MVP, push the design in a different direction, or regenerate just one part (spec, build prompt, feature sequence, or checklist)."

Iterate until the user is satisfied.

Anti-patterns to avoid

When reviewing or building the package, watch for and fix these:

• Vague one-liners ("build a recipe app") — expand into a real spec.
• No stack pinned — always state it, recommend a default if needed.
• "Build everything at once" — split into a feature sequence of vertical slices.
• Skipping plan mode — the build prompt must instruct plan-mode-first.
• Tag soup / keyword lists — write clear instructions, use XML structure.
• Contradictory or excessive requirements — keep the spec coherent and minimal.
• No success criteria — "done" must be concrete and testable.

Sources

Prompting guidance in this skill is based on Anthropic's official docs:

• Prompting best practices
• Prompt engineering overview