How to use Claude Code as a founder

Write your standing rules once, and Claude reads them at the start of every session.

You stop repeating the same instructions in every chat.

Steps to copy

1. Open your project in Claude Code and type /init for a first draft of the rules file.
2. Rewrite it in four parts: who you are, how to answer you, when to ask, what never to do.
3. Give every rule a date and a one line reason.
4. Add a new rule the second time you correct Claude on the same thing.

Every key your tools use lives in one hidden file, never in a chat message.

A key works like a password for a service you pay for. Anyone who finds it can run up your bill or read your data. A key pasted into a chat or saved in a public project is already out.

Steps to copy

1. Know the words. An API key is a password a service gives your software.
2. The .env file holds those keys.
3. .gitignore lists the files git never saves or uploads.
4. Ask Claude to create the .env file, move every key into it and add .env to .gitignore. The prompt below does this in one go.
5. When a service shows you a key, paste it into the .env file yourself, never into the chat.
6. If a key ever lands in a chat or a public project, make a new one at the service and delete the old one. Deleting the message is not enough.

Set up this project so no password or API key can leak.
1. Create a file named .env in the project root for every key and password, one per line as NAME=value, and tell me which values you need from me.
2. Add .env to .gitignore so git never saves it, and check that it is not already in a past commit.
3. Change the code so it reads keys from .env instead of holding them in files.
4. Search every file for anything that looks like a key or password and list the file names, without printing the values.
5. Add a check that runs before every commit and blocks it when a file holds a key.

Make Claude open with the result, then what needs you, then what comes next.

You see at once whether the work landed, and you never hunt through a long reply for your part.

Steps to copy

1. Add a rule: every reply opens with the outcome.
2. Name three labelled blocks after it: Info, Needs you and Next.
3. Ask for decisions as a numbered list, one decision per number, with the recommended option marked.
4. When a reply breaks the shape, point at the rule and ask again.

Finish one project before the next one starts, and approve a plan before any job with three or more steps.

Fixing a plan is cheaper than fixing finished work.

Steps to copy

1. Keep a ranked list of projects and work only the top one until it is closed.
2. Paste long notes as background, ask for a short phased list back, then set the order yourself.
3. Ask for a plan first and read it before anything changes.
4. When the results start to drift, say stop and ask for a new plan.

Start a fresh chat before a long one gets heavy, and carry the work over in a saved handoff file.

Long chats get summarized, and details you needed can go with the summary.

Steps to copy

1. Type /context now and then to see how full the current chat is.
2. At your own threshold, finish the item and ask for a dated handoff file.
3. Type /clear for an empty chat and send one line: read the handoff file first.

Plans and final judgment stay with the strongest model. Searches, edits and checks go to helpers on cheaper models.

You pay top rates only for the work that needs judgment.

Steps to copy

1. List the jobs that need judgment: plans, final reviews and anything a customer will see.
2. Give each helper one task and a cap on its answer, such as "reply in at most ten lines".
3. Write helper instructions for someone with zero context: exact files, exact steps, how to decide edge cases.
4. Before you act, have the main chat recheck the one finding your decision rests on.

Done means the checks ran and passed, with their output in the reply.

An AI saying done often means the text exists and no check has run.

Steps to copy

1. Before work starts, list what done means as items you can tick.
2. Ask for the check output in every reply that says done. No output means not done.
3. When something breaks, ask for the cause first, then fix the cause.
4. Close every review finding before you publish, or write down why it stays open.

Log each mistake as a dated rule the same day, and link every task to a brief.

The same mistake rarely costs you twice.

Steps to copy

1. After any correction, have Claude add one dated line to a lessons file: what went wrong and the new rule.
2. Keep one line per task, each linked to a brief with goal, reason and evidence.
3. Give every parked item a trigger to come back: a date, a number or an event.
4. Open and close every session the same way: read the list, work the top item, update the list.