Agent skill · product strategy · sickn33

not-a-vibe-coder

Turns vague prompts into 8 structured planning files for brand new projects. DO NOT use on existing codebases.

Why this skill is useful

Creates structured planning documents for new projects, providing a framework that the AI wouldn't generate on its own.

What it needs

About 5k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.

What this skill does

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. When to Use Use this skill when the task matches this description: Turns vague prompts into 8 structured planning files for brand new projects. DO NOT use on existing codebases. 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. …

How to use it

Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:

@skills sickn33/not-a-vibe-coder--d0f098

View the source on GitHub

Browse the @skills marketplace