148 lines
7.0 KiB
Markdown
148 lines
7.0 KiB
Markdown
---
|
|
name: not-a-vibe-coder
|
|
description: Turns vague prompts into 8 structured planning files for brand new projects. DO NOT use on existing codebases.
|
|
risk: critical
|
|
---
|
|
|
|
# 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
|
|
|
|
| File | Purpose |
|
|
|---|---|
|
|
| PRD.md | What the app does, features, goals, user requirements |
|
|
| TechSpec.md | Architecture, tech stack, APIs, database choices |
|
|
| AppFlow.md | User flows and navigation |
|
|
| Design.md | UI/UX guidelines, layout, style, color palette |
|
|
| Schema.md | Database tables, relationships, data models |
|
|
| ImplementationPlan.md | Step-by-step development roadmap |
|
|
| Tracker.md | Completed work, pending tasks, progress |
|
|
| Rules.md | Coding standards, constraints, project rules |
|
|
|
|
## 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.
|