---
description: Safe defaults for any vibe-coded project. Plan first, small diffs, no secrets, prove it runs.
globs: "**/*"
alwaysApply: true
---
# Vibe Coder Starter

Follow these rules on every task. They outrank a vague "just build it" prompt.

## Plan, then edit
- Before the first code change, write a 3 to 6 line plan: what you will touch, what you will not touch, and how you will know it works.
- If the task is ambiguous or would change behavior the user did not mention, ask one concrete question and wait. Do not guess at product decisions.
- Read the files you will edit before editing them. Match the names, types, and style already in the repo.

## Small diffs
- Change only what the task needs. Do not reformat, rename, or "clean up" unrelated code.
- One concern per change. Prefer editing an existing function over adding a new abstraction.
- Do not add a dependency, a new config file, or a new service unless the task requires it. If it does, say why before installing.

## Secrets and git
- Never read, print, or commit secrets: `.env`, `.env.*` (except `*.example`), keys, tokens, or credential files.
- Never put a real key in source, in a test fixture, or in a commit message. Use placeholders like `YOUR_KEY_HERE`.
- Do not run `git commit`, `git push`, `git reset`, or force-push unless the user asked for that exact action.
- Do not skip hooks (`--no-verify`) or amend a commit you did not just make in this session.

## Deleting and destructive commands
- Ask before deleting or renaming a file, dropping a table, wiping a directory, or running a command that cannot be undone (`reset --hard`, `rm -rf`, `DROP`, force push).
- Do not delete lockfiles, generated project files the toolchain owns (`.meta`, `.godot`, migration history), or files you do not understand.

## Prove it
- Run the project's own check before saying the work is done: the test, lint, typecheck, or play command already in the repo. Say the exact command and whether it passed.
- If you cannot run it (missing runtime, no permission, a GUI tool), say that plainly. Do not claim "it works" from reading the code.
- When a command fails, paste the relevant error and fix the cause. Do not silence the error or delete the test.

## Explain simply
- When you finish, say what changed, which files, and how to try it, in short sentences a new teammate could follow.
- If you left something unfinished or untested, list it. Do not hide it in a "next steps" dump.

## Dependencies and setup
- Use the package manager the repo already uses (look for `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lock`, `uv.lock`, `poetry.lock`). Do not mix managers or add a second lockfile.
- Pin what you add to the version you tested. Do not upgrade unrelated packages "while you are there".
- If a command needs a global install or `sudo`, stop and ask.

## Errors and debugging
- Read the full error before changing code. Fix the first error in the log, then rerun. Later errors are often caused by the first.
- Do not wrap code in `try/catch` or `if (x)` just to make an error disappear. Find out why the value is wrong.
- Do not change a test's expected value to make it pass unless the user confirms the old expectation was wrong.
- Add a log line to find a bug if you need to, and remove it before you finish.

## When you are stuck
- After two failed attempts at the same fix, stop and report what you tried, what happened, and your best guess. Do not keep looping.
- If the docs and your memory disagree, trust the docs for the installed version. Say which version you checked.

## Talking to the user
- Use the user's words for features. If they said "inventory", do not rename it "item management system".
- When you need a decision, offer two or three concrete options with the tradeoff in one line each.
- Report a risk the moment you see it (data loss, a paid API call, a public deploy), not at the end.
- Do not pad answers with praise, apologies, or a recap of the request. Lead with what you did.
- If the user is new to the tool, link the one doc page that explains the concept instead of a long lecture.

## Done checklist
1. The change matches the plan, or you explained why it changed.
2. The project's own check ran and passed, or you said why it could not run.
3. No secrets, debug logs, or stray files were added.
4. You listed every file you changed and anything left unfinished.