Write your rules file
Twenty lines that stop you repeating yourself in every prompt for the rest of the course.
Every tool reads a plain-text file of standing instructions. Claude Code reads CLAUDE.md, Cursor reads .cursorrules, and most others read something similar. Check which yours uses, then create it in the root of your project.
six useful parts
# Habit Tracker
A tiny app for building
daily habits.
## What it does
- Create daily habits
- Mark them complete
- Track your streak
## Live demo
[Open the app](https://...)
## Run locally
npm install
npm run dev
## How to use it
1. Add a habit
2. Check it off daily
3. Watch the streak grow
## Decisions
- Local storage for v1
- No login yet
- Mobile-first layout
Habit Tracker
A tiny app for building daily habits.
What it does
- • Create daily habits
- • Mark them complete
- • Track your streak
Live demo
Run locally
$ npm install
$ npm run dev
How to use it
- 1. Add a habit
- 2. Check it off daily
- 3. Watch the streak grow
Decisions
- • Local storage for v1
- • No login yet
- • Mobile-first layout
Title + one line
README anatomy
Tell someone what the project is before they have to search for clues.
remember
A README is the front page of your project. Someone should understand what you built, how to run it and where to try it without reading the code first.
A good README answers the reader’s first questions before they open the code.
Keep it short, ideally twenty to forty lines. It is loaded into context on every request, so a long rules file costs you every time and takes up space that could be used for the task itself.
Write rules that are checkable. "Use clean code" is not a rule; nothing is falsifiable. "Two-space indent, no semicolons, no CSS framework, plain HTML and CSS only" is a rule, and you can tell at a glance whether it was followed.
Cover four things: the stack you are using and what you have banned, your formatting conventions, how you want assumptions handled, and anything the tool has already got wrong more than once. That last category is often the most useful because your rules file should grow from problems you have actually seen.
Add one line that will save you repeatedly: "If a requirement is ambiguous, ask me before writing code." Models default to guessing, and a guess costs you a whole generation.
Then test it. Ask for something that would break one of your rules and see what happens. If the tool still gets it wrong, rewrite the rule so there is less room for interpretation and try again.
Build this in your own editor
This one runs on your machine rather than in the browser workbench. Work to the outcomes below, then come back and mark it complete.
You should now be able to
- Write a rules file your tool actually reads
Loading…