---
name: anti-vibe-coding
description: |
  Enforces professional, intentional development mindset on every web coding
  task — preventing AI slop, unplanned code, and amateur security mistakes.
  TRIGGER when: user says "build this", "write a component", "add this feature",
  "create a function", shares code and asks to extend it, or starts any
  frontend or backend coding task.
  TRIGGER also when: user asks why their site looks generic, why code is
  breaking, or wants code reviewed for quality.
  DO NOT TRIGGER when: user asks a conceptual question with no code to write,
  requests non-web work like data analysis or writing.
---

# Anti-Vibe-Coding

Enforces the mindset and habits of a professional developer on every coding
task — eliminating reactive, unplanned, AI-slop-generating behavior.
Primary constraint: no code is written until its purpose, security boundary,
and reusability are explicitly confirmed.

## Core Rules

Rule: Never write frontend code without a wireframe or mockup existing first.
Why: designing inside code using random utility classes produces inconsistent
padding, visual misalignment, and a generic template look that cannot be
fixed by tweaking CSS after the fact.

Rule: Never hardcode color values, pixel sizes, or config variables inside
component files. Why: hardcoded values break global theming and force edits
across dozens of files for a single brand change — one CSS variable change
should be enough.

Rule: Never connect a frontend framework directly to a database. Why: this
leaks credentials to the browser, bypasses backend security rules, and
exposes the entire database schema to anyone who inspects network traffic.

Rule: Never store auth tokens in browser local storage or session storage.
Why: any cross-site scripting attack can read these stores freely — stolen
tokens grant full account access with no further credentials needed.

Rule: Always declare pointer cursor on every custom clickable element. Why:
missing pointer cursor is the clearest visual marker of AI-generated UI —
it makes custom buttons feel broken and signals the interface was not
reviewed by a human.

Rule: Never animate UI elements with linear transitions. Why: linear motion
looks mechanical and robotic — ease-in-out transitions simulate physical
velocity and make motion feel natural and intentional.

Rule: Never create a state effect hook without a precise dependency list.
Why: an undefined dependency list runs on every render and triggers infinite
loops that crash real browsers under normal user load.

Rule: All state must flow in one direction — from parent to child. Why:
circular state creates unpredictable re-renders and makes the codebase
impossible to debug as it grows.

## Patterns

**Correct — security boundary respected:**
  User clicks "Export PDF" → frontend calls backend API endpoint →
  backend generates PDF and returns file → frontend downloads it.
  Credentials never leave the server.

**Incorrect — vibe coding breach:**
  User clicks "Export PDF" → frontend calls database directly using
  client SDK → credentials exposed in browser network tab.

**Correct — state is traceable:**
  Form input updates a single grouped state object.
  One state update, one re-render, dependency list is explicit.

**Incorrect — fragmented state causes loops:**
  Every form field has its own independent state hook.
  Parent state updates trigger child effects with no dependency list.
  Browser freezes under normal typing speed.

**Correct — intentional animation:**
  `transition: all 0.3s ease-in-out` on button hover with upward scale.
  Motion feels physical — accelerates in, decelerates out.

**Incorrect — vibe animation:**
  `transition: all 0.3s linear` — motion feels robotic and mechanical.
  No hover scale. Default arrow cursor on a custom button div.

## Pre-Code Checklist

Before writing any function, component, or route, answer all four. If any
answer is "I don't know", resolve it before writing a single line.

- [ ] Where is the security boundary? Frontend displays only. Backend runs all logic.
- [ ] Is this component reusable? If yes, build it generically, not inline.
- [ ] Are colors and styles variable-mapped? No hardcoded values anywhere.
- [ ] Will this state update cause circular side-effects? Trace the data flow first.

## Decision Guide

| Situation | Correct action | Why |
|-----------|---------------|-----|
| About to hardcode a color value | Declare it as a root CSS variable first | One variable change must update the entire UI |
| About to call database from UI file | Route through backend API layer | Credentials must never reach the browser |
| About to write a component for the second time | Abstract the first into a reusable shared component | Duplication is the primary driver of unmaintainable frontends |
| About to write an effect hook without deps | Map exact dependencies before writing | Undefined deps runs on every render and causes loops |
| Site looks generic after coding | Identify root cause: no wireframe or mockup was built first | Visual decisions made in code always produce template aesthetics |

## What Not To Do

- Do not accept AI-generated code without reading every line. AI defaults to
  the most common, most generic pattern — without constraints it produces slop.

- Do not treat "it works" as done. Working code with open database connections,
  local storage tokens, and hardcoded values is not production-ready.

- Do not add glassmorphism or micro-interactions before security boundaries
  and component architecture are solid. Visual polish is finish work — it
  is never the first step.

- Do not design inside the code. If no wireframe exists, stop and make one.
  Even a rough grayscale sketch on paper prevents the generic layout problem.