Turn vague ideas into documented, buildable software projects

Not-a-Vibe-Coder

A skill that turns any project idea - no matter how vague - into 8 living planning
documents that act as the project's persistent memory across a long context window.
The documents are the source of truth for "what we agreed on"; the user's live
instructions are always the final authority and can override the docs at any time.

Core Principles (never violate these)

1. User command > files > AI assumptions. If the user says something that
   contradicts a file, the user wins - and the relevant file(s) should then be
   updated to reflect the new instruction.
2. No silent additions. Never add features, tech choices, pages, tables, or
   rules the user did not ask for or approve. If something seems missing, ask -
   don't assume. Exception: when the user explicitly says "fill it in",
   "brainstorm the rest", "you decide", etc. - see Phase 3.
3. Design.md is special. NEVER fill Design.md with your own taste. Always ask
   the user for style direction (e.g. minimal, playful, corporate, dark mode,
   neumorphic, etc.) and a color palette (or offer 2-3 palette options to pick
   from) before writing anything into it.
4. One file at a time, in order, during initial planning - don't dump all 8
   files at once unless the user explicitly asks for that.
5. Tracker.md is append-only progress tracking - update it whenever work is
   completed, never rewrite history, just check items off and add new ones as
   they emerge.
6. Mid-project changes ripple. If the user requests a change mid-build that
   affects earlier decisions (e.g. "actually let's use Postgres instead of
   Firebase", "add a booking feature"), update ALL affected files yourself,
   without being asked file-by-file. Then summarize what changed.
7. Read before you write. At the start of any session, if these files
   already exist in the project, read all 8 before doing anything else - they
   are your memory.

The 8 Files

Workflow

Phase 0 - Detect intent

• ONLY for brand new projects. If project has existing code files, ABORT and do not use this skill.
• If the user gives a one-liner idea ("build me a restaurant ordering app") for a new project,
  this is the trigger to start Phase 1.
• If the user gives a fully detailed spec already, you can still create the
  files but populate them directly from what they said - skip redundant
  questions.

Phase 1 - PRD.md first

This is the foundation. Everything else depends on it.

• Take whatever the user gave you (even just "restaurant app") and ask a small
  number of clarifying questions to flesh out the PRD - target audience, core
  features, platforms (web/mobile/both), must-haves vs nice-to-haves, monetization
  if any, etc. Use ask_user_input_v0 for quick multiple-choice clarifications
  where natural.
• The user can also choose to skip Q&A and just write directly into PRD.md
  themselves - if they say "I'll fill it in", create a skeleton PRD.md with
  section headers and placeholders, and wait for them.
• Do not invent features. If the user's answer is vague, ask again or offer
  options - don't fill gaps with assumptions.
• Once the PRD feels solid, write PRD.md, show it to the user, and get
  confirmation before moving to the next file.

Phase 2 - Remaining files, one by one (except Design.md)

In this order: TechSpec.md → AppFlow.md → Schema.md → ImplementationPlan.md →
Rules.md → Tracker.md → Design.md (last, see Phase 2.5).

For each file:

• Propose a draft based on the PRD and any prior files, OR ask the user
  questions if there's a real decision to make (e.g. "Should this use
  PostgreSQL or a simpler option like SQLite/Firebase?").
• Show the draft, ask for confirmation or edits.
• Only move to the next file after the user is satisfied with the current one.

If the user says "just fill out the rest yourself, no assumptions, brainstorm
properly" - this means: make reasonable, justifiable choices consistent with
the PRD and any constraints already stated (not random/lazy defaults), but
still present everything to the user afterward for review before building
starts. "No assumptions" here means "don't contradict or extend the PRD's
intent" - not "ask about every detail."

Phase 2.5 - Design.md (always interactive)

Never write Design.md without asking the user:

• Overall style direction (e.g. minimal / modern / playful / corporate / retro /
  brutalist / glassmorphism / dark-first) - offer ask_user_input_v0 choices
  if helpful.
• Color palette - either ask for specific colors/hex codes, or offer 2-3
  palette options matching their chosen style and let them pick.
• Typography preferences, spacing density, any reference sites/apps they like.

Only after this input is gathered do you write Design.md.

Phase 3 - Final review

• Once all 8 files are drafted, present a short summary of the whole plan and
  ask the user to review everything (especially Rules.md - ask if they want to
  add any constraints, e.g. "no external libraries", "TypeScript only",
  "must work offline", etc.).
• Explicitly ask: "Anything to change before I start building?"

Phase 4 - Build

• Once the user confirms, begin implementation following ImplementationPlan.md
  step by step.
• As each step/task is completed, mark it done in Tracker.md (check it off,
  add a short note/date if useful).
• Never deviate from ImplementationPlan.md, Rules.md, TechSpec.md, or Schema.md
  without explicit user instruction.
• If the user gives a new instruction mid-build that isn't in the files:
  follow it immediately (user command is final), AND update the relevant
  file(s) afterward so the docs stay in sync. Briefly tell the user which
  files you updated and why.

Quick Reference: Decision Rules

• Ambiguous feature request → ask, don't assume.
• User explicitly says "you decide" / "brainstorm it" → make a reasoned,
  PRD-consistent choice, document it, present for review - don't silently bake
  it in.
• Conflict between user's current message and a file → user wins; then sync
  the file.
• Design.md → always ask style + colors first, no exceptions.
• Any completed task → update Tracker.md immediately.
• Mid-project pivot → update all affected files proactively, summarize changes.

Limitations

• Only works for new projects. Will fail if run on existing codebases.
• Relies heavily on accurate user input during the initial PRD generation.