Write a natural-language specification optimized for feeding to AI coding assistants. Covers problem statement, user flows, data model, API contracts, UI descriptions, tech stack, and constraints.
From pm-vibe-codingnpx claudepluginhub tarunccet/pm-skills --plugin pm-vibe-codingThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
| Input | Required? | Example |
|---|---|---|
| Product idea or feature to build | ✅ Required | "A job board for climate tech roles with GitHub sign-in" |
| Core user flow (step-by-step) | ✅ Required | "User lands → browses jobs → applies → gets email confirmation" |
| Target AI coding tool | 🟡 Recommended | Cursor, Replit Agent, Claude Code, Bolt.new, v0.dev, Windsurf |
| Preferred tech stack | ⚪ Optional | Next.js + Supabase + Vercel, or "let AI decide" |
| Known constraints | ⚪ Optional | "No backend, static only" / "Must use our existing auth" |
Don't have everything? Start anyway — the skill will work with what you provide and flag where richer input would improve the output.
Generate a comprehensive "vibe spec" — a structured natural-language specification document designed to be fed directly into AI coding assistants (Cursor, GitHub Copilot, Replit Agent, Claude Code, etc.) to build a working product. A good vibe spec eliminates back-and-forth with the AI by front-loading decisions, context, and constraints.
"Vibe coding" (term coined by Andrej Karpathy, 2025) describes building software primarily through natural language instructions to AI coding assistants, with the human providing direction, design judgment, and product sense rather than writing code line-by-line. For a PM-builder, the vibe spec is the equivalent of an engineering spec — but written in a way that AI assistants can directly execute.
The key insight: AI coding assistants perform dramatically better with explicit data models, user flows, and constraints defined upfront. Ambiguity creates hallucinated architecture. Specificity creates working code.
Different AI tools interpret specs differently:
Context window considerations: Long specs (1500+ words) may need to be chunked when pasting into tools with smaller context windows. For Replit Agent and Bolt.new, lead with the problem statement and core flows — move API contracts and detailed schemas to follow-up prompts. For Cursor and Claude Code, paste the full spec upfront since they handle longer contexts well.
You are helping a PM-builder create a vibe coding specification for $ARGUMENTS.
Ask the user these questions if not already provided:
Then generate the vibe spec document:
For each core flow (2-3 maximum):
Generate a system prompt header to paste at the top of the AI coding session:
You are building [product name].
Tech stack: [stack]
My goal: [one sentence]
Start by: [first task]
Coding style: [preferences — e.g., TypeScript strict, functional components, no class components]
File structure: [preferred structure]
When uncertain: ask me before proceeding
Do not: [anti-patterns to avoid — e.g., don't use Redux, don't write raw SQL]
Provide the 3-5 prompts to use in sequence at the start of the coding session:
A single markdown document with all 9 spec sections (Steps 1–9), formatted for direct paste into an AI coding assistant context window. The AI-facing spec must include only Sections 1–9. Keep Step 10 (Spec Iteration Guide) in a clearly separated appendix or a separate document labeled e.g. Appendix (PM-only — do not paste into AI) with a visible delimiter such as ----- PM-only appendix below — do not paste into AI -----; this PM-only content is not pasted into the AI. Aim for completeness over brevity — a 500-word spec is better than a 100-word spec when it prevents 2 hours of back-and-forth.
----- PM-only appendix below — do not paste into AI -----
This section is a PM-only reference for revising your spec after the AI produces its first output. Do not paste this into the AI coding assistant.
After the first build attempt, revisit these sections:
When to rewrite vs. patch: If the AI's first output is 70%+ aligned with the spec, iterate with targeted corrections. If the AI went in a fundamentally wrong direction (wrong architecture, wrong data model structure), rewrite the relevant spec section with more explicit constraints and start that section fresh.
Input: "A simple waitlist landing page with email capture and a Notion-style admin dashboard to manage signups"
Output excerpt:
A landing page for a new product that captures waitlist signups, lets visitors submit their email and name, and provides a simple admin dashboard to view, filter, and manage signups. The goal is to go from 0 to a live waitlist page in one day.
Out of scope: Email drip campaigns, referral system, analytics dashboards, payment.
| Entity | Fields | Type | Notes |
|---|---|---|---|
| Signup | id | uuid | auto-generated |
| string | unique, required | ||
| name | string | optional | |
| created_at | timestamp | auto-generated | |
| source | string | UTM source, optional | |
| status | enum | pending/approved/rejected, default: pending | |
| Admin | id | uuid | auto-generated |
| string | unique, required | ||
| password_hash | string | bcrypt hashed |
You are building a waitlist landing page with admin dashboard.
Tech stack: Next.js 14, TypeScript, Tailwind CSS, Supabase (Postgres + Auth), deployed on Vercel.
My goal: A landing page that captures email signups and an /admin route to manage them.
Start by: Creating the Next.js project with TypeScript and Tailwind, then the Supabase schema.
Coding style: TypeScript strict mode, functional React components, no class components, use shadcn/ui for UI components.
When uncertain: Ask me before choosing a library or architecture pattern.
Do not: Use Redux, write raw SQL, hardcode any secrets.