1
IF I CLICK IT, SOMETHING SHOULD HAPPEN
Meaningful actions need obvious feedback. A tiny click deserves a tiny response. A major action can celebrate with stronger movement, clarity, or reward.
WHY COW RULES EXISTS
WE SHOULD NOT HAVE TO EXPLAIN THE SAME FUCKING PRINCIPLES IN EVERY PROMPT.
Cow Rules is the concise, practical source for recurring Ideas Shed operating principles. It helps the next build benefit from what earlier builds already taught us.
Will this lesson make the next build better?
If yes, it probably belongs in Cow Rules.
Future prompts should usually need only: Follow Cow Rules.
The build stamp above is the current version and last-updated record. Read the machine-readable rules →
THE COW RULES
2
DON'T MAKE HUMANS HUNT
Avoid forcing people to remember random folders, threads, or versions. The current destination should be obvious every time.
3
ONE OBVIOUS CURRENT VERSION
Publishing once should mean one clear current live build. If the user refreshes, they should get the latest version without cache games.
4
CHAT THINKS. WORK BUILDS.
Use chat for discovery, strategy and critique. Use WORK for implementation, execution, deployment and delivery.
5
HUMAN NAMES BEAT SYSTEM NAMES
People should read names that describe meaning, not only IDs, slugs, or generated system labels.
6
DON'T ADD ANOTHER BLOODY TOOL UNLESS IT HELPS
Before adding another platform, check: can the existing product do this simply and reliably right now? Never simulate an integration, payment, AI feature, delivery, account, file or trust signal. If it is not implemented, say so.
7
AI PROPOSES. HUMAN DECIDES.
The machine can lower cognitive load, but humans keep final judgement. Suggest, approve, change and ignore as needed. Do not silently rewrite, classify, discard, publish, replace, approve or finalise important human work.
8
REWARD COMPLETION
Finishers should feel it. Use concise celebration, progress marks, and clean transitions when work lands.
9
DOGFOOD BEFORE THEORY
Build for the person using it first, then simplify from what that person actually says is annoying. Do not secretly prepopulate, solve or polish away the real founder journey; honest friction teaches us something.
10
SIMPLE FIRST. CLEVER LATER.
If a simple, reliable version ships, ship it. Skip sophisticated automation until one simple path is already obvious. Do not make an early product carry marketplaces, enterprise permissions, speculative integrations or mature-company architecture before it earns them.
11
DON'T TEACH THE HUMAN TO BE THE MACHINE
Ask one question: does this complexity actually help the human understand, or just make the human keep up with tooling?
12
DON'T GUESS WHEN YOU CAN LOOK
If the answer exists in the system in front of you, inspect it before inventing an explanation.
Don't confidently guess which deployment is live, which domain is registered, which account contains something, whether a setting exists, or what state a system is in when you can check.
Look first. Reason second. Act third.
Don't make the human correct something the machine could have checked itself.
13
STAMP EVERY SHIP
Every successful published build should visibly show its build number, date, local time and timezone.
Example:
BUILD 4 · 17 AUG 2026 · 13:42 EAT
The timezone should follow the user's current local/device timezone rather than being hard-coded.
Only update the stamp after a successful publish.
If the build did not ship, the stamp does not change.
The purpose is simple:
Am I looking at the bloody thing we just built — and when did it actually ship?
14
DON'T MAKE THE HUMAN ASSEMBLE THE ANSWER
If the intended next action is one usable thing, give the human one complete usable thing.
Do not make them combine:• an original prompt• three later corrections• an extra instruction• something mentioned ten messages ago• and a final missing detail
The machine already has the context.
Use it.
If the human needs one complete implementation prompt, give one complete implementation prompt.
One copy. One action.
This is closely related to DON'T MAKE HUMANS HUNT. But it addresses a specific AI behaviour: forcing the human to reconstruct an answer that the AI could have assembled itself.
15
DON’T TELL ME THE TANK IS FULL IF THE TRACTOR ISN’T ALLOWED OUT OF THE SHED
Software should show the user the usable truth, not just a technically correct number.
If a feature is unavailable because of capacity, limits, credits, quotas or another restriction, say that clearly.
Do not show something like:
100% remaining
if the user may still be unable to use it without also explaining why.
The user should be able to understand:• what they have left• whether they can use it now• what is stopping them if they cannot
Do not make the user work out internal quota systems or technical limits.
If an action has a material AI, API or processing cost, explain the allowance clearly and warn before unusually expensive work. No deliberately confusing credits.
Honesty and transparency build trust.
Pink Cow version:
🐄 “Don’t tell me the tank is full if the tractor isn’t allowed out of the shed.”
16
MAKE IT EASY TO TELL US WHEN SOMETHING IS SHIT
If a user is frustrated, confused, blocked or thinks something is broken, give them an obvious way to say so.
Do not make feedback difficult to find.
Do not hide it behind support pages, menus or long forms.
Put feedback controls near the place where the problem happens.
Useful examples:
THIS DIDN’T WORK
THIS IS CONFUSING
REPORT A PROBLEM
SEND FEEDBACK
Keep feedback quick and simple.
Where the same issue is being reported by many users, acknowledge it clearly.
Show that the feedback has been heard.
Where practical, show:• known issues• issues being investigated• fixes made because of user feedback
Do not let feedback disappear into a black hole.
Users should be able to see that the product is listening.
In an early beta, make it easy to reach the person building it where that is useful. Do not pretend that person is an expert when they are not.
Pink Cow version:
🐄 “If everyone is mooing about the same broken gate, perhaps have a look at the gate.”
17
MATCH THE INSTRUCTION TO THE INTELLIGENCE
Different AI models need different kinds of instructions.
Do not give a smaller, faster model a long strategy brief when it only needs a clear work order.
For junior coding models such as Spark or Mini:
• keep prompts short• tell them exactly what to build• give exact copy where needed• give one clear outcome• remove unnecessary explanation• avoid asking them to make product or architecture decisions unless necessary
Use stronger models for work that genuinely requires deeper reasoning, ambiguity, architecture or judgement.
Match the instruction to the intelligence. Don’t give the junior Cow a strategy memo when what she needs is a work order.
🐄 “Small tractor. Clear job. Off you go.”
18
IF IT FAILED, SAY IT FAILED
If something fails, say it failed.
Do not show animation that implies work is happening when nothing is happening.
If progress says 37%, it should correspond to something real.
Say whether the work can recover, whether it needs to restart, or whether the system simply does not know.
Do not make semantic claims unless real semantic analysis happened. Deterministic facts such as counts, dates and validation results are not proof that the AI understood the work.
Never optimise the appearance of success at the expense of the truth.
19
MAKE THE SOFTWARE COME TO THE HUMAN
Do not automatically solve every problem by creating another website, app or dashboard people must remember to visit.
Ask whether the software can appear where the work already happens: in a folder, a menu bar, an existing workflow, a useful notification or the right conversation.
Work with useful tools people already use, including their own AI, documents, email and spreadsheets. Do not create lock-in merely to make the product feel bigger.
Remove another destination when you can. Do not remove a consequence the human needs to understand.
20
CONVERSATION FIRST. STRUCTURE SECOND.
Where natural-language capture is practical, let the human talk, type naturally, paste or upload. Structure the information behind the scenes.
Do not force a user to think like a database. Use explicit fields when precision, comparison, legal, payment or security requirements genuinely need them.
21
FREE SHOULD BE GENUINELY USEFUL
If it costs us almost nothing to provide, do not deliberately cripple it just to manufacture a subscription.
Charge where real variable cost appears, such as LLM usage, transcription, generation, heavy processing or paid external services. Be commercially sensible and unusually honest.
22
NEVER HOLD USER WORK HOSTAGE
Cancelling, downgrading, pausing or stopping payment should turn off paid capability, not erase the human's core work.
Wherever reasonably possible, their ideas, writing, sources, designs, relationships and project data remain available and exportable.
23
VERSION CREATIVE WORK
Do not destroy a good earlier version just because a newer one exists.
Creative work branches. Preserve useful history and make restore, compare, duplicate or branch-from-earlier possible when the work matters.
24
ONE SOURCE OF TRUTH
If two product areas depend on the same underlying fact, store it once. Do not create parallel settings that can quietly contradict each other.
Identity, pricing, entitlements, edition specifications and deployment source all need one authoritative home.
25
HUMAN WORK IS NOT A CONVEYOR BELT
Do not force a rigid linear workflow onto work that naturally moves between thinking, research, writing, design, planning and editing.
Stages may help people orient themselves. Do not turn them into prison cells.
26
MOBILE IS FIRST-CLASS
Do not design desktop first and squash it onto a phone. Where the task makes sense on mobile, deliberately support readable type, generous tap targets, useful navigation and no horizontal overflow.
Marcus often uses an iPhone. That is a real use case, not an edge case.
27
PRESERVE THE BRAND. RESPECT THE SCOPE.
Once identity, palette, typography, mascot, tone or navigation is agreed, do not casually redesign it during a functional change.
If the task is to fix auth, fix auth. Do not redesign the homepage while you are there.
28
FIX FOUNDATIONS PROPERLY
Prefer fixing a misconfigured foundation over burying an avoidable workaround underneath the product.
Temporary workarounds are acceptable only when necessary, safe, documented and clearly marked for cleanup.
29
KEEP THE PLUMBING DOWNSTAIRS
Customers use the product, not its providers. Keep database jargon, raw API messages, stack traces and provider names behind the product unless they genuinely help the customer.
Errors should explain what happened, what it means and what the human can do next in plain language.
30
GITHUB IS AUTHORITATIVE FOR PRODUCTION CODE
Every production deployment should map to committed source code in the authoritative repository.
Do not reconstruct production from deployment artefacts, generated output or a stale local folder. If the authoritative repository is unclear, resolve that before risky production work.
31
TEST IN PROPORTION. PRESERVE WHAT WORKS.
A small scoped change needs scoped checks. A major product or architecture change needs broader validation.
Understand what already works and preserve user data, URLs, authentication, flows, brand and integrations unless the task explicitly changes them. Quality is not an excuse for waste; speed is not an excuse for breakage.
32
PRIVACY AND OWNERSHIP ARE REAL BOUNDARIES
Treat user work as private by default. Enforce ownership in the database, API and storage, not merely by hiding links in the interface.
Do not expose one user's content to another or include private work in notifications unless it is genuinely necessary.
33
NO DARK PATTERNS
No hidden cancellation, pre-ticked consent, false urgency, forced marketing, misleading trials, confusing upsells or account-deletion traps.
Commercial does not have to mean slippery.
34
PRODUCT COPY TELLS THE TRUTH
Do not overclaim with words such as seamless, revolutionary, effortless or AI does everything. Say clearly what the product does, what it does not do and where uncertainty remains.
Keep it plain, warm, specific and occasionally funny. Humour sits on top of competence.
35
MAKE THE NEXT ACTION CLEAR
After onboarding, generation, signup, upload or publishing, the human should know what to do next.
Do not leave the continuation hidden below the fold or stranded behind an unexplained state.
36
FOLLOW COW RULES. DON'T PASTE COW RULES.
Future build prompts should normally be able to say Follow Cow Rules. Marcus should not have to paste the same principles repeatedly.
Repeat a rule only when it is central to the task, genuinely ambiguous or needs task-specific interpretation. Cow Rules records how we build, not everything we have ever thought.