Coding Agent Discipline Kit

# [PROJECT NAME]

## Project Overview
[One paragraph: what this project is, who uses it, where it's deployed.]

**Domain**: [yourdomain.com]
**Deployment**: [Vercel / Railway / Fly / etc.]
**Repository**: [URL]

---

## IMPORTANT RULES

### 1. Task completion
A task is NEVER complete until [your bar — pushed, deployed, tested in staging, etc.]. Always verify before declaring done.

### 2. No emojis
Do not use emojis in code, comments, commit messages, or user-facing text.

### 3. Read before write
Before changing a file, read it fully. Before adding a function, search the codebase for an existing one. Never generate code based on an assumption about what the codebase looks like.

### 4. Minimal diff
Touch only the files necessary for the task. Do not refactor surrounding code, rename variables, or reformat. List cleanup ideas separately — don't bundle them into the diff.

### 5. No fallbacks for impossible cases
Trust internal code. Only validate at system boundaries (user input, external APIs, untrusted data). Don't add try/catch to silence an error — find the root cause and fix it.

### 6. No comments unless they explain WHY
Default to no comments. Add one only when the WHY is non-obvious — a hidden constraint, a workaround for a specific bug, a subtle invariant.

---

## Tech Stack
[Frontend / Backend / Infrastructure — framework, language, styling, state, database, hosting.]

## Conventions
[Naming, imports, tests, commit style.]

## Commands
- Dev / Build / Typecheck / Test / Lint / Deploy: [commands]

## Project Structure
[Tree — top two levels of the source tree.]

## What "Done" Means
- [ ] Code changes match the planned scope
- [ ] Typecheck passes
- [ ] Tests pass (or new tests added if behavior changed)
- [ ] Manually verified [in browser / via curl / etc.]
- [ ] Committed with a meaningful message
- [ ] Pushed (deploy trigger, if applicable)

## Things to NEVER do
- Push without verifying the build
- Skip pre-commit hooks to force a commit through
- Run destructive git operations without confirmation
- Add features or abstractions beyond what the task requires
- Create a new file when an existing one would do

Before writing any code: list every file you need to read to understand this task, read each one fully, then state back in 3-5 bullets what you understood — what the existing code does, what convention you're following, and where the change goes. Wait for confirmation before writing code. If you're guessing instead of reading at any point, stop and say what you'd need to read.

Don't write code yet. Read the relevant files, then produce a plan: files to change (path — what changes), files to create (path — purpose), a 2-4 sentence approach, and any risks or open questions. Wait for a go-ahead before writing code. If the task turns out to be bigger or different than described once you've read the files, say so before planning.

Make the smallest change that solves the problem. Touch only necessary files. Don't refactor surrounding code, rename variables you think are misnamed, "improve" formatting, or add error handling for cases that can't happen. Don't add comments unless they explain a non-obvious WHY. If you see something worth cleaning up, list it separately at the end — don't fold it into the diff. Show the diff and wait for confirmation before applying.

Before saying you're done: run the typechecker and paste the result; run the test command for the affected module and paste the result; if it's a UI change, open the dev server and describe what you see; if it's an API change, hit the endpoint and paste the response; if it's a database change, run a query that proves it. If any step fails, fix the root cause — don't skip the step or rationalize past it. Only then call the task complete.

When you hit an error or unexpected state: find the root cause, don't hide it. Don't add try/catch just to silence an error, don't add fallback values for cases that shouldn't happen, don't add compatibility shims or underscore-prefix unused variables, don't validate internal data you already control. If something's broken, surface it — the fix is to fix it, not hide it. Only validate at real system boundaries: user input, external APIs, untrusted data.

Look at the staged diff. Write a commit message in imperative mood ("Add", "Fix", not "Added"), title under 72 characters, describing WHY the change was made rather than restating the diff. If unrelated changes are staged together, suggest splitting into separate commits. No emojis. Output only the message.

Look at the diff and every commit between this branch and main. Write a PR description with: a Summary (2-4 bullets on what this delivers), a Why (1-2 sentences on the motivation), a What Changed section grouped by area, a Test Plan checklist, and a Risks section (reviewers should pay attention to — "none" is fine if true). Be specific about file paths and behavior, skip generic boilerplate.

I'm debugging: [describe the bug, paste relevant code/logs]. Don't suggest a fix yet. Walk through: what the code is supposed to do, what's actually happening based on the evidence, where exactly the divergence happens, why it diverges (the underlying mechanism), and three possible causes ranked by likelihood with what would distinguish between them. Once I confirm your read of the situation, then suggest the fix.

I'm choosing between [Approach A] and [Approach B] for [problem]. Give me a table comparing implementation cost, long-term maintenance, performance impact, reversibility, and failure modes. Then pick one explicitly, state the deciding factor in one sentence, and name what would change your mind — under what conditions the other approach wins. Don't hedge, don't say "it depends."

I'm designing [system/feature]. Walk through it senior-style: the problem in one sentence, hard constraints and assumptions, the simplest possible design (not the right one — the dumbest one that could work), specifically where and how that design breaks, the next iteration and what new failure mode it introduces, then stop — don't jump to microservices, queues, or sharding unless the prior steps actually required them. End with open questions and a one-paragraph summary of the chosen architecture and why.