Most people are trying to write better prompts.

Wrong layer.

The real advantage is knowing which model to use, what context to give it, what to remove, what to automate, what to verify, and when to stop asking AI altogether.

Here are the rules :

1 · Intelligence Allocation

1. The One Giant Prompt to Fable 5 Rule.
For a genuinely hard problem, don’t drip-feed Fable 5 twenty tiny messages. Give it the problem, outcome, constraints, relevant context, files, uncertainties, and what success looks like in one serious opening brief. Your first prompt frames almost everything that follows.

2. Buy the framing from Fable.
Use the most capable model when the problem itself is still unclear. Once the problem has been framed correctly, you often don’t need to keep paying the smartest brain in the room.

3. Hand execution down to Opus.
Let Fable decide what matters. Then move the same work to Opus on High and let it carry the execution.

4. The Senior Lawyer Rule.
You don’t hire a senior lawyer to format the PDF after the legal strategy is settled. Treat expensive intelligence the same way.

5. Opus is the daily-driver layer.
Most serious knowledge work does not need the absolute top model every single turn. Use the expensive tier when the decision deserves it.

6. Small jobs deserve small models.
Grammar, extraction, formatting, summaries, cleanup, file reading: stop burning frontier intelligence on clerical work.

7. Haiku is for speed.
When the task is basically “read this and report what you found,” speed often matters more than deep reasoning.

8. Sonnet is for execution.
If the thinking has already happened and the remaining job is drafting or transformation, move down.

9. Effort is a budget.
Max for the problem that could cost you weeks if framed incorrectly. Low for the sentence you want shortened.

10. High is a sane default for serious work.
You do not need Max because the task feels important. Use it because more reasoning has a credible chance of changing the answer.

11. Pick before entering Cowork.
Cowork can lock the model for the session. Choosing badly at the beginning means paying for that mistake throughout the run.

12. Learn the intelligence ladder once.
Haiku → Sonnet → Opus → Mythos/Fable. Stop treating model names like random menu options. They are different economic layers of cognition.

13. Model choice usually matters before prompt polish.
A brilliant prompt cannot manufacture reasoning capability that the model does not have.

14. Check the model selector every time.
Claude remembers what you used last. One careless click and you’re buying frontier reasoning for a grocery list.

15. Expensive models become expensive faster inside long chats.
The model keeps rereading the thread. Your harmless little follow-up is not necessarily priced like a harmless little follow-up.


2 · Prompt for the Actual Outcome

16. Never prompt for the artifact when you actually care about the outcome.
“Write a follow-up email” is weak. “Get these two overdue invoices paid without destroying the client relationship” tells the model what game it is playing.

17. State what winning looks like.
If you don’t define success, the model optimizes for producing something that looks complete.

18. Put the decision before the deliverable.
First decide what should be said. Then write the email.

19. Your first sentence should answer the question.
Tell Claude: “Start with what happened, what you found, or what you recommend.” Methodology comes after usefulness.

20. Stop asking leading questions.
Finish with “right?” and you have quietly told the model which answer would make you happy.

21. “Maybe?” is still steering.
Tiny linguistic cues can turn analysis into agreement.

22. Neutral prompts produce more useful disagreement.
Ask what the evidence supports, not whether your theory is correct.

23. Drop “think step by step.”
Modern reasoning models already reason. Adding ritual phrases does not automatically create better judgment.

24. Give it a useful professional lens instead.
“As a reliability engineer” changes what the model notices. “Think harder” mostly changes how long it sits there.

25. Roles should change the lens, not inflate the ego.
“World-class genius marketer” is cosplay. “CFO reviewing the assumptions behind this forecast” changes the work.

26. Three hard rules beat twelve decorative ones.
Models quietly lose constraints when you pile too many into one instruction.

27. Split complex standards into passes.
Create first. Audit against rule set A. Then audit against rule set B.

28. Examples are powerful enough to become dangerous.
Show the model five examples and it may stop exploring beyond those five examples.

29. Use examples when imitation is the goal.
Do not use them automatically when originality is the goal.

30. The Anti-Bullshit Rule.
Add: “Only report work you can point to evidence for. If something isn’t verified, say so.”

31. Never accept “done” without evidence.
If the model claims it checked fifteen things, ask where each result came from.

32. Declare your mode.
“I am thinking out loud. Do not create anything yet.” This prevents an eager model from solving the wrong stage of the problem.

33. Declare autonomy too.
“Handle this end-to-end. Interrupt me only for irreversible decisions.” Different task, different operating mode.

34. Give AI permission to stop thinking.
“When you have enough information to act, act.”

35. Demand a recommendation.
A cemetery of seven alternatives is often overthinking disguised as thoroughness.

36. Tell it what bad looks like.
“Never write like this:” followed by real text is more useful than “make it punchier.”

37. Negative examples create sharp boundaries.
An adjective is vague. Something you genuinely hate gives the model a line it can see.

38. Edit the poisoned prompt instead of arguing with the poisoned answer.
If the model misunderstood you, go back and fix the instruction where the error entered the conversation.

39. Stop accumulating correction debris.
Ten messages of “no, not like that” leave the model negotiating with ten previous mistakes.

40. Batch related asks.
“Summarize this, extract the key points, identify the disagreement and suggest a headline” is usually cleaner than four separate context reloads.

41. Open every citation.
A reference that looks academic can still be invented.


3 · Make the Model Question You

42. The first answer should sometimes be a question.
For ambiguous work, Claude should interrogate the brief before pretending it understands it.

43. Use AskUserQuestion before important execution.
Tell it to gather whatever context materially changes the answer first.

44. Click the obvious answers. Dictate the nuance.
The options handle structure. Your custom answer carries the reality.

45. Give it the goal and the success threshold.
“I need X for Y. I consider Y achieved when Z happens. Ask me what you need before starting.”

46. Make it propose strategies before committing.
Three genuinely different approaches expose assumptions you would otherwise never see.

47. The question the AI asks you can be more valuable than the answer it gives you.
A strong collaborator notices missing information before executing.


4 · Context Is a Weapon. Stop Spraying It Everywhere.

48. Fewer global settings can produce better thinking.
Every permanent instruction becomes invisible pressure on every future answer.

49. Delete permanent instructions you don’t actually need everywhere.
Context that belongs to 10% of your work should not contaminate 100% of your conversations.

50. Memory is useful only when the memory is useful.
Old context does not become relevant merely because the system remembers it.

51. Clean chats have value.
Sometimes you specifically want the model to know nothing except the current problem.

52. Stale folders can poison fresh work.
A model that accidentally reads old drafts can begin treating abandoned thinking like current truth.

53. Context has a contamination cost.
Every document changes what the model is likely to produce.

54. Turn on interactive charts when you’re doing data work.
If the model can render the data interactively, use the surface instead of mentally parsing another table.

55. Turn off training for work you do not want contributing to model improvement.
Privacy settings are part of the workflow, not an afterthought.

56. Cap team usage.
Unlimited enthusiasm plus metered frontier models is a finance problem waiting to happen.

57. Run Claude’s setup workflow instead of manually guessing every setting.
If /setup-cowork can configure the environment through questions, make the system do the setup work.


5 · Projects Are Context. Skills Are Behaviour.

58. Stop confusing Projects with Skills.
A Project tells Claude what world it is inside. A Skill tells Claude how to perform a recurring task.

59. One durable client, one Project.
Emails, agreements, prior work, decisions and relevant history belong together.

60. Project context should stay inside the Project.
The entire point is relevance without contaminating unrelated work.

61. Do not stuff Projects with instructions just because you can.
The files may already contain enough context.

62. Too much instruction turns every answer into the same answer.

63. Creative work deserves breathing room.
Load forty previous posts and the model starts remixing your archive instead of discovering the forty-first idea.

64. The past can become a creativity ceiling.
Context does not only teach. It anchors.

65. A Skill inside a Project is where things get interesting.
The Project supplies the client reality. The Skill supplies the repeatable operating procedure.

66. Create thinking in Chat before moving execution to Cowork when useful.
Settle the direction before unleashing the workers.

67. Use Projects for onboarding.
Company deck, CEO interviews, operating docs, FAQs, previous decisions. Let the new employee interrogate that context first.

68. Ask the Project before asking the colleague.
“Here’s what I found and what I think; what am I missing?” is a better use of human attention than “I don’t know.”

69. The archive does not belong in the active context.
Curate the gold.

70. File limits are a feature if they force you to decide what matters.


6 · Skill the Repetition

71. If you explained the workflow twice, consider turning it into a Skill.
Repeating yourself is not craftsmanship. It is missing infrastructure.

72. Skills belong to repeated work.
Contract review. QA. Research methodology. Formatting. Publishing checks. Anything where consistency matters.

73. Keep Skills away from early creative exploration.
Reusable instructions reduce variance. Creativity often needs variance.

74. Skills can travel.
A good operating procedure should not die because you changed surfaces.

75. Build Skills from workflows that already work.
Do not automate an unproven process.

76. Use the Skill creator when the process is mature enough.
Claude can help encode the procedure you have already discovered.

77. Load deep reference material only when the Skill needs it.
Hundreds of pages are fine if they appear only when invoked.

78. Watch automatic triggering.
A badly described Skill can activate when you never intended to use it.

79. Skill descriptions are routing logic.
Write them like routing logic.

80. Test a Skill with multiple phrasings.
A workflow that works only when summoned using one magical sentence is brittle.

81. Share proven Skills with the team.
One person’s method becomes organizational infrastructure.

82. Build a /how-to Skill for unfamiliar Claude workflows.
Let it plan the sequence and interrogate you before execution.

83. Build a prompt-builder Skill when the expensive model deserves a better brief.
Use Opus to structure the prompt, then give that brief to Fable.

84. Build an anti-slop Skill.
Your banned phrases, writing tells, tone failures and publishing checks should become a repeatable filter.

85. Build an About-Me Skill instead of polluting every conversation with yourself.
Load your voice and working context only when it matters.

86. Turn the design system into a Skill.
The next visual should not require re-explaining typography, spacing and visual language from zero.


7 · Cowork Is Not a Fancy Folder

87. Cowork is parallel labour.
The interesting part is not accessing files. It is splitting a large problem across multiple agents.

88. Give Cowork work large enough to divide.
“Prepare the onboarding deck, welcome email and operating checklist” gives parallelism something to do.

89. Stop watching agents work.
If the run takes twenty minutes, leave.

90. Match the surface to the artifact.
Question → Chat. Document-shaped output → Cowork. Software → Code.

91. Claude Code is less narrow than it looks.
The terminal-looking interface scares people away from capabilities they would happily use if the UI looked softer.

92. Export working files into the environment where people actually collaborate.
If the spreadsheet ends up in Google Sheets anyway, move it there.

93. Put assumptions before spreadsheets.
Before the model builds the financial model, make it expose what it is assuming.

94. Give assumptions their own sheet.
Inputs should be editable, visible and pressure-testable.

95. Never hide an assumption inside a formula.

96. Use “Restart from here” aggressively.
You do not need to keep paying for a bad branch of the conversation.

97. Redo the broken section, not the entire deliverable.
“Keep everything else. Only rebuild section two.”


8 · Claude Code and Vibecoding

98. Vibecoding is useful. It is not magic capitalism.
A clickable prototype and a small internal tool are legitimate wins. “AI built it” does not manufacture demand.

99. Start Code in a clean folder.
Do not let yesterday’s experiments quietly become today’s architecture.

100. Pick your model before the build begins.

101. Bypass permissions only when you understand the consequence.
Constant approval clicking kills autonomy. Blind permission bypassing creates another kind of problem.

102. Company machine? Ask IT before going cowboy mode.

103. Give Claude Code the CTO relationship when useful.
“You are the CTO. I am the CEO. Interview me, make the technical choices, test it and ship a usable link.”

104. Screenshots beat tortured descriptions.
If you can show what you want, show it.

105. Taste can be encoded.
A good DESIGN.md carries more visual information than twenty adjectives about “premium minimalism.”

106. Borrow mature component systems.
If shadcn/ui gets you professional controls faster, use the fucking components.

107. Build one piece at a time.
Home page first. Make it right. Then move.

108. Twelve simultaneous changes create twelve hiding places for failure.

109. Run the visual loop.
Build → inspect → list exactly what is wrong → fix → refresh.

110. Five iterations on one page beat one heroic prompt for the whole application.

111. Screenshot bugs.
“Fix this” plus the actual failure often beats a paragraph describing what your eyes already know.

112. The Build-Less-Than-You-Use Rule.
If you spend five hours building something you’ll use for fifteen minutes, you did not create leverage.

113. Performative productivity now has a deploy button.
Do not mistake a Vercel URL for useful work.

114. Write HANDOFF.md before prototypes become someone else’s problem.
What’s real. What’s mocked. What’s broken. Where things live. What should not be trusted yet.

115. Call prototypes prototypes.
AI did not remove engineering maturity levels.

116. Check /usage before starting a monster session.

117. One-off widgets do not deserve architecture.
If you’ll use it once, an artifact may be enough.


9 · Artifacts Are Disposable Software

118. Treat Artifacts like mini-apps.
Dashboards, calculators, trackers, lightweight tools and interactive documents do not always deserve a codebase.

119. Ask an Artifact to remember state when persistence matters.

120. Put Claude inside the Artifact when the interface needs contextual intelligence.

121. Publish useful Artifacts.
A client-facing analyzer or employee quiz becomes much more valuable when someone can actually use it.

122. CSV → interactive chart is a ten-second decision-support tool.
Use it.

123. HTML is underrated for information design.
When text accuracy matters, a coded infographic can outperform an image generator.


10 · Design With References, Not Adjectives

124. Use the simpler surface for infographic work.
Code can be overkill when the deliverable is essentially designed information.

125. References first.
The model understands an actual visual better than your six-paragraph attempt to describe one.

126. Make it extract the design language before designing.
Palette. Type. Spacing. Signature motif. Let it tell you what it sees.

127. Demand a design-system preview.
DESIGN_SYSTEM.md plus a token preview can save you from discovering the wrong visual language after ten screens.

128. Fidelity to the reference should beat the model’s taste when fidelity is the requirement.

129. Reuse the original prompt when you want the same visual grammar with different content.

130. Mine visual taste deliberately.
Pinterest, Awwwards, Godly, Dribbble, Refero. Taste improves when the reference pool improves.

131. Use different engines for different visual jobs.
One model can create the atmospheric background. Another can lay exact text, charts and HTML over it.


11 · Connectors Can Make AI Useful Enough to Become Dangerous

132. Turn off connectors you are not using.
Every active connection is more context, more surface area and potentially more token overhead.

133. Combine connectors when the work genuinely spans systems.
Slack + Gmail + meeting notes can produce something none of those sources could produce alone.

134. Connectors give the model the one dataset it was never pretrained on: your week.
Your clients. Your deadlines. Your half-finished work. Your organizational reality.

135. Use specialist tools where they are stronger.
If Gamma produces better decks, let Claude structure the thinking and hand the visual execution over.

136. Keep work and personal accounts separated.
Convenience is a terrible reason to create an accidental company-data pipeline.

137. Memorize the lethal trifecta.
Private data access + untrusted external content + ability to send information out.

That combination deserves paranoia.

138. Minimum sufficient access beats maximum convenience.

139. Prefer official connectors.
A random third party can change what its integration does after you have already trusted it.

140. Audit connected access monthly.
Permissions accumulate because humans almost never remember to remove them.


12 · Token Economy Is Workflow Design

141. Message 30 is not message 1.
Long threads repeatedly carry their history forward. The cost curve changes while the UI still looks like a simple chat box.

142. Leave zombie conversations.
At some point the accumulated context is doing more harm than good.

143. Somewhere around 30–50 turns, ask whether you should restart.

144. Past 100 turns, you should have an extremely good reason to still be there.

145. Summarize and restart.
Carry the useful state forward. Leave the conversational debris behind.

146. Higher-tier plans can change how aggressively you use Opus.
Economics changes behaviour. Know your actual limits rather than vaguely fearing them.

147. Seat thresholds matter.
A pricing cliff can turn a harmless-looking headcount change into a serious bill.

148. Point at files instead of repasting walls of text.

149. Ask for the plan before paying for the implementation.
A wrong plan is cheaper to delete than wrong execution.


13 · Writing That Does Not Smell Like a Machine

150. Use ASD-STE100 when clarity matters more than personality.
It forces instructions toward controlled, plain language. Great for operational clarity. Terrible for poetry.

151. Do not use technical-language discipline blindly on creative writing.
Correct tool, wrong register, dead writing.

152. Kill the em-dash addiction.
AI has somehow discovered one punctuation mark and fallen madly in love with it.

153. Kill “It’s not X, it’s Y” when the contrast is doing nothing.

154. Kill “here’s the thing.”

155. Kill the motivational bow at the end of everything.

156. Ban the machine vocabulary you never use in real life.
Delve. Tapestry. Myriad. Seamless. Pivotal. Transformative. Whatever your model keeps reaching for when it has nothing concrete to say.

157. Force sentence-length variation.
One sentence can be four words. The next can actually breathe.

158. Stop making every paragraph symmetrical.
Reality does not arrive in six perfectly balanced blocks.

159. Add texture.
₹43. 4:30 AM. V2. The exact tool. The actual street. The weird little detail somebody remembers.

160. Personality must survive the cleanup.
Removing AI tells and removing the human are not the same operation.

161. Fake typos are embarrassing.
Human writing is not human because someone misspelled “because.”

162. AI detectors are not the standard. Human attention is.
You do not need a classifier to notice lifeless sludge.

163. Workslop transfers your labour to somebody else.
You saved ten minutes generating it. Your colleague now spends twenty deciphering it.

164. Dictate the mess first.
Ten minutes of messy spoken context can contain more reality than one immaculate written prompt.

165. Then make the model ask what your voice note failed to explain.


14 · Privacy, Research and Judgment

166. Use temporary or clean sessions for sensitive and highly exploratory work when appropriate.

167. Have a never-paste list.
Credentials. Customer data. NDA material. Sensitive source code. Unreleased financials. Private recordings. Things whose leakage creates actual consequences.

168. Anonymize before convenience wins.
Replace names. Reduce the fragment. Remove metadata. The model usually does not need the identity to solve the problem.

169. Use the company-channel test.
Would you be comfortable seeing this exact material posted internally with your name attached? If not, reconsider where you’re pasting it.

170. Research mode is criminally underused.
For a serious question, make the system plan the research, inspect the sources and return with something closer to analyst work.

171. Ask decision questions, not school-report questions.
“What should we do given X?” creates more value than “tell me everything about X.”

172. Research does not remove verification.
A 70-page report can still contain one wrong number that changes your decision.

173. Review financial work.

174. Review legal work.

175. Review anything where a confident mistake can cost more than the time you saved.