Steal my agent rules.

# Agent rules: what runs alone, and what waits for a human

## Tier 1: agents just do it
Reading code, data and docs. Drafting. Running tests. Opening pull requests. Internal reports and summaries.

## Tier 2: agents do it, then it passes a gate
Publishing content, merging to main, deploying.
The gate is one of: an approval queue, a one-tap approve button, or an automated check the agent can't skip (tests, a link check, a scan test).

## Tier 3: only a human
Logins. Payments and refunds. Deleting data. Messaging someone new in my name. Changing DNS, billing or permissions. Anything that can't be undone.

## Keys
Agents never hold live payment keys, admin or service-role database keys, or my passwords. If a task needs one, the task stops and asks.

## Every agent, every time
- Read CLAUDE.md and CURRENT_STATE.md first.
- Say what you're about to do before you do it.
- Verify, then report. "Done" means checked.
- Report failures as plainly as successes.

# CLAUDE.md: read this before touching anything

## What this repo is
<One paragraph: what the product does, who uses it, where it runs.>
Live URL: <https://...>
How it deploys: <for example, every push to main deploys to production>

## Source of truth
- This file says how to work here. These rules beat habits.
- CURRENT_STATE.md says what is live, what is in progress and what is broken. Read it first. Update it last.
- If this file and the code disagree, stop and say so. Don't guess.

## Commands
- Install: `<npm ci>`
- Run locally: `<npm run dev>`
- Test: `<npm test>`
- Type-check and lint: `<npm run check>`

## Rules
1. Work on a branch named `agent/<short-task>`. Never commit to main.
2. One task per branch. One agent per repo at a time.
3. Open a pull request that says what changed, why, and how you checked it.
4. Never read, print or commit secrets. Refer to environment variables by name only (see `.env.example`).
5. Never run migrations, deletes or bulk updates against production data. Write them, then stop for a human.
6. Never send email, post publicly, charge a card or change DNS. Draft it, then stop.
7. If you're not sure something can be undone, treat it as if it can't.

## Definition of done
A task is done only when all of these are true:
- [ ] It works on a real run, not just in theory (command output, a screenshot or a live URL).
- [ ] Tests and type-check pass.
- [ ] You checked the result the way a user would: opened the page, clicked the button, read the draft.
- [ ] CURRENT_STATE.md is updated.
- [ ] The pull request lists anything you could not verify.

## When you get stuck
Stop after two failed attempts at the same fix. Write down what you tried, what happened and your best guess, then ask.

# CURRENT_STATE.md
Last verified: <YYYY-MM-DD> by <agent or person>

## Live
- <Feature>: <URL or entry point>. Verified <date> by <how: test run, live check, screenshot>.

## In progress
- <Task>: branch `agent/<name>`. Status: <where it stands>. Next step: <one line>.

## Known issues
- <What is broken>: <who it affects>. Workaround: <if any>. First seen <date>.

## Decisions (don't reopen these without a new reason)
- <Decision>: <why>. <date>

## Next
1. <The single most important next step>

# Weekly review prompt
Paste this into your agent every Monday. Fill in the <brackets> once.

You are reviewing last week for <project>. Use only real data from <analytics source>. If a number is missing, say so instead of estimating.

1. Plan vs shipped: list what last week's plan said and what actually shipped. Count both.
2. The numbers: <the 2-3 metrics that matter>, this week vs last week. Split paid from organic. Flag anything driven by ads, a promotion or a one-off spike.
3. What broke: anything that failed, quietly got worse, or needed a human. One line of root cause each.
4. One lever: the single change most likely to move the main number next week. One, not three.
5. Next week's plan: at most 3 tasks, each with how we'll know it's done.

End with a one-line verdict: on track, at risk or off track, and why.