AI Guides

751 short, practical AI guides by Nigel Guy. Each names the common mistake, gives the rule that fixes it, and says what to skip. Free to read.

Step-by-step guides

Follow along click by click, checked against today's official docs.

• The AI Answer Gap Audit: Check What Assistants Say About You, Then Fix the Source — You cannot instruct a model to quote you. You can only make your pages reachable, clear and consistent, then measure what comes back.
• Build an AI Co-Founder From a Context File and Three Rules — A co-founder is a context file plus permission to push back. Load facts, load your known weak spots, and write down exactly how it should challenge you.
• Make an Anime Short of Yourself with Claude and the Higgsfield Connector — Claude writes and directs; Higgsfield renders. Nothing gets animated until a character sheet and a set of still panels are approved, and every later generation is made from that sheet, never from the last clip.
• Brain Dump, Project, Files: The Claude Setup Order — Tell Claude everything once, in a project, before you ask it for anything that matters.
• A Brand Deal Research-and-Draft Pipeline With Claude — Let the AI research and draft, but you choose the targets, check every claim against a source, and press send yourself.
• Brief First, Then One Slice at a Time: Building an App by Chatting With Claude Code — No code until there is a written brief, and no slice is "done" until something runnable says so.
• Build a Codebase Map Claude Reads Before It Reads Your Files — Build the map once, keep it fresh cheaply, and treat it as a guide to which files to open, never as a replacement for opening them when the answer matters.
• Build Your Own Content Kit in Claude: A Project, a Skill and an Artifact — Build the three layers separately. A Project holds what Claude should know, a Skill holds how a repeatable job is done, and an Artifact is a small tool you use. Mix them and you get one giant prompt that nobody maintains.
• Job Hunting with ChatGPT Work: A Three-Pass Chain That Stops Before Submit — Let ChatGPT do the searching, sorting and first-draft tailoring, and keep the submit button for yourself. You decide which roles get an application, and you read every CV before it goes.
• Running a Claude Code Agent Swarm with Ruflo, Safely — Split the work into named roles with written boundaries first, start with two or three agents, and only add more when the previous run was reviewed and was good.
• Claude Code Command Centre: One Connector at a Time — Add one connector, prove it with a read-only question, and only then let anything write, send or spend.
• Your First Claude Code Build: Install, One Small Task, One Check — Start in one empty folder, give Claude one small job, and tell it the check that proves the job is done, so it runs the check itself instead of you pasting errors back.
• Set Up a Claude Code Routine That Reads, Reports and Touches Nothing — Limit what the routine can reach before you write what it should do. Strip the repositories, network and connectors down to the job, then let the prompt describe the job.
• Splitting Work Across Claude Code Subagents with a Hand-Off Card — A subagent knows only what you put in its brief. Write every hand-off as if the reader has never seen your conversation, and say exactly what shape you want the answer back in.
• Claude Code in the Terminal: Install, First Session, First Scheduled Routine — Install once, prove it works by hand, then put each recurring job in the scheduler that matches where it needs to run — cloud, desktop or open session — with one job per schedule.
• Connectors, Projects and Skills: Setting Up Claude in One Evening — Give Claude somewhere to work (a project), something to work with (a connector), a way to repeat good work (a skill), and permission to ask before it guesses.
• The Day-One Claude Setup: Five Layers, in Order — Set Claude up from the widest layer to the narrowest. That means account-wide rules first, then search, then Projects, then folders and Cowork, and the model last. Each layer inherits from the one above, so a mistake near the top gets copied into everything below it.
• Set Up Claude Once: Memory, a Voice Brief and Dictation — Spend week one on the three settings that carry over to every chat (memory, a written brief about how you work and sound, and dictation), and treat the testing as a by-product.
• The Five-Switch Order for Claude: Skill, Schedule, Share, Plugin, Browser — Switch on five things in a fixed order. First the task you repeat, then the task that should run without you, then the output you need to send, then a ready-made toolkit, and last the browser. Each step depends on the one before it, so skipping ahead hands more power to something you haven't tested.
• The Claude Four-Part Setup: Memory, Skills, Connectors and an Ask-First Rule — Give Claude durable context once (memory, skills, connected data), then give it a standing instruction to ask before guessing, and check each part with one test.
• Four Settings, Set Once, So Claude Stops Answering Like a Stranger — Tell Claude who you are once, in the four places built for it, and put each fact in the place where it belongs, not all in one pile.
• The Three-Layer Claude Install Shortlist — Pick one job, install one thing from the right layer, use it for a week, and only then add the next.
• Three Jobs for Claude Before You Pay a Solicitor: Read, Chase, Record — Use Claude to read, structure and draft, never to decide. Every output ends as a list of questions and a draft that you check against a primary source or a professional.
• Claude Memory: Write a Brief, Import It, Prune It Monthly — Memory holds the durable facts about you and how you work; anything that belongs to one piece of work goes in that project's instructions, and anything you would not say to a new colleague stays out.
• Give Claude a Notebook File It Reads and Updates Every Session — Memory you can open, read and correct beats memory you have to trust. Keep the project's state in one file you own, and make reading it and updating it the first and last thing every session does.
• The Claude Surface Pick Table — Pick the surface by where the work lives (your files, a website, a repo, or nowhere yet), then move the session if your location changes, rather than starting again.
• Connect Claude to Indeed and Let Your CV Do the Filtering — Give Claude your rules before it searches, and make it show its reasons for every match, so you only spend time on roles that survived a written test.
• Connect Claude to Metricool and Run a Weekly Social Read — Let Claude read everything and schedule nothing without showing you the exact post, platform and time first.
• Connect Higgsfield to Claude and Check Your Credits First — Connect once, make Claude quote the credit cost before every render, and generate one shot before you commit to the rest.
• Connect prompts.chat to Claude Code So It Searches the Library for You — Don't carry prompts to Claude, let Claude fetch them. Install once, search with one command, and read what comes back before you run it.
• Build a Site From a Brand File, Not a Prompt: The DESIGN.md Workflow — Write the brand down as a file before any screen is generated, and make every tool read that file.
• The Design Rules File: Turn "Make It Premium" Into a Spec Claude Follows — Replace adjectives with values. A design rules file lists the exact colours, type sizes, spacing steps and component patterns, plus a short list of things never to do, and Claude reads it before it builds anything.
• Edit Talking-Head Videos by Describing Them: Claude Code and Remotion — Write the editor's rules down once as a skill, then build the video in small passes you can watch between each one.
• Fable Plans and Checks, Opus Builds: An Orchestrator–Worker Split in Claude Code — Fable writes the specs and checks the results. A worker subagent pinned to Opus 5.5 does the building. Neither swaps jobs with the other.
• Find a Named Contact with the Vibe Prospecting Connector — Ask a connected data source for the person, make Claude report what the database holds (and what it does not), and treat every email as a lead to check, not a fact.
• Five AI Skills Worth Building, and the Three-Question Test That Picks Yours — Only build a skill that survives a tool change, that you will use on real work within a fortnight, and that you can check for yourself.
• Five Claude Code Add-Ons, Installed in Order of Risk — Install in order of how much each one can change or touch, read what it will do before you run it, and stop at the first one that already solves your problem.
• Five Claude Code Skills, Installed One at a Time — Install one skill, run one real task with it, keep it only if the result is visibly better, then add the next.
• Five Claude Projects for Recurring Admin, Built in a Week — One Project per recurring job, with written instructions, two or three reference files and one real task handed over on the day you build it.
• Five Claude Projects With Pinned Instructions and a Short Upload List — One project per area of your life, one page of pinned instructions, and a short upload list you can name from memory.
• Five Claude Setups That Remove Repeated Chores: Instructions, Project, Skill, Connector, Artifact — Set up a thing only when you have explained the same thing three times. Match the repeated annoyance to the right container, and do one this week, not all five.
• The Five-Layer Claude Setup: App, Connectors, Skills, Then Claude Code — Add one layer at a time, and don't add the next until the current one has done a real job for you.
• Five MCP Servers, Installed One at a Time, Each With a Check — Add one server at a time, give it the narrowest access that does the job, and prove it works with one real question before you add the next.
• Five Departments From Five Plugin Installs — Install the skills in minutes, then spend twenty minutes making each one yours, and treat anything with legal or financial weight as a draft for a professional.
• Turn Five Repeat Jobs Into Claude Skills — If you have explained the same job to Claude three times, stop explaining it and write it down once as a skill, with a description that says when to use it.
• Five Weekend Builds: Claude Projects, Connectors and Your Own Files — Build one thing on your own information, with a "say so if you can't find it" instruction, and use it for a week before you build the next.
• Four Claude Agents: Think, Sort, Watch, Draft — An agent is a saved prompt plus access plus a trigger. Give each of the four exactly one job, the least access that job needs, and a stop point where you take over.
• Fresh-Evidence Research With the last30days Skill — Never ask an AI about a fast-moving topic without handing it dated, sourced evidence from a fixed window, and make it cite which source each claim came from.
• The Gather, Act, Check Loop: Steering an AI Agent One Turn at a Time — An agent is a loop of gather context, take action, check the result. You steer it by controlling what it can reach, what counts as "done", and when you step in.
• The Gmail Three-Switch Privacy Check — Check all three places in one sitting, write down what you chose, and only then decide what to switch back on.
• Giving Claude Code a Codebase Map With Graphify — A graph is only useful while it matches the code, and the install is only safe once you know exactly what it writes to your project.
• Headshots From Your Own Photos in ChatGPT — Give ChatGPT several honest reference photos, tell it exactly what to keep and what to change, and judge every result against your real face, not against how polished it looks.
• Build an Idea Scorecard Project in Claude or ChatGPT — Give the model a written standard and a scoring card once, in a project, so every idea gets judged by the same hard questions before you spend a year on it.
• Instagram Comment-Keyword DMs: Set Up the Auto-Reply in an Afternoon — Let a keyword in the comment trigger the private message, so you only ever write the message once. Your own time then goes on the comments that need a human.
• Install One Claude Code Plugin Pack, Then Audit What It Added — Install one path, start with one workflow, and read what the pack added before you trust it.
• The Name Canary: A One-Line Check for Long Chats Going Stale — Give the chat one cheap, visible instruction to obey on every reply, and treat the first missed reply as a signal to summarise and start fresh — not as proof of anything more.
• One CLAUDE.md File That Corrects Four Coding-Agent Habits — Put four behaviour rules and three short project sections in one CLAUDE.md, keep it under 200 lines, and check it actually loaded.
• One Claude, One Skill per Job: Turning Repeat Work into Playbooks — Keep one agent and give it a written playbook for each job. The playbook is the asset; the agent is just the thing that reads it.
• One Claude System Per Weekend: Pick From Ten, Build One — Build one system, run it on three real jobs, and only then build the next.
• The One-Day Claude Setup: Instructions, Memory, Projects, Connectors, Skills — Set up the five features in order, from who you are, to what you're working on, to where your files live, to how a task should be done, and give each one a single job.
• The One-Page Build Sheet: Describe a Small Tool Before Claude Builds It — Write the one-page Build Sheet first (who uses it, what goes in, what comes out, what it must refuse to do), then let Claude build from the sheet, one change at a time.
• One Project per Role: Building AI Helpers That Each Do One Job — One role, one project, one standing brief. Build a single role properly before you build a second, and give every role one thing it must never do without asking you.
• Pair, Launch and Check Claude Tag in Slack — Decide three things before anyone tags anything (who may use it, what it can reach, and how much it may spend), then pair, launch and prove it works in one pilot channel before you widen it.
• Pick Claude Chat, Cowork or Code by the Output You Need — Pick the mode by what you want at the end, not by how hard the task feels. A reply to read means Chat. Finished files on your computer mean Cowork. Working software in a project means Code.
• Plan in Claude, Build in Blink: The Build-Brief Method — No build prompt until you have a written build brief that a stranger could build from — screens, data, access and money, with the scope already cut.
• The Quarterly Subscription Audit: Test Each Renewal Against Something You Have Built — Question every renewal against what you actually use it for, and cancel only after the replacement has done that job for real at least once.
• Rebuild a Site's Look with DevTools Measurements and Claude Code — Give Claude Code two things, the picture and the measurements. The screenshot shows it the layout; the numbers you read out of your browser's developer tools stop it guessing.
• A Research-Then-Review Pipeline for B2B Cold Email — Let AI do the reading and the drafting, but never let it send a claim you cannot trace to a source, to a person you were not allowed to email.
• The Role-to-Model Card for Claude Agents — Give each agent a role, give each role a model on a written card, and change a card line only when a test on your own work says so.
• Mock Up a Room Redesign From One Photo With Claude Code — Change one thing per image, always start from your own photo, and treat every result as a sketch, never a spec.
• From Screen Recording to Reviewed Guide in Claude Cowork — Record once with the narration on, then treat what Claude proposes as a draft to check against the real app, not as documentation to publish.
• Screenshot Line to Aerial Camera Brief — Claude reads your line and turns it into words; Higgsfield only ever receives words and a start frame, so your job is to make those words specific and then check the result against the line.
• Screenshot to Live App: Plan First, Then Code, Domain and Payment Link — Get a written plan you have approved before any code exists, and make the AI save a working version to GitHub after every step.
• Search, Read, Act: Setting Up Claude's Web, Drive and Gmail Connectors — Connect one capability per job, in this order: search first, then read, then act, and grant write access only when you can name the task that needs it.
• A Second Brain for AI: A Claude Project or a Plain Folder — A second brain is one place where your working information lives in a form an AI can read without you re-explaining it. Pick the simplest container that does that, and spend your effort on what goes in it, not on the container.
• September's Claude Updates: Check Which You Have, Then Try One — Check what your account actually has, match one update to the work already on your calendar this week, and try that one with Claude asking before it acts. Leave the other four for later.
• Set Up Claude Properly: Memory, Standing Instructions and One Project — Give Claude three things once, in three different places (what it remembers, how it should behave everywhere, and the material for one piece of ongoing work), instead of repeating them in every chat.
• The Seven-Slot Shortlist: From Idea List to First Payment Link in a Week — Build the smallest thing one named buyer would pay for, take payment before you polish, and treat every idea on a list as unproven until someone pays.
• Seven Stops: Using Claude as a Workbench, Not a Text Box — Give Claude a small, clean, well-labelled amount of context for one job at a time, and keep every decision and every fact-check on your side of the desk.
• A Shared Memory Folder: One Read Order for Every AI Agent — Keep one source of truth in plain Markdown, give it a fixed read order, and make each file answer exactly one question.
• Give Claude Code and Codex One Shared Notion Desk — Give every agent the same written place to read rules from and write progress to, and make the agents use it before they use the chat.
• Train a Soul ID Once, Then Shoot a Set Through Claude — Train the face on the Higgsfield website, direct the shoot from Claude, and generate every image from the trained character by name. Never use your last output as the reference for your next one.
• A Spoken Morning Numbers Brief in Claude: Number Card, Connectors, Schedule — Write down which numbers matter and what would make each one worth acting on before you connect anything. The brief reads that card back to you; the connectors only fill it in.
• Stretch Your Claude Usage Limit With Fresh Chats and a Handover Note — Keep each conversation small and single-purpose, and carry the thread between conversations in a short handover note you write, not in a long history Claude has to re-read every turn.
• Ten Scheduled Claude Tasks That Draft but Never Send — Each automation is a saved prompt on a schedule that reads, sorts and drafts, then stops for you. Build one, watch it run twice, then build the next.
• The Three-Connector Map: Email, Calendar and Files, Then One Real Job — Connect three tools, read-only in spirit, give them one real job with a written output, and only then add a fourth.
• The Three-Layer Starter Stack for Claude — Add things in three layers, built-in first, then connectors, then plugins, and switch each one on only when you can name the task it serves.
• Three Earning Systems, Built One at a Time, Counted in Pounds — An AI agent drafts and sorts, you approve and send, and every system gets a line in a ledger that shows pounds in, not activity.
• The Three-Setting Claude Start: Privacy, Instructions, Memory — Before your first real piece of work, set three things in this order: who can learn from your chats, what Claude should always know, and what Claude is allowed to remember. Each one shapes every conversation after it, so doing them later means cleaning up after the fact.
• Three Starter Builds in Claude: an Income Dashboard, One Scheduled Task, a Three-Agent Team — Build the smallest version that does one real job, use it for two weeks, and only then add the next piece.
• A Timeboxed Claude Code Build for a One-Screen Phone App — Spend fifteen minutes on exactly one screen that does exactly one thing, plan before Claude edits anything, and stop at the clock whether or not it looks finished.
• Build a Trip Packing App in Claude Code: Past Weather, Photo Palette, Capsule List — Forecast only what can be forecast, use past years for everything else, and take the colours from real photos you can see and credit.
• A Two-Hourly Inbox Triage That Only Ever Drafts — The job may read, label and draft. It may never send, forward or delete. You are the only sender.
• Build a Two-Tool MCP Server for Claude Desktop — Build a two-tool server, test it outside Claude before you test it inside Claude, and change one thing at a time.
• Turn a YouTube Video into a Tutor That Quizzes You — Let the video be the source, never the teacher. Make something ask you questions about it, and only count what you can answer without looking.
• Wire Five Research Connectors into Claude, Then Give It a Routing Rule — Connect one tool per job, then tell Claude in writing which job belongs to which tool, and make it ask before combining them.

Playbooks

Repeatable systems for getting a real result with AI.

• The Agent Access Card: Three Controls to Set Before Any Agent Touches Your Business — Write down what each agent can reach, what it can get out through, and what it can do that can't be undone. Then make the system enforce those limits, not the prompt.
• The Agent Manager Job: A Claim Ledger for the Salary Hype and a Proof Run for the Skill — Check each claim on its own, against the primary source, and keep only what survives. Then prove the skill with a run you can show, not a certificate you can't.
• The Agent Permission Card: Letting AI Read Your Inbox and Send Cold Email Without Losing Control — An agent earns autonomy one action at a time, and only for actions you have written down, can check afterwards, and could undo or live with if it got them wrong.
• The Agent Roster Card: One Job, One Folder, One Memory, One Schedule — An agent is only real when it has four things written down — a single job, its own folder, its own memory file and its own trigger. Anything missing is a role-play, not a team member.
• The Agent Team Role Sheet: How to Split One Job Across Several Agents — Never create an agent without writing down what it receives, what it hands back, what it may touch, and when it stops.
• The AI Use Register: Placing a Small AI Business Under the EU AI Act — List every AI use in your business, give each one a role and a risk tier, and do only the work that tier demands, with a dated record of what you did.
• The Brief Card and Three-Task Ladder for Claude Cowork — Treat Cowork as a delegate you brief, not a chat you steer. Write a short brief first, start with a task that cannot do damage, and widen access only after a task has gone right.
• The Tell Audit: Turning ChatGPT's Own Habits into a Standing Rule — Have ChatGPT audit your own drafts for its tells, compress the findings into a short rule written as positive instructions, save that rule where ChatGPT reads it every time, then test the rule against a fresh draft. A rule you have not tested is a hope.
• The Claim, Evidence, Limit Card for Claude's "Workspace" Paper — Before you share a take on any AI research story, write down three separate lines, what was claimed, what was done to test it, and what the authors say it does not show, and share only what survives all three.
• The Claude for Teachers Eligibility Check — Check who you are, what you are claiming and what you are allowed to paste, in that order, before you run a single prompt.
• The Repeat-Mistake Ledger for Your CLAUDE.md — A line earns its place in CLAUDE.md only when its absence has already cost you a mistake, and it is concrete enough to check.
• The Claude Model Pick Card: Matching Task to Model — Start on the cheapest model that could plausibly do the job, raise effort before you raise the model, and move up only when a real output has failed a check you wrote in advance.
• The Send Sheet: Six Habits That Make Your Claude Allowance Last — Every message you send pays for the whole conversation behind it, so keep that conversation short and clean, and don't send the same thing twice.
• The Three-Door Check for Connecting Claude to Outside Tools — Look for the connector in the directory first, read its label, and only go to a custom URL or command when the directory has nothing, treating each step down as a step up in how much you must check yourself.
• The Context, Role and Check Card for Working With AI Agents — Write the context down, give the agent a role with edges, and never accept output that has not passed a check someone other than the author can see.
• The Family Logistics Brief: A Claude Project That Holds the School Run — Put the facts that rarely change in one place Claude always reads, put this week's mess in the chat, and make Claude say what it is unsure of before it plans anything.
• Fan-Out, Debate, Council: Three Formations for Running Several Claude Agents — Pick the formation by the shape of the question, give every agent a different job, and write the tie-break rule before anyone starts.
• The Filed, Reported, Projected Ladder for OpenAI's IPO Numbers — Before you use any OpenAI number, say which rung of the ladder it sits on, and never let a number from a lower rung borrow the authority of a higher one.
• The First-Deal Card: Reading a Creator's Brand Deal Story and Running Your Own — A brand deal is a transaction with a buyer, a product and a set of rules. Write all three down before you post, pitch or accept anything.
• The First-Client Ledger: Find, Pitch and Price Your First Automation Job — Sell one named, measurable chore to one person who already feels it, price it before you build it, and write down what the job will not do.
• Five AI Income Routes and the First-Move Card — Pick one route, take its first move inside seven days, and decide in advance what result earns a second week. If you can't name the buyer and the first move, you don't have a route yet. You have an idea.
• The Five-System Ladder: Build Claude Into Your Work, One Rung at a Time — A system is anything that saves a decision so you never make it again. Build one rung at a time, and only climb when the rung below has paid for itself twice.
• The Five-Default Override Card for Claude — For each of five settings, decide on purpose whether the default serves you, and write the decision down. Keeping a default is fine; keeping it by accident is not.
• The Five-Minute Free Tool Limit Test — Never rely on a free tool until you have deliberately hit its limit on purpose, with a throwaway file, and written down what happened.
• The Five-Rung AI Engineering Ladder — Climb one rung at a time, and do not step up until you can show a small piece of working evidence that you have finished the rung below.
• The Five-Stage AI Roadmap With Exit Checks — Do not move to the next stage until you can pass its exit check with something you made, not something you watched.
• The Four-Lane Fit Card: Turning Anthropic's Growth Into Work You Can Actually Sell — Treat the growth numbers as evidence that demand exists, then pick one lane where you already have a skill, a customer and a way to prove the work. Nothing in this guide is investment advice or a promise of income.
• The Four-Lens Experience Audit — Audit what you already hold, not what you might become, and make every answer end in a dated action or a named thing you will stop.
• The Four-Room Card for Choosing Where to Use Claude — Pick the room by the thing you want at the end, not by the room you already have open.
• The Four-Route Creator Income Ledger — Before you post, name which of the four routes pays you, what it needs from you, and whether it leaves an asset behind; then pick one to test first and decline the one that does not fit.
• The Free AI Credential Ledger — Pick one credential for one job you will do in the next 30 days, finish it, then use it on real work before you enrol in anything else.
• The Condition Card: Reading GPT-6 Astra's Benchmark Numbers — Never carry a benchmark number anywhere without its conditions. If you cannot say what harness, effort setting, safeguards and rival scores sat behind it, you are repeating a headline, not a result.
• The Health Question Brief Card for Claude — Ask Claude to help you understand and prepare, never to diagnose or decide, and give it a brief that makes a specific answer possible.
• The Same-Job Scorecard: Judging a New Claude Model by the Work, Not the Voice — Never judge a model on how it sounds; run the same real job on the old and new model, with a pass mark written down beforehand, and score the output.
• The Judgement Handover Card — The model supplies drafts; you supply context, the test for "good" and the final check. Hand over only what you can judge.
• The Judgement Ledger: Turning Your Expertise into a SKILL.md File — Capture decisions, not credentials. If a line in your skill file wouldn't change what the agent does next, delete it.
• The Keep-or-Hand-Off Ledger: Using AI Hard Without Giving Away Your Judgement — Decide task by task what AI does and what you keep, write it down, and change one thing at a time.
• MCP and A2A Under One Foundation: The Two-Lane Handshake Check — A shared standard tells you how two systems can talk, not whether you should let them. Sort every "works with agents" claim into its lane, then check who holds the keys before you connect.
• The Meeting Homework Project: A Claude Project That Turns Transcripts into Decisions, Actions and First Drafts — A meeting is processed only when you have the decisions, the owned actions, the open questions and a first draft of the quickest follow-ups in hand. Anything less is summary theatre.
• The MiniMax H3 Licence-First Check — Decide how you will run H3 and whether your use is allowed before you spend time on prompts.
• The Ninety-Box One-Line Tracker — One box per day, one tick, one line of evidence written the same day, and a pre-agreed plan for the day you miss.
• The Ninety-Day Quarter Card: A Five-Pass Review in One Claude Chat — A review is finished only when it produces three priorities, a weekly check-in and a list of things you are dropping, all written down where next quarter's you can find them.
• The No-Guardrails Claim Check: Vetting a Free Multi-Model Image and Video Tool — Treat "no guardrails" as a claim to be decomposed, not a feature to be enjoyed. Before you install anything, name what the tool is, where it runs, who made each model, and which checks have moved from the vendor to you.
• The o3 Swap Test Card: Moving Off a Retiring Model Without Breaking Your Prompts — Find out which o3 you actually use, put a date against it, then swap on a test card, not on faith.
• The One-Job Crew Card for AI Agents — Every agent gets exactly one job, one set of tools that job needs and nothing else, and one file it hands over to the next agent. If you cannot say the job in one sentence, it is two agents.
• The One-Leak Card for a First Small-Business Automation — Automate one named leak, with one trigger, one owner and one number you can check in a week. Nothing else goes in the first build.
• The One-Person Business Picker: Three Models, One Weekly Scorecard — Pick the model by who pays and what they pay for, then give it a fixed test with a kill threshold before you build anything.
• The One-Ticket Ledger for a Small Laundry Shop — One ticket is one row, every row has one status, and you build the smallest tracker that answers "where is it and what is owed?" before you add anything else.
• The Outcome Quote Card: Pricing AI Freelance Work by Result, Not Hours — Price the outcome the client gets, scope it tightly, and never itemise the time or the tool.
• The Page Brief Card: How to Brief Claude Code to Build a Web Page — Brief one page at a time on a card with four fixed blocks, give Claude a way to check its own work, then change one thing per round.
• The Period-and-Basis Card for Anthropic's IPO Numbers — Never repeat an IPO number until you can say who published it, which period it covers and what it measures.
• The Plan, Goal, Background, Review Card for Claude Code — Decide what "done" means before Claude starts, let something other than Claude check it, and only review what that check produced.
• The Research Brief Card: Seven Business Jobs for Claude Research — Write the decision first, then the brief. Research is for gathering sourced material toward a decision you have named; the checking and the judgement stay with you.
• The Sample-First Proposal Ladder for a First Upwork Gig — Don't ask a stranger to trust you; hand them a small piece of finished work about their own job, and make the proposal about that.
• The Saved-Video Conversion Ledger — A saved video is only worth keeping once it has become something you can run, and the video itself is then disposable.
• The Seven-Skill Creative Pipeline: One Skill Per Stage, One Idea Through All of Them — One skill per stage of the work, each with one job, one input and one output that the next stage can pick up. If a skill needs the word "and" in its description, split it.
• The Side-Income Fit Scorecard: Pick the AI Route That Pays Soonest — Choose the route where someone you can already reach has a problem you can fix this month, and sell one small, priced job before you build anything.
• The Six-Game Career Pick Card — Name the one game you are playing for the next twelve months, write down what counts as winning, and judge every AI habit by whether it moves that score.
• The Six-Month Recheck: Retest Five AI Features Before You Write Them Off — An opinion about an AI tool expires. Retest it on a real task of yours, with a pass mark you set before you start, and only then decide.
• The Pre-Install Check: Scanning a Claude Skill with NVIDIA SkillSpector — No skill from outside your own hands gets installed until it has passed a scan you ran yourself, on the exact copy you are about to install, and you have read anything the scan flagged.
• The Stated-Position Check: What Anthropic Actually Says About Open-Weight Models — Before you repeat, cite or argue with anyone's stated position, read the primary statement, write down what it commits to and what it does not, and only then compare it with the claim you heard.
• The Swap-Readiness Card: What Anthropic's Chip Team Means If You Build on Claude — Treat hardware news as a reminder that the model you call is temporary, and keep your build in a state where swapping it is a config change plus a test run, not a rewrite.
• The Five-Probe Conversation: Test a Task by Talking Before You Automate It — If you cannot get a good result from a chat by steering it yourself, you are not ready to automate it. Use five short probes to find out, and write down what worked.
• The Taste File Pass Card: Giving Your Coding Agent a Design Brief — Never ask an agent to design from adjectives. Hand it one plain-text design file, make it read that file first, and check the result against the file's own Do's and Don'ts.
• The Agent Access Card: Three Rules Before You Connect an AI Agent to Anything Real — Decide what an agent can touch before it starts, enforce that outside the model, give each job its own keys, and plan for the day it goes wrong.
• The AI Spend Ledger: Five Purchases to Skip and What to Use Instead — Pay for a tool only after you have hit a specific limit doing real work, and write that limit down before you pay.
• The Always-Allow Check for Claude in Chrome — "always allow" is a decision about the site and the account behind it, not about the task in front of you, so make it once, deliberately, with the six checks below.
• The Back-Office Ledger: What Three Wealth Reports Say About Quiet AI Use — Let AI do the reading and the reporting, keep the deciding for yourself, and decide what it is allowed to see before you give it anything.
• The Boundary Map: Checking Your Claude Work Against Anthropic's Usage Policy Before the Lines Move — Treat Anthropic's policy hiring as advance notice of where enforcement will tighten, and map your own use cases against the published Usage Policy now, while nothing is broken.
• The Capture-and-Recall Ledger for a Claude Second Brain — Capture the reason, not just the thing, and make yourself recall before Claude retrieves.
• The Claude Escalation Ladder: Choosing Between Fable and Opus — Start on Opus, move up to Fable only when a fair test on Opus has failed, and move up for a reason you can name.
• The Claude for Open Source Eligibility Check: Numbers First, Application Second — Check your own numbers against the official criteria and the general requirements first, then write the application around the one criterion you can prove with a public link.
• The Context Brief: Fix What the Model Knows Before You Fix How You Phrase It — Before you rewrite a prompt, check what the model has been given to work with. If a smart stranger could not do the job from this page alone, better wording will not save it.
• The Context Ladder: One Home for Everything Your AI Needs to Know — Write your context down once, in one place you own, and point every AI tool at that place instead of at your memory.
• The Cut List: Auditing Your Subscriptions with a Tool You Build Yourself — Let the AI build the tool, not see the money. Build the checker from fake rows, run your real statement through it yourself, and cancel through the route that actually stops the payment.
• The Daily Five Card: Five Small AI Habits That Protect Your Money and Time — A habit only counts if it ends in something you can check tomorrow: a number written down, a task removed, a purchase decided or a skill practised. If it doesn't leave a trace, it was a chat, not a habit.
• The Demo-Reading Card: Judging an AI-Built Game Before You Believe It — Never judge a demo by what it shows; judge it by the five things it had to hold together, and by what the people who built it admit it cannot do.
• The Directed Use Ledger: How to Be Neither Purist Nor Maximalist — Decide per task, not per identity. For every piece of work, name what you keep, what AI drafts, and what check you run before anything leaves your hands.
• The Durability Ledger: Which of Your AI Tools Will Still Be There in Five Years — Keep a tool because it is better at a specific job you can name, not because it was first or familiar, and know in advance what would make you leave it.
• The Earned-Week Ranking: Sorting Your AI Tools by the Work They Actually Do — Rank a tool by the hours of your real week it earns, not by its reputation, and cancel anything that cannot name the job it does better than the tool above it.
• The Egress-First Agent Checklist — Never treat an instruction, or a belief about the setup, as a boundary. Only something that is enforced outside the agent, and that you have tested, counts.
• The Eight-Layer Ladder for Learning AI From Zero — Climb one layer at a time, stay on a layer until you can pass its check, and do not add a new tool until the layer you are on needs one.
• The Eight-Rung AI Engineer Ladder — Climb in order, and do not move up a rung until you can show one small thing you built or measured at the current one.
• The Evidence-Before-Certificate Ladder — Spend your first fortnight producing evidence of work you can show, and buy or earn a certificate only where a named reader has asked for it.
• The First-Task Ledger for Starting AI Late — Judge whether you are late by what people actually do with AI, not by how loudly it is discussed, then run one small, real task a week and write down what happened.
• The Five-Bin Check: What Stays Out of a Claude Chat, and How to Clean What Goes In — Decide what the text is before you paste it, not after. Five kinds of material never go in at all. Everything else goes in cleaned, and you check the cleaning yourself.
• The Five-Part Life Ledger: Tracking Your Inputs Without Running Your Life Like a Startup — Track only the inputs you are willing to change, review them on a fixed day, and let the AI do the summarising while you do the deciding.
• The Five-Question Asset Test — If it stops working the day you stop touching it, it is a task. An asset is something you build once that keeps producing, can be handed to someone else, and gets better each time it is used.
• The Five-Setting Beginner Check for Claude — Before you judge an answer, check the five settings that decide its quality, namely memory, pushback, thinking, inputs and honesty about guesses.
• The Four-Doors Routing Table for Claude — Pick the door by where the finished work has to end up, not by where you happen to be typing.
• The Four-Gate Income Test — No AI income idea gets a week of your time until it has passed four gates in order, and each gate has a pass mark you wrote down before you started.
• The Four-Question Receipt Check: Testing AI Advice Before You Act on It — Before you act on anyone's AI advice, ask four questions about the person giving it, and let the answers set how much checking you do yourself. That includes the advice on this site.
• The Four-Register Sweep for Lost UK Money — Search the official registers yourself, for free, and use Claude only to remember your past and organise the paperwork. It can't search the registers for you, and it can't tell you what you're owed.
• The Four-System Ladder: Second Brain, Teammate, Workflow, Automation — A system is anything you set up once that makes the next run better or cheaper without you starting from scratch. Build the four rungs in order, and don't climb to the next one until the one below is earning its keep.
• The Four-Week Practice Ledger for AI Skills — Practise one narrow skill, and make each session force you to produce, recall, vary or explain something before you are allowed to look at the answer.
• The Full-Cost Ledger: Reading an AI "Price Per Result" Claim — A price per result is only the price of the final run. Before you act on one, write down every other cost that sat behind it, and cost your own task the same way.
• The Gap Memo: Replace the CV With a Ninety-Day Plan — Stop proving you match the advert; show the manager you have already looked at their problem. Send a short plan built on one real gap, not a rewritten CV.
• The Goal Ladder: Choosing a Bigger Goal and Checking It Holds — Write the goal that would force you to change the method, then prove it is ambitious rather than fantasy by building a ladder of checkpoints underneath it.
• The Half Tank Method: Three Habits That Stop Claude Limits Arriving Early — Spend your limit on the work, not on the carrying costs. Check your usage at the halfway mark of a session, and when you are half-spent, change one of three habits: the model, the context size, or the chat.
• The Handover Ladder: Turning Repeat Work into Scheduled Claude Tasks — Never schedule a task you have not run by hand three times, and never hand over a job you could not check in two minutes.
• The Income Claim Ledger: Grading "Ways to Earn With AI" Before You Spend a Weekend on Them — Never act on an income claim until you have graded what kind of evidence sits behind it, and only build on the claims that survive the grade.
• The Job Scorecard: Comparing AI Tools on Your Own Work — Judge tools job by job, on your own real work, with the pass mark written down before you run the test, and put a date on every verdict.
• The Leverage Ledger: Five Sums That Replace Vanity Metrics — Track only numbers that end in a sum you can redo from your own records, and pair every speed number with a quality number.
• The Loop Card: Objective, Check, Exit and Ceiling for Self-Running AI Work — Never start a loop until you can write down what "done" looks like, how it will be proved, and what makes it give up. If you can't fill in those lines, write a prompt, not a loop.
• The Match Card: Getting Found by a Job-Matching Platform Like Xeruit — On a matching platform your profile is the search query, so write it to be matched, not to be admired.
• The MCP Server Card: Five Checks Before You Connect a Server — A server gets connected only after it has a filled-in Server Card. If you cannot answer one of the five questions, you do not connect it yet.
• The Mirror-Rule Card: Three Content-System Mistakes and the Rule That Replaces Each — For every mistake you keep making, write down the rule that makes it impossible, and put that rule where the work happens, not in your head.
• The Morning Triage Card: A Claude Project That Picks Your Three Things — A daily plan is only useful if it forces a choice. Give the model your goal as well as your list, and make it hand back three things to do and a named pile of things to stop.
• The One-Move Day Card: Deciding What to Drop and Acting Once in 24 Hours — In 24 hours you may make one cut, one move and one visible trace. Anything beyond that is planning theatre.
• The One-Screen Start Card — Build the smallest thing that does one job for one person, finish it today, and only then decide what it should grow into.
• The Overnight Job Card: Handing Work to a Home Assistant Without Handing Over the House — Decide what the assistant may touch before you decide what it should do, and give every overnight job a written card that says what it may read, what it may change, and what it must never do.
• The Own-Words Pass: Writing After Claude's Text Watermark — Don't try to scrub the mark. Decide how much of the piece should be yours, do that much of the writing yourself, and say plainly what Claude did.
• The Paid-Work Ledger: Selling a Service Instead of Posting Output — Sell a specific result to a named person, use AI to deliver it faster, and keep a human check between the model and the customer.
• The Phrase Ledger: Writing Ad Copy From Reddit Threads Instead of a Brainstorm — Every line of copy has to point back to a phrase you copied word for word from a real thread and saw more than once. If you can't point to the phrase, it's a brainstorm with extra steps.
• The Plugin Build Card: Packaging One Recurring Client Job as a Claude Plugin — Package one recurring job that a named kind of client already does by hand, prove it with a demo on their own material, and charge for the setup rather than the idea.
• The Premium Ledger: Pricing AI-Augmented Work From Published Data — Price the job you already know how to value, then add only the AI premium you can evidence, and write down where every number came from.
• The Proof Ledger: Reading Solo AI Revenue Stories Before You Copy Them — Before you copy anything from a success story, put it through the Proof Ledger. Write down what the receipt actually measures, what came before it, and which part depended on things you do not have. Copy only the rows that survive.
• The Provenance Claims Card: Claude's Text Watermark and What You Can Honestly Say — Decide what you will claim about a piece of work before you send it, and base that claim on how the work was made, never on whether you think a detector would catch it.
• The Real-Blocker Ledger: Price Out Your AI Excuse — Put a pound figure on your actual use before you say the word "afford", then name whatever is still blocking you.
• The Resource-to-Skill Card: Turn Saved Guides Into Workflows Claude Runs — A saved resource only counts once it has been turned into a named workflow with a trigger, inputs and an output, and you have run it once on real work.
• The Seven-File Continuity Pack — Automatic memory is a convenience, not a record. Anything you would be annoyed to lose lives in a file you wrote or approved, and the session reads it in the same order every time.
• The Six-Question Build Gate: Deciding Whether an Idea Deserves Your Time — Building got cheap, but deciding didn't. An idea gets real time only after it has passed six written questions, and each answer has to be evidence you collected, not a sentence you or a model made up.
• The Small-Model Task Card: Pick One Boring Job, Prove It, Then Scale — Never evaluate a small model in general. Give it one narrow, repetitive task, set the pass mark before you run it, and let a hundred real examples decide.
• The Swap Ledger: A Year-On-Year Check of Which AI Tool Does Each Job — Review your tools one job at a time, against what you used a year ago, and only swap a job when you can name the specific thing that changed and you have tested it on your own work.
• The Task Ledger: Splitting Your Job Into Tasks Before AI Does It for You — Never judge your job as a whole. List last week's tasks, sort each one by what it really involves, and only defend the ones that genuinely need you.
• The Task Split and Proof Log: Four Moves for Staying Valuable as AI Improves — Stop asking whether AI will replace your job, and keep a written record of which tasks you hand over, which you direct, and which you own, then build evidence on the last two.
• The Thirty-Day Post Ledger: Deciding What to Post Next From Your Own Numbers — Judge topics and formats, never single posts, and only against a question you wrote down before opening the numbers.
• The Three-Door Check: Locking Down the Web, Skills and Connectors in Claude — Anything Claude reads on the job can try to give it orders, so decide in advance which doors are open, and keep a human on the ones that can send, spend or delete.
• The Three-Rung Build Ladder — Do not build an app until the same job has failed on a saved prompt and then on a shareable page.
• The Three-Task Model Test: Keep, Park or Skip a New AI Model — Never judge a new model on a fresh, clever prompt. Run it on three tasks you have already done, with a pass mark you wrote down before you pressed enter.
• The Three-Test Hiring Match Card — A match is only as good as the evidence you can read behind it, so test any AI recruiter on what it can show, not on what it says.
• The Three-Viewer Check for Claude Privacy — Before a sensitive detail goes into Claude, you should be able to name every person who could read it and the setting that limits each one. If you can't, the detail stays out.
• The Visibility Ledger: Turning Good Work Into Evidence Your Manager Can Repeat — Your manager can only argue for what they can state in one sentence with a number in it, so build the sentence yourself, every month, before you are asked.
• The Weekend Lane Test: Choosing an AI Freelance Side Line From Dated Demand Data — Pick a lane only from dated, sourced demand data, then run a weekend test with a pass mark you write down before you start. If it misses the mark, you drop it.
• The Weekly Handoff Ledger for Boring Work — Automate the part that repeats, keep the part that decides, and write down which is which before you build anything.
• Three Solo AI Business Models and the Fit Card for Picking One — Pick one operating model on purpose, write down what it demands of you, and judge yourself against that model, not against someone else's headline number.
• Three Tests on Your Own Work: The Model Comparison Card — Never choose a model on public rankings or a single answer. Run the same three tests on your own work, score them against criteria you wrote before you saw any output, and let the card decide.
• The Token-Multiplier Ledger: Costing a Claude Model Switch — Never cost a model switch from the price list alone; multiply the price by a token count you measured on your own prompts.
• The Two-Layer Flyer Card: Pictures from AI, Words from You — Let AI make the picture, and type every word yourself in an editor.
• The Weekly Job-Hunt Ledger for ChatGPT Work — Give the agent a standing brief and a ledger, let it do the gathering and drafting every week, and keep every decision that touches another person for yourself.

Workbench

Prompts, tools and skills you can pick up and use straight away.

• A First-Week Kit for ChatGPT: Settings, One Project, Three Prompts — Before you ask it for anything clever, set up three things (privacy, one Project, one weekly output), then run the same three prompts for a week and judge them on time saved.
• A Skill Ladder: From One Weekend of AI Tools to a Paid Service — Climb one rung at a time, and do not move up until the rung below has produced something a real person has used.
• The Job-to-Platform Table: ChatGPT Work, Claude and Perplexity Computer — Pick the platform by where the job's inputs live and where the finished file has to end up. Then give it one real job, connected to the fewest apps it needs.
• The AI Literacy Ladder: Three Rungs, One Source Each — Pick one source per format per rung, finish it, then use what it taught you on a real task before you climb.
• The Answer-First Standing Instruction: A Kit for Shorter AI Replies — Put the length rule where the tool reads it on every message, write it as what to do rather than what to avoid, and give the model a clear exit for when it genuinely needs more room.
• Anthropic's Role Plugins: Marketing, Sales, Legal, Productivity and Finance — Install one plugin for the job you do every week, connect it to one real tool or one real file, and test it on a task you have already done by hand so you can judge the output.
• The Apple HIG Review Skill: Installing It and Getting Cited Findings — Don't ask a model for taste. Give it the rulebook, make it quote the rule behind every finding, and treat anything it can't cite as opinion.
• Ask Before You Write: The Brief Interview for ChatGPT — Before any copy gets written, make the model interview you, then lock the answers into a brief it must reuse.
• The Basket Test: Voucher Codes With a Cloud Browser — A code isn't found until the retailer's basket shows the lower total. Let the AI do the tedious trying, but you check the evidence and you press "pay".
• Borrow a Design Language with Claude Design: Three Briefs — Give Claude Design a reference to work from and a list of what must not be copied. A reference without a boundary produces a knock-off; a boundary without a reference produces beige.
• Build Your Own AI Resource Library From Official Sources — A resource earns a place in your library only when it has an owner, a date and a first task you will do with it this week.
• The Carousel Brief: Set It Once, Run It Per Topic — Write the brief once, in a Claude Project, and let each new carousel be a one-line topic, not a fresh explanation.
• ChatGPT Chat, Work and Codex: The Three-Question Picker — Pick the mode by what you want back. An answer means Chat. A finished file or a task carried through means Work. A change to code means Codex. Decide before you type, because Work and Codex draw on a separate, metered allowance.
• Family Tree Research with ChatGPT: Interview, Search, Then Verify Every Match — ChatGPT can organise what you know and go looking for leads, but nobody goes on the tree as a relative until a record you have seen yourself connects them.
• The Mirror Chain: Reading ChatGPT's Memory Without Treating It as a Verdict — Treat ChatGPT's memory as a mirror of the chats it can see, not a judge of your life. Check what it is drawing on before you ask, make it show the evidence for every claim, and keep any conclusion you couldn't defend to a friend.
• ChatGPT Shorthand Codes Are Just Instructions: Four to Keep, One Stack Rule — A code is only a label for one specific instruction you could have written out in a sentence, so use the few that fix a problem you actually have, and write each one out in full at least once.
• Interview, Plan, Site, Launch: A Four-Prompt ChatGPT Work Kit — Make ChatGPT interview you before it suggests anything, review a private preview before anything goes public, and sort out the UK data-protection basics before you ask for a single sign-up.
• ChatGPT Work Tasks: Three Watchers and Two Schedules — Let Work watch and draft on its own, and keep every send, purchase and claim behind your own tap.
• Classify First: A Decision-Mentor Skill That Stops Claude Echoing You — Make Claude name what kind of decision this is before it advises, and let it use only thinking that is publicly documented for that kind.
• Claude Academy: One Course, Every Quiz, One Badge — Pick one course that matches the work you do this month, pass every quiz in it, and use what each lesson teaches on a real task before you start the next lesson.
• Answer-Mode Phrases for Claude: Red Team, Forecast, Mirror, Human, Concise — A slash in front of a word doesn't give it any power. What makes the answer change is the instruction you write after it. Write that instruction out in full, and only turn it into a real command when you've used it often enough to justify it.
• Thirty Claude Code Commands, Sorted by the Moment You Need Them — If a command exists for the job, use the command rather than asking Claude to do it. The command checks real state; Claude answering from memory doesn't.
• The Five Add-On Bench for a New Claude Code Install — Install one add-on at a time, know what each one runs on your machine, and keep only the ones you have used within a fortnight.
• The Five-Part Front-End Kit for Claude Code: Taste, Rules, System, Parts, Eyes — Give Claude Code five separate things it doesn't have by default (taste, a rulebook, a design system, real components and a way to see its own output), and use them in that order on every page.
• Seven Claude Code Commands for Undo, Planning, Memory and Context — Let commands carry the routine work. Plan before edits, write your background down once, rewind instead of asking for repairs, and check the cost and the context before they surprise you.
• Claude Design Skills: Direction, Theme and Audit in One Stack — Don't ask for "better design" in a sentence. Install skills that make the choices for Claude, one for direction, one for palette and type, one to check the result, and use them in that order.
• A Claude Project That Answers From Your Google Drive, With Citations — Claude may only answer from files it actually opened, and it names the file every time. If nothing turns up, it says so.
• Claude's Effort and Thinking Controls: When to Turn Them Up — Leave effort at the default for routine work, raise it only for tasks where a wrong answer is expensive and the reasoning can be checked, and judge the result by checking it, not by how long Claude thought.
• A Three-Prompt Claude Kit for Spotting Price and Options Volume Gaps — Claude only works on data you exported yourself, each prompt does one job, and the output is a watchlist with a stated way to be wrong, never a buy or sell call.
• Claude Prompt Labels: Define the Legend Before You Use the Shortcut — A label is a shortcut to an instruction you've already written down. Write the instruction once, in a legend Claude can see, then use the short label as often as you like.
• Claude SEO: The Free Audit Plugin, Six Commands and What They Actually Check — Install it in the right order, run the narrowest command that answers your question, and treat the action plan as a draft you check, not a verdict you obey.
• The Session Handover Note: Close Every Claude Chat with a Written Record — Before you leave a chat that mattered, have Claude write a handover note you can read, check and paste. Then put that note somewhere the next session will actually see it.
• The Claude Skill Folder Kit: Three Ways to Make and Test a Skill — Write one skill per repeated job, keep each one narrow, and test it on a real task before you trust it.
• A Claude Voice Skill Built From Your Own Writing: Niche Scan, Voice Card, SKILL.md — Describe your voice from evidence (your real posts and what already works in your niche), write that description down once as a Claude Skill, and judge the skill against a sample you held back, not against how it feels.
• CLI-Anything: Four Parts That Let Claude Code Drive Desktop Apps — Install the hub, install one ready-made wrapper, read its command list, and only then ask Claude to use it. Build your own wrapper only when the hub has nothing.
• Scan Before You Rewrite: A Four-Prompt CV Chain for ChatGPT — Diagnose the skim first, rewrite second, and only fix what the skim says is broken.
• The Data Broker Removal Kit: Find, Request, Submit, Re-check — Let AI do the finding, drafting and logging, but keep yourself in the loop for every submission, and treat nothing as removed until you have checked it yourself.
• DeepSeek Harness: Running an Open-Source Coding Agent from Your Browser — Treat DeepSeek Harness as a developer preview you test on a copy, not a replacement you point at real work. Start it read-only in spirit, check what it proposes, and widen its access only once you have seen how it behaves.
• The DESIGN.md Skill: One Style File Claude Reads Before Every Page — Write the look down once, in a DESIGN.md file, and put it inside a skill so it loads on every build. Then the AI has your fonts, colours and spacing to follow, and stops guessing.
• The DM Follow-Up Sort: Export Your Messages, Score Them, Draft the Replies — Get the conversations out of the app as a file, have an AI sort them against criteria you wrote down first, and send nothing it drafts until you have read the original thread yourself.
• The Document-First, Question-Last Layout — Put the long material at the top, the question at the bottom, and ask for quotes before conclusions.
• The Draft-Check-Finish Skill: Making Claude Hand Back Drafts, Not Final Answers — Claude's first pass is a proposal. It comes back labelled as a draft with its guesses listed, you decide, and only your decision makes it final.
• The Swap Ledger: Weighing DeepSeek Harness Against Your Current Coding Agent — Separate the harness from the model, price each one on its own, and switch only when a trial on your own repository beats your current setup.
• The Stop, Fence and Delegate Prompt Kit for Claude Fable — Give a Fable model three written decisions up front: when it stops, what it may not touch, and who is allowed to delegate. Everything else can be a plain statement of the goal and why you want it.
• Family Tree Research With Claude and Claude in Chrome, Graded by Evidence — Nobody goes on the tree until they have a source you have opened yourself, and every person carries a grade saying how sure you are.
• Five Admin Prompts for Claude, Each With a Built-In Check — Give Claude one admin job at a time, make it ask for what is missing, and make it show its working so you can check it in under a minute.
• Five Advisers and a Chair: A Council Prompt Kit — Never take one answer to a decision. Make the model argue the question from five fixed positions, make them disagree before anyone summarises, and have a chair that must name what stays unresolved.
• Five Claude Finance Skills for a First Read, Not a Verdict — Split the question into five narrow jobs, give each one a fixed checklist as a skill, and make every skill say what it could not verify. A skill gives you a first read. It doesn't decide anything.
• Five Official Claude Plugins To Install First, And What They Won't Do — Install a plugin for a job you already do every week, test it on one real piece of work, and only then add the next.
• Five Code Words, One Skill File — If you have typed the same instruction three times this week, it belongs in a Skill, triggered by a short code word, not in a notes app.
• Five Custom Slash Commands That Stop Claude Agreeing With You — A slash command is a saved prompt you wrote, so make each one demand a specific kind of output (objections, failure causes, hidden assumptions) instead of asking for "honest feedback".
• Five Free Skill Packs and the Context File That Makes Them Work — No skill pack runs on real work until it has a context file describing your business. The install takes five minutes; the context file is the bit that decides whether the pack is worth keeping.
• Five GitHub Repos for Claude Code, and the Buyer's Check to Run First — Install one repo at a time, only after you have read what it will run on your machine, and only if it fixes a problem you had this week.
• The Five-Habit Kit: Context Card, Decision Page, Objection Pass, Standing Project, Saved Skill — Three habits change the answer, two habits buy back the time. Learn them in that order, because saving a bad setup only repeats it faster.
• The Five-Job Tool Table for Saving Time — Pick one tool per job, name the job first, and automate only something you have already done by hand three times.
• Five Phrases That Change the Answer — Claude answers the question you actually asked, so ask for the job you need done (critique, plain language, a verdict, a gap check), and name it in one short phrase at the start.
• Five Pressure Prompts: Attack, Translate, Benchmark, Repeat, Patch — Never ask for "feedback" or "help". Name the job, name what a good result looks like, and name what the model must not do.
• Five Project Files Claude Code Reads Before You Type — Anything you would say twice goes in a file, and each file does exactly one job.
• The Five-Prompt Career Gap Audit — Never ask for advice until the assistant has your evidence, and never accept a conclusion until it has argued against it.
• Five Prompts For A Working Day: Audit, Rank, Shrink, Block, Debrief — Give Claude your real calendar, tasks and constraints, make it ask for what is missing, and have it return something you can act on today rather than advice about productivity.
• Five Sentences That Fix a Thin Prompt — If a new colleague with no context couldn't do your task from the prompt alone, add the one sentence they would have asked about.
• The Five-Tool Bench: Free Software to Run Before You Hire — Run one tool on one real job for one week before you pay anyone, and know in advance where the free plan stops.
• Five Tools, One Paid Deliverable Each — Pick one tool, name the one deliverable a buyer receives, fix a price before you start, and have a human check it before it leaves your hands.
• The Four-Assistant Fit Test: Matching a Job to Claude, ChatGPT, Gemini or Grok — Choose the assistant by the job's inputs and its finished output, not by its reputation. When two tools fit equally well, run the same small sample through both before you commit.
• Four Claude Code Add-ons for Cheaper Vibe Coding, Checked One by One — Install one add-on at a time, read what it will run before you say yes, and keep the one that changes where your code goes switched off unless you have a reason to use it.
• Four Claude Skills for a CV: Diagnose, Benchmark, Rewrite, Prep — Split the job into four checks that each do one thing — diagnose, benchmark, rewrite, prep — and run them in that order, so every change traces back to a finding and every number traces back to you.
• Four Design Repos: Read Before You Install — A design repo is a set of instructions or code that will shape your project, so read it, install it on a branch, and judge it by one real screen before it touches anything else.
• The Four-Prompt CV Audit: Diagnose, Close Gaps, Rebuild, Read Like a Recruiter — Never ask for a better CV; ask for a diagnosis against one specific job advert, then fix only what the diagnosis finds.
• The Four-Prompt CV Rewrite Against a Real Job Advert — Make the model read your CV against one specific job advert, as someone hunting for reasons to reject it, and never let it invent a number you can't defend in an interview.
• The Four-Trial Kit for a New Frontier Model — Test a new model on your own real work, one narrow trial at a time, and decide each trial's pass mark before you run it.
• The Free AI Course Shortlist: Pick Three, Prove One — Take few courses, finish them, and attach one piece of real work to each credential you list.
• The Free Course Pick Table: Seven Harvard, MIT and Yale Courses, One Finished — Bookmark seven, start one, and write down the date you will finish it before you open the first lecture.
• Free Tiers That Do Real Work, and Where Each One Stops — A free tier can replace a paid tool only when the job fits under its limit and you can get your work back out. Check both before you build a routine on it.
• The Free-Tier Stack: Four Tools, and Where Each One Stops — Use the free tier until it blocks a specific job, then pay for that job's tool only, never for a bundle.
• Free Harvard, Yale and MIT Courses: What Is Actually Free, and How to Finish One — Pick one course, know exactly what its free version includes and when it expires, and only then plan your weeks. One finished course is worth more than seven you've started.
• The Gather-Then-Make Bench: Seven Claude Skills for a One-Person Creative Studio — Install the skills in the order the work happens. Gather first, then make, and don't add a making skill until the gathering one before it produces something you'd actually use.
• The Google Labs Build Chain: Brand, Screen, Site, Repeat (October 2026 Check) — Treat every Google Labs tool as a loan, not a purchase. Export what you make the same day, and build the chain so any one link can be swapped out.
• The Handoff File: Moving a Long Claude Chat Into a Fresh One — Never leave a long chat until its decisions, current state and next steps are written into one file, and never start the new chat until that file is the first thing in it.
• Independent Reviewers: Three Fresh Contexts Instead of One Agreeable Chat — Never review in the context that produced the work. Hand the work to fresh reviewers who have not seen your reasoning, give each one a different job, and run them side by side.
• The Interview-First Harness: Five Places Claude and ChatGPT Keep Your Context — Interview yourself before you install anything. Build only the layers your answers ask for, starting with one page of standing instructions, and add a layer only when the same gap shows up three times.
• The Lean Upload Kit: Four Moves That Keep Claude's Context for Your Work — Upload the least material that still carries the meaning, in the plainest format that holds it, and say it once somewhere it persists.
• The LinkedIn Drafting Kit and the Humaniser Pass — Let the pack draft, but run every piece through the humaniser and your own voice before it goes anywhere near LinkedIn, and never let any skill post, comment or message on your behalf.
• A Live Money Dashboard From Three Free Tools — A finance dashboard is only useful if you can change one number and watch the gap move. If it can't recalculate in front of you, it's a report, not a tool.
• The MCP Connection Check: Reading /mcp Before You Trust a Tool — Before you rely on a connected tool, look at its status, and read the status word, not just the fact that a list appeared.
• MCP Connectors: Plugging the Model Into Your Tools Instead of Pasting — If you paste from the same system more than twice a week, connect it instead, and give the connection only the permissions the job needs.
• The Net-Worth Starter Kit: Free UK Tools and Two Prompts for Building Wealth — Track net worth, not salary, and add one small income stream at a time rather than chasing a big one.
• Your First No-Code AI Agent: The One-Job Card — Write the job on a card first, then choose the cheapest tool that can do exactly that job, and keep a human on every step that sends, spends or deletes.
• One Balance, Many Tools: Connecting an Agent to Actionway — Connect one gateway, cap the balance you load into it, and make the agent quote a cost before it spends.
• One Brief, One System: Getting AI to Make Brand Pieces That Match — Make the system first, then make every piece from it, in one place. A single prompt can start a brand kit, but only if it produces a written brand system you check before anything gets built.
• One Health File an AI Can Read: Building Your Own Health Ledger — Keep one plain, dated file of your readings, results, medicines, notes and appointments, and only ask the AI questions about that file. Without the file you're getting guesswork.
• The One-Offer, One-Channel Income Chain — One offer, one channel, one paying customer, one 90-day plan. If a prompt hands you a list, send it back.
• The One-Page Income Ledger: Every Stream in One View — Give every pound one category, one date and one source before you try to analyse anything.
• One Skill Per Department for a Solo Business — Give each department one skill you have read, tested on one real task, and kept only if the output was better than your plain prompt.
• The One-Tool-Per-Job Ledger: Five Jobs, Five Named Owners — Every recurring job gets exactly one named tool, and each tool gets set up once so it stops asking you to explain yourself.
• Three Open-Source Scrapers: ScrapeGraphAI, Scrapling and Agent Reach — Decide what kind of page you are scraping and how often before you install anything, and give every tool its own virtual environment.
• The Paid AI Stack: Two Brains, Two Time-Buyers and a Monthly Cancel Test — Pay for one tool to think with, one to check against, and only those time-savers you can name the hours for. Everything else has to pass a cancel test every month.
• Pattern, Depth, Premortem: Three Labelled Prompts That Change a ChatGPT Answer — The capitalised word is a label, not a switch. ChatGPT has no hidden command called AUTOPSY. What changes the answer is the instruction you write after the label, so write that part properly.
• The Two-Photo Colour Check: Getting a Usable Palette From Selfies — Treat the first answer as a hypothesis, make the assistant state its confidence and what it could not judge, then test it against a second photo and a real garment before you spend a penny.
• The Photo-to-Listing Pipeline: Pricing, Writing and Bulk-Uploading Household Items With AI — Let AI do the typing, not the judging. It drafts identifications, prices and listings; you check prices against real sold listings, and you only upload a file built on the platform's own template.
• The Prompt Trim Audit for Claude's 5-Series Models — On the Claude 5 generation, delete the instructions you wrote to make older models try harder, keep the ones that say what you want and why, and test the trimmed version before you trust it.
• The Pushback Kit: Four Prompt Blocks That Make Claude Argue Before It Answers — Never ask Claude whether you are right; assign it a specific adversarial job, with a defined output, before it is allowed to answer.
• Read It Like a Recruiter: Six Prompts That Audit Your CV Before Anyone Else Does — Make Claude read the job first, then the CV, then argue against you, and only rewrite what the evidence can support.
• Scan a Skill Before It Runs: A SkillSpector Kit — Scan every skill you did not write before it goes into your skills folder, run the free static scan first, and treat the report as a list of places to look, not a verdict.
• The Scene Card: Free AI Roleplay for the Conversations You Actually Need in Another Language — Practise one named scene at a time, with a clear goal and a set way of being corrected. If you haven't decided both before you start, you're making conversation, not practising.
• ScrapeGraphAI: The Free Local Route and the Paid Hosted Route — Decide which route you are on before you install anything. The local library is free but you have to run it yourself. The hosted MCP server needs no setup but spends credits. In both cases, check the output against the page.
• Screenshot to Code: Four Routes from a Page Picture to Editable Code — Treat a screenshot-to-code result as a first draft of one page's layout, pick the cheapest route that gets you that draft, and spend your real effort on the editing afterwards.
• Seedance 2.5: Three Routes In and What the Free Access Covers — Check the offer before you check the output. Find out which plan, which resolution and which end date apply, then spend a small, fixed budget on one test shot of your own before you commit to anything.
• The Self-Check Prompt Kit: Make Claude Test Its Answer Before You See It — A self-check only works when it names what the answer is being checked against. "Double-check this" is a mood; "check it against these criteria and the text I gave you" is a test.
• The Session Starter Brief: Goal, Context, Standard and a Question Rule — Before you ask for anything, give Claude four things in one block (goal, context, standard, and what to do when something is missing), then let it tell you what it still needs.
• Seven Claude Commands Sorted by Mechanism: Three Real Switches, Four Sharper Instructions — Know which of your seven are switches and which are instructions, and only expect a switch to behave the same way every time.
• The Seven-Day Model Log: Testing a New Claude Model Before You Trust It — Write the tasks and the pass mark before day one, log every real use as it happens, and give a verdict only from the log.
• Seven Opening Lines That Set How Claude Answers — Decide what kind of answer you need before you ask, and say so in the first line of the chat.
• Seven AI Tools, One Job Each: The Stack Checked in October 2026 — Give every tool in your stack exactly one job, plus a handoff to the next tool. If you can't name a tool's job in one line, it hasn't earned its place.
• The Six-Trap Launch Audit for AI-Built Apps — Audit the defaults before launch, read-only, with evidence from your own code — then fix the smallest thing that closes each gap.
• The Skill Gatekeeper: Read It Before You Install It — Nothing gets switched on until you have read the folder, in a fixed order, and can say in one sentence what it does and what it touches.
• The Skills-to-Roles Kit: Building Your Own Career Pivot Agent for Free — Break your work into tasks and evidence first, match those tasks to roles second, and only trust a suggested path once a real job advert backs it up.
• The Standing Disagreement Instruction: Making Claude and ChatGPT Tell You When You're Wrong — Put the instruction to disagree where it loads before every chat, not in the chat. Then test it with a claim you know is wrong before you trust it with one you don't.
• The Stranger Read-Through Kit for Prompts — Before you send a prompt that matters, hand it to a stranger, human or model, and fix every place they stop or guess.
• Switch Codes: Turning Off ChatGPT's Flattery, Padding and Hedging — Name the behaviour you want switched off, not the virtue you want switched on. Define each switch once, then trigger it with a short code.
• The Task-by-Task Job Audit: Sorting Your Work Into Hand Over, Speed Up and Keep — Audit tasks, never the job title, and sort each task into one of three buckets (Hand over, Speed up, Keep) before you touch any tool.
• Ten Context Files That Replace the Blank Chat Box — Write the standing context once, as plain files, and load it every time, so each chat starts from "who you are, what you sell and what is live" rather than from nothing.
• The Access Brief: Connect First, Prompt Second — Connect the sources first, then give a short brief that names the outcome, the evidence to read and the limit on what it may change.
• The Application Test for AI Courses — Judge a course by what you will have produced with your own material by the end of each lesson, not by what you will have watched.
• The Completeness Brief: Three Prompts That Stop Half-Finished Work — Demand completeness inside a fence you drew, one finishable unit at a time, and make the model report what it left out.
• The Daily Stack Order Table: Five Slots, One Tool Each — Give every tool one slot, one job and one hand-off to the next slot, and delete anything that doesn't fit a slot.
• The Four-Lever Avoidance Audit: Automate, Delegate, Cut, Then Plan — Check the three cheaper levers (automate, delegate, cut) before you reach for discipline, and when discipline is genuinely the answer, write it as a single if-then plan rather than a pep talk.
• The Negative Instruction Rewrite Kit for Claude — For every "don't" in a prompt, write down the thing you want in its place, and keep the "don't" only if it guards a real line and carries a reason.
• The Seven-Prompt Money Clarity Kit — Give Claude your real numbers in a fixed order, and make every prompt end in one decision you can act on this week.
• The Three-Lies Block: A Paste-In Filter for Honest AI Answers — Name the failure modes in the prompt, give the model explicit permission to commit them less, and make it show its working so you can check.
• The Three-Prompt Gap Finder: Complaints First, Ideas Last — Never ask AI for ideas; ask it for evidence of people already being annoyed, then try to kill whatever survives.
• Three AI Skills to Practise First: Briefing, Checking, Applying — Learn to brief the model, learn to check what comes back, and only then learn to point both at a job you are already paid to do.
• The Three-Filter Prompt Stack: Demand, Attack, Moat — Never let the model judge your idea until it has been made to find evidence against it, and never build until you have a demand signal, a surviving attack and a reason the thing cannot be copied in a weekend.
• Three Gmail Prompts for Claude: the Sweep, the Ask Finder and the Voice Draft — Give Claude a job with a filter, not an inbox to describe. Each prompt below tells it what to ignore, what counts as "needs you", and what shape the answer must take.
• The Three-Input Website Redesign Prompt — Give Claude three inputs before you ask for a single pixel (your real content, your visitor and their one job, and your design limits), then work in three rounds, not one.
• Three Prompts for Claude Drafts That Sound Like You — Give Claude evidence of your voice and your own thinking, make it audit its draft against both, and never let it supply the opinions.
• The Three-Slot Toolkit: One Thinker, One Reader, One Notebook — Give every tool one job, cap the list at three, and replace a tool only when it fails its job twice.
• The Three Tagged Examples Kit: Steering Claude by Showing, Not Describing — Show three examples, each wrapped in tags and each different from the others, and keep instructions for the things an example can't show.
• The Three-Tier Test Card: Sol, Terra or Luna for Your Own Work — Run one real job of yours through all three tiers against a pass mark you wrote down first, and pay for the cheapest tier that passes.
• The Two-Pass Inbox Sweep for Forgotten Credits and Vouchers — Run it as two separate passes. Pass one only finds and lists what your inbox says you were given. Pass two checks each item at the source. Nothing counts as money until a company's own site or account shows a balance.
• The Two-Photo Try-On Prompt for Checking an Outfit Before You Buy — Give the tool two clean photos and one narrow instruction, change only the garment, then treat the output as a style preview, never as a fit check.
• Two-Word Prompts With a Written Expansion: An 18-Card Deck for Claude — Two words make a good handle, but they're a poor instruction. Write down once what each handle should make Claude do, then load that written version every time you use the two words.
• VidRush Documentary Briefs: The Four-Pillar Prompt and the Small-Edit List — Write the brief as if you were briefing a human researcher. Check the Quote Statement before you approve it. Then fix the result in small, specific edits, never one big "make it better".
• Let Gemini Watch the Video for Claude: The Watch Skill Kit — Let a model that can actually see the video do the watching, then have Claude work from its timestamped notes — and treat those notes as evidence to check, not gospel.
• Seven Claude Prompts Built on Patrick Winston's "How to Speak" Lecture — Use the lecture as a checklist and Claude as the person who applies it. Run one prompt for one job at a time, on your real material, and keep the judgement calls for yourself.

Getting Started

Your first weeks with AI, set up properly.

• Your First Day With Claude: The Four Things To Set Up Before You Type Anything — Four setup decisions, in this order, do more for your first week than any amount of exploring the interface.
• Free vs Paid: What Actually Changes When You Upgrade — Paid plans mainly change how much you can do and which models you can reach, not how good any single answer is capable of being.
• The Onboarding Mistake: Treating Claude Like A Search Engine — A search engine gives you one shot at one query; a conversation is meant to be worked, corrected, and built on — and treating it like the former throws away most of what it's good at.
• Reading The Model Picker: What Each Tier Is Actually For — The model picker is a task-fit choice, not a quality ladder — match the tier to the difficulty of the task in front of you, not to whichever one sounds most impressive.
• The Five-Minute Setup That Saves You A Week Later — Spend five minutes once, writing down what you'd otherwise re-explain every session, and Claude's memory carries it forward from there.
• Why Your First Conversations Should Be Boring — Practise on something low-stakes and checkable before you trust it with something that isn't — the goal of your first conversations is learning to judge answers, not getting a good answer out of the first one.
• The Difference Between A Chat And A Project — A plain chat is for something bounded and done today; a project is for anything you'll come back to — pick based on whether tomorrow's you needs today's context.
• Setting Expectations: What AI Gets Right On The First Try, And What It Never Will — Calibrate by task type, not by how confident the answer sounds — confidence and correctness are not the same signal here, and the sooner you stop reading tone as a proxy for accuracy, the better your judgement gets.
• The One Setting Most New Users Never Touch — Custom instructions apply to every conversation from then on, so five minutes spent there once saves the same correction being repeated in dozens of separate chats later.
• Choosing Your First Real Task — Pick a first real task you can check, not the one you most want solved — verifiability, not importance, is what makes a task a good starting point.
• The Onboarding Checklist Nobody Gives You — Five setup decisions, made once, do more for you than a month of "tips and tricks" posts.
• Why "Just Ask It Anything" Is Bad Advice For Week One — An unlimited invitation is worse advice than a narrow one — a scoped task in week one teaches you more, faster, than an open one does.
• What A Connector Actually Does (And Why Most People Skip This Step) — A connector isn't magic access to everything you own — it's a scoped permission to a specific tool, and understanding the scope is what makes it safe to use, not avoiding it entirely.
• The Beginner Trap: Judging AI By One Bad Answer — One bad answer is a diagnosis to run, not a verdict to reach — most bad first answers trace back to a specific, fixable cause, not to the tool being unreliable in general.
• Your First Week, Day By Day — The order matters more than the list — each day's step is designed to make the next day's step land better, not just to fill seven days with tasks.
• What "Context Window" Means And Why It's The First Thing To Understand — A context window is the amount of the current conversation the model can actually see at once — once something falls outside it, it isn't remembered within that chat, it's gone from view entirely.
• The Difference Between Asking And Delegating — Asking gets you an answer to bring back into your own work; delegating hands over the work itself, including the parts you didn't explicitly specify — and it needs a different kind of instruction to go well.
• Setting Up Your "About Me" File Properly — An "about me" file should hold what you'd otherwise repeat across many conversations, and nothing else — that's the only test for whether something belongs in it.
• The Three Questions To Ask Before Any New AI Tool — Ask what it costs, what it does with your data, and what it's actually for, before you create the account — not after.
• Why New Users Over-Explain (And How To Stop) — Say the outcome you want first, in one sentence, then add only the context that changes the answer.
• The Getting-Started Guide For People Who Hate Getting-Started Guides — Do the task first, and only pick up the two or three habits that actually save you time, after you've already seen what you're dealing with.
• What To Do In Your First Failed Conversation — A bad answer is information for the same conversation to fix, not a reason to start a new one.
• The Real Reason Beginners Quit After Two Days — Most early quitting is an expectations problem, not a capability problem — and expectations are the cheaper thing to fix.
• Reading An AI Model's Release Notes Without Getting Lost — Skip the benchmark scores and read for three things only — what changed that you'll notice, what got deprecated, and what it costs.
• The One-Page Cheat Sheet For Absolute Beginners — One page, five sections, nothing on it you'd need a second page to explain.
• Setting A Weekly "AI Practice" Habit That Actually Sticks — A habit that isn't tied to a fixed time and a specific, checkable output isn't a habit yet — it's a hope.
• Why You Should Pick One Tool Before Comparing Five — Pick one tool that plausibly fits, commit to it for a real task over a real week, and only compare once you know what you're actually comparing against.
• The Beginner's Guide To Saying What You Actually Want — Describe the finished thing you want to be holding, not the subject you want it to be about.
• What Happens To Your Data When You Start Using AI Tools — Three specific questions answer almost everything that matters, and each one has a findable answer — you don't have to guess or assume.
• The 20-Minute Setup That Makes Every Session After This One Faster — Twenty minutes, done once, in a fixed order, gets every habit this library recommends separately into place at the same time.

Claude Mastery

Projects, memory, context and the features most people skip.

• The Context Window Is A Budget, Not A Wall — Treat the context window as a spending budget for this session, not a hard wall you're trying not to hit.
• Why Your Best Conversations Have A Shape — A good conversation isn't luck — it has three deliberate phases, and skipping the first or the last is what makes the middle feel messier than it needed to be.
• The Difference Between A Chat And A Project (Claude Edition) — A Project is a standing memory for one piece of work, not a folder — put the facts that don't change conversation-to-conversation into it once, and every chat inside inherits them for free.
• Reading Claude's Own Settings Page Properly — Every toggle on the Settings page changes one identifiable thing about how Claude behaves — read it as a set of levers, not a one-time checklist, and revisit it when behaviour changes.
• The Memory Feature: What It Remembers, What It Forgets, And Why That's Deliberate — Memory is opt-out by category and editable by you — it's a working notebook it keeps for your benefit, not a surveillance log, and treating it as either magic or menace means missing how to actually use it.
• Writing An "About Me" File Claude Actually Uses — An About Me file should be a short, labelled reference document, not prose about yourself — structure beats sentiment every time it's actually used.
• When To Start A New Conversation (And Why More People Should) — A conversation should track one piece of work, not one calendar week — when the topic changes, the conversation should change with it.
• The Three Claude Surfaces, And When Each One Wins — Web, desktop, and terminal are built for different shapes of work — pick the surface that matches the work, not the one you happen to have open.
• What Claude Code Is For, If You've Never Written Code — Claude Code is for anyone who wants Claude working directly with real files and real folders, not just chatting about them — the name is about what it operates on, not a requirement that you can already program.
• The Terminal Isn't Scary: A Non-Coder's Guide To Claude Code — You don't need to know terminal commands to use Claude Code well — you need to know how to describe what you want in plain language and read what it proposes before it acts.
• Projects vs Plain Chats: A Decision Rule, Not A Preference — The decision isn't taste, it's a single test — will you come back to this same context three or more times? If yes, build a Project; if no, a plain chat is not the lesser option, it's the correct one.
• The One Instruction That Fixes Most Bad Outputs — Ask for the reasoning before the answer, not after — a wrong plan is cheap to redirect; a wrong finished answer is expensive to unpick.
• Why Claude Sometimes Says No — A refusal is data about your phrasing or your framing, not a verdict on your intentions — read it for what triggered it, and adjust that specifically, rather than repeating the same request more forcefully.
• Artifacts, Explained For People Who've Never Used One — An artifact is a standalone, editable version of something you asked for — treat it as the actual deliverable, and the chat as the conversation about it, not the other way round.
• Turning A Conversation Into Something You Can Reuse — The valuable part of a good conversation usually isn't the output, it's the prompt that produced it — extract that prompt deliberately, the moment you notice the result was right.
• The Weekly Usage Reset: What It Actually Means For How You Plan Work — Usage limits on a weekly cycle behave like a weekly budget, not a countdown to zero — the useful move is planning around the reset, not reacting to running low.
• Reading A Model Card Without An Engineering Degree — Read a model card for what changed and where the stated limits are, not for a single benchmark score to compare against last time.
• Fast Model vs Flagship Model: A Simple Rule For Which To Reach For — Reach for the fast model when the cost of being wrong is low and easily checked, and the flagship model when the cost of being wrong is high or hard to check — not by default habit either way.
• The Cost Of Re-Explaining Yourself Every Session — Anything you've explained the same way more than twice is a cost you're paying repeatedly for no reason — it belongs in memory or a Project, not in your fingers.
• Claude's Tone Settings: Making It Sound Like You, Not Like A Brochure — Show it real examples of your own writing before you describe your tone — examples are instructions a description can't be.
• The Honest Case For Starting Over Instead Of Fixing A Bad Thread — If you've corrected the same misunderstanding twice and it's still recurring, the thread itself is the problem — starting fresh with what you now know is usually faster than a third correction.
• What A Connector Can See (And What It Can't) — A connector only sees what you ask it to look up, in that conversation, at that moment — it is a fetch-on-request tool, not a background watcher.
• Giving Claude A File vs Describing It — If the document exists as a file, upload it — don't summarise it into the prompt and hope the summary carried what mattered.
• The Difference Between Summarising And Understanding — A summary tells you what the document says; it doesn't tell you whether you could defend, apply, or challenge what's in it — that's a different check, and it's on you to run it.
• Why Long Documents Need A Different Prompting Style Than Short Questions — A short question needs a sharp instruction; a long document needs a scoped one — tell it where to look and what job to do with what it finds, or it will guess at both.
• Claude For Research: A Workflow, Not A Single Question — Treat research as a sequence of separate passes with different jobs, not one question that's supposed to do everything at once.
• The Session You Should Never Delete — Keep one running conversation per ongoing project, and treat it as a working log, not a chat you'll eventually clear.
• Reading Claude's Citations And Sources Properly — A citation is a claim about where information came from, and like any other claim it can be wrong — reading it properly means checking it, not just noticing it's there.
• The Two-Pass Rule: Draft, Then Ask It To Attack Its Own Draft — The first draft is a starting position, not a result — the second pass, where you make it attack its own work, is where the real quality gets found.
• What "Hallucination" Actually Means, In Plain Terms — A hallucination isn't a glitch you'll notice — it's a normal, expected output that happens to be wrong, which is exactly why catching it is your job, not the tool's.
• Claude On Mobile: What's Actually Different, Not Just Smaller — Treat mobile and desktop as two related but distinct surfaces — check what a given task actually needs before assuming your phone can do everything your laptop can, or that it can't.
• The Settings Most People Never Change (And Should) — Default settings are a starting point chosen for someone else's habits, not a decision made about yours — a short, occasional audit is worth more than reacting to the one setting you happen to trip over.
• Building A Reusable Prompt Library Instead Of Reinventing Every Time — A prompt that worked well once is worth saving deliberately, as a reusable piece of infrastructure — not left to be rediscovered by accident in old conversation history.
• Why Vague Requests Get Vague Answers — A vague request gets a vague answer because there was nothing specific to aim at — the fix is shape, not volume.
• Claude For Meetings: Before, During, After — A meeting has three separate jobs attached to it — preparing, capturing, and following up — and each needs a different kind of prompt, not one generic "help with my meeting" request.
• The Difference Between Asking For An Answer And Asking For A Method — Asking for an answer gets you a conclusion you have to take on faith; asking for a method gets you a way of deciding that you can check, reuse, and disagree with on the merits.
• Handling Sensitive Documents: A Practical, Non-Paranoid Checklist — Sensitive documents need a specific, quick set of checks before upload — not blanket avoidance and not blanket trust.
• What Changes When Anthropic Ships A New Model — A new model is a hypothesis about improvement, tested on your own actual tasks, not a fact to be accepted from the release notes.
• The Habit Of Asking "What Would Change Your Answer?" — Instead of asking whether an answer is right, ask what would change it — a recommendation that can't name the fact that would flip it is closer to a guess with good formatting than to a considered view.
• Claude For Teams: Shared Context Without Shared Chaos — A team gets value out of Claude in proportion to how much of its context lives in a document everyone can point Claude at, not in how many people happen to be using it.
• Why "Make It Better" Is The Least Useful Instruction You Can Give — "better" is not a direction, it's an admission that you haven't decided what's wrong yet — and the fix is to name the dimension, not repeat the instruction.
• The Real Difference Between Claude And A Search Engine — A search engine finds documents that already exist and hands you the ranking; Claude generates a new answer from a model of language and reasoning, and doesn't have a source list behind it unless you've explicitly given it one or it has used a search tool to look something up.
• Reading A Long Claude Response Efficiently — Read a long response for its structure first and its sentences second — skim the shape before you commit to the words.
• The One Habit That Separates Casual Users From Power Users — The habit that separates casual use from getting real value out of Claude isn't a prompting trick — it's reviewing the output before you use it, every time the output is going to do something in the world.
• Claude As A Second Opinion: A Format That Actually Works — A second opinion only works as a genuine check if you withhold your own conclusion until after you've asked for one — the moment Claude knows what you've decided, it's reviewing your decision, not forming its own.
• What Goes Wrong When You Paste In Everything At Once — A single giant paste asks Claude to guess what matters in your input; chunking the input by purpose tells it, which is the difference between a flattened summary and a useful one.
• The Difference Between A Good Prompt And A Good Brief — A good prompt reads well once; a good brief still works when someone else picks it up next week and asks a question you didn't anticipate.
• Claude For Decisions: Borrowing The Board's Evidence Ledger For Your Own Chats — Label your inputs before you ask for a recommendation, and the recommendation gets dramatically more useful — you don't need our full advisory-board product to do this, just its opening move.
• Why Screenshots Are An Underused Input — When the problem is what something looks like, a screenshot carries the information a paragraph is trying to approximate — send the picture, not the description of the picture.
• The Weekly Review: Auditing What You Asked Claude To Do, And What It Actually Did — A short weekly look back at what you actually asked for, and what actually came back, catches drift that no single conversation will ever show you.
• Claude For Writing In Your Own Voice — Real writing samples teach voice far better than instructions describing it — show, don't tell, applies to prompting exactly as it does to writing.
• The Difference Between Editing And Rewriting — Editing preserves the structure and mostly the wording and fixes what's broken in place; rewriting starts over from the intent and produces new wording throughout — decide which one you want before you ask, because the instruction that gets you one will actively get in the way of the other.
• What A "Thinking" Or Reasoning Mode Actually Changes — A reasoning mode changes how much visible working-through happens before the final answer, which helps most on problems with real internal steps to get wrong — it doesn't uniformly raise the quality of every kind of request.
• Claude For Learning A New Subject — Claude is far more useful as a tutor that questions you than as an encyclopaedia that explains at you — the mode most people miss is the one where it checks whether you actually understood, rather than just telling you again.
• The Habit Of Asking For Three Options, Not One — Ask for three genuinely different options before you judge any of them — a single answer can only be accepted or rejected, never actually compared.
• Claude's Refusals Aren't Random — A refusal is a response to something specific in the request — find what triggered it before you try to work around it.
• Building A Personal Style Guide Claude Actually Follows — A style guide only works if it's a document Claude can be pointed at, not a memory it's meant to infer from past chats.
• The One File Every Claude Project Should Have — A project needs one living brief that gets updated as things change, not a chat transcript you hope to remember to scroll back through.
• Claude For Comparing Documents — Tell Claude what dimension to compare on before it compares — an unscoped "what's different" misses the differences you'd actually act on.
• What Changes When You Switch From Casual Use To Daily Work Use — Daily use needs structure that casual use never required — the same loose habits just cost more when you repeat them constantly.
• The Difference Between A Skill And A One-Off Prompt — The moment you're reconstructing the same request from memory for the third time, it's stopped being a one-off — and it's worth formalising into something reusable, not repeating from recall.
• Claude For Planning A Project — A real plan needs a sequence, an owner, and a definition of done for each step — a bullet list of good intentions isn't one of those things.
• Reading Usage Limits Like A Budget, Not A Countdown Clock — A usage limit behaves like a budget you allocate, not a clock you race — spend it deliberately on what matters, not reflexively on whatever's in front of you.
• The Two-Minute Audit Before You Trust A Claude-Written Number — Any number you're about to act on gets a two-minute check before it gets used — precision in presentation is not evidence of accuracy in the number.
• Claude For Negotiation Prep — Rehearse the other side's argument before you rehearse your own — you can't prepare a response to a position you've never had to make yourself.
• Why "It Got It Wrong Once" Isn't A Verdict — One wrong answer is an anecdote, not a pattern — the useful thing is a log across many uses, not a verdict from one.
• Claude As A Drafting Partner, Not A Ghostwriter — A draft is a starting position for your judgement to act on, not a finished piece waiting for your approval — if you can't say what you changed and why, you didn't actually draft it.
• The Settings That Actually Affect Privacy — A handful of settings do the real privacy work — find those first, and treat the rest as secondary.
• Claude For Big Decisions: Slowing Down On Purpose — The size of the decision should set the pace of the session, not the other way round — a big decision deserves a session that's deliberately slower than the conversation naturally wants to be.
• The Claude Habit Worth Building Before Any Other — Review what Claude gave you before you use it, every time, as the one habit that catches everything else — before you build any other habit, build this one.

Skills & Agents

Reusable skills and agents that do real work.

• What A "Skill" Actually Is — And Why The Word Undersells It — A skill is a written procedure with a stated point and stated limits — closer to a checklist you'd hand a new employee than a feature you switch on.
• The Difference Between A Skill And A Saved Prompt — A saved prompt is a request you'll reuse; a skill is a procedure with stated triggers, steps, and guardrails — build the second only once the first isn't enough.
• When To Build A Skill, And When You're Just Procrastinating On The Actual Task — Build the skill after you've done the task by hand at least once this cycle, not instead of doing it — if the task is still undone, you don't have a skill problem yet, you have a doing-the-task problem.
• Your First Skill Should Be Boring — Your first skill should automate something small, repeated, and low-stakes — the goal of skill one is learning the shape of a good skill, not solving your biggest problem.
• The One-Rule Pattern: Why Every Good Skill States Its Point First — A skill should state its point in one or two sentences before it states anything else — if you can't compress what the skill does into a single sentence, you don't yet understand the skill well enough to write it.
• Writing A Skill Nobody Else Can Misuse — A skill that can be misused hasn't been finished — the scope and boundary lines are as much a part of the skill as the steps are, and they need writing down, not assuming.
• The Difference Between An Agent And A Skill — A Plain Distinction, Finally — A skill is a written procedure; an agent is something that carries out steps with a degree of autonomy, often using a skill as part of how it works — one is the recipe, the other is the cook.
• What MCP Actually Connects, In Non-Technical Terms — MCP is a standard plug shape that lets an AI assistant talk to an outside tool or service in a structured way — it's the connector, not the capability, and the capability is only ever as good or as risky as what's on the other end of the plug.
• The Skill You Shouldn't Build — A task earns a skill by being frequent, consistent, and slower by hand than the build costs to make and maintain — miss any one of those three, and the sensible move is to just do the task.
• Testing A Skill Before You Trust It With Anything Real — Run a new skill on low-stakes, checkable cases before you trust it on anything that matters — a handful of successful test runs is the minimum evidence, not a formality.
• The Maintenance Tax Nobody Mentions: Skills Rot As Tools Change — Every skill you build carries a maintenance tax for as long as it exists — the question isn't whether you'll pay it, it's whether you've budgeted for it or you're paying it unknowingly in silently bad output.
• Sharing A Skill With Your Team Without Sharing Your Bad Habits — A skill built for one person and a skill built for a team are different documents — sharing yours as-is usually means sharing your blind spots along with your shortcuts, and that needs a deliberate rewrite pass, not a copy-paste.
• The Difference Between Automating A Task And Automating A Decision — Automating a task speeds up something you'd have done the same way regardless; automating a decision replaces judgement — the second needs far more scrutiny than the first, and treating them the same is how a fast, useful skill turns into a quietly bad one.
• Reading Someone Else's Skill Before You Install It — Read a skill before you install it, not after it misbehaves — a five-minute read catches the large majority of problems worth catching, and it's cheaper every time than debugging a bad output afterwards.
• What A Marketplace Skill Actually Promises (And What It Doesn't) — A marketplace listing tells you what a skill claims to do and how many people have used it — it does not tell you that the skill is correct, current, safe for your specific setup, or maintained going forward, and those are separate questions you still have to ask yourself.
• The Skill That Pays For Itself In One Use vs The One That Never Will — Work out the break-even point before you build, not after — a skill needs to save more time across its life than it cost to build and maintain, and that sum only comes out right if you're honest about both sides of it.
• Building A Skill Around A Repeated Mistake, Not A Repeated Task — If you keep making the same kind of mistake across otherwise different tasks, build the skill around catching that mistake specifically — a targeted check applied broadly beats a broad skill that happens to include a check.
• The Guardrails Section Is The Most Important Part Of Any Skill You Write — Write the guardrails section before you consider the skill finished, and write it by asking "what's the worst plausible way this gets misused or goes wrong," not "what should I disclaim."
• Why Most People's First Skill Is Too Ambitious — The size of your first skill idea is not the problem — trying to build it whole, in one pass, before you've built the muscle on anything smaller, is.
• The Difference Between A Workflow And A Skill, When You Actually Need Both — A skill is one reusable procedure with a single point; a workflow is the ordered sequence that decides which skills run, in what order, and what happens between them — most real processes need both, and conflating them is what makes either one hard to maintain.
• Naming A Skill So Future You Understands It In Six Months — Name a skill for the version of you with no memory of building it — specific enough to identify what it does and when to reach for it, without opening the file.
• The Skill Version Nobody Updates — And What Breaks When They Don't — A skill without a version number and a one-line changelog is a skill whose copies will silently drift apart — the fix you ship only exists where someone knows to go and get it.
• What Happens When Two Skills Disagree — A disagreement between two skills is a specification problem, not a quality problem — treat it as evidence that their boundaries overlap before you treat it as evidence that one of them is wrong.
• Building An Agent That Reports Instead Of Acting — The Safer First Version — Build the reporting version first — same analysis, same recommendation, but it tells you what it would do instead of doing it — and only promote to acting once the reports have earned your trust.
• The One Question To Ask Before Giving Any Agent Write Access — Before granting write access to anything, ask "what's the cost if this happens once, on the wrong input, with nobody watching" — if you can't answer that cleanly, the agent isn't ready for write access yet.
• Skills For Solo Operators vs Skills For Teams — Decide who else will run this skill before you decide how to write it — a skill built for one person's head and a skill built for a team's shared understanding are different documents, not the same document at different lengths.
• The Difference Between A Skill's Trigger And Its Actual Job — A skill's trigger describes when it should start; its job description describes what it's actually for — confuse the two and you'll keep patching the wrong one.
• Retiring A Skill Properly Instead Of Letting It Quietly Rot — A skill that no longer earns its place needs an actual retirement, with a record of why — leaving it in the library unused is not a neutral choice, it's a decision to let the next person find it by accident.
• The Real Cost Of A Marketplace Full Of Skills You Never Read — Every skill you install without reading is a skill you're trusting blind — and a library full of them isn't a capability boost, it's an audit debt you haven't paid yet.
• Building A Skill Around The Task You Dread Most, Not The One That's Easiest — Build your first skill around the task you actively put off — if building it feels uncomfortable because the task is messy or high-stakes, that discomfort is the signal you're pointed at the right target, not a reason to pick something easier.
• What A Good Skill Description Actually Does For You (Beyond The Obvious) — A skill description isn't documentation of what the skill does — it's the thing that decides whether the skill fires correctly, whether anyone else can safely reuse it, and whether you'll trust it six months from now, so write it for those three jobs, not just the first one.
• The Difference Between Delegating And Abdicating — Delegation means you've defined when you'll check back in; abdication is delegation with that part left out — and if you can't name the check-in point before you hand the task over, you haven't delegated it, you've abandoned it.
• Auditing Your Installed Skills Once A Quarter — What To Keep, What To Delete — Review your installed skills on a fixed cadence, not when something breaks — a quarterly audit catches rot before it costs you anything.
• The Skill That Should Never Auto-Trigger — If a skill's action can't be undone, it doesn't get to auto-trigger, no matter how reliable it's been — reliability is a track record, not a substitute for the specific moment a human looks at this one before it happens.
• Writing Skills For Non-Technical Teammates — A skill built for a non-technical teammate needs one extra step engineers routinely skip — writing down what it looks like when it's wrong, in plain language, before anyone else ever runs it.
• The Difference Between A Skill's Happy Path And Its Failure Mode — A skill isn't done when it handles the case you designed it for — it's done when you know, specifically, what it does when that case doesn't hold, and whether that failure is loud or silent.
• What "Tool Access" Actually Means When You Grant It To An Agent — "tool access" is never one thing — it's a bundle of what the tool can read, what it can change, how often it can be called, and what it can do without asking again — and granting it without unpacking that bundle means you've agreed to all four without reviewing three of them.
• Building A Skill From A Support Ticket Pattern, Not A Hypothetical — Build the skill from an actual pattern of real support tickets, not from a guess at what the pattern probably looks like — the gap between the two is usually where the skill turns out not to help.
• The One Metric That Tells You A Skill Is Actually Working — The one metric that actually tells you a skill is working isn't how often it runs or how fast it feels — it's how often its output survives contact with someone who checks it against the truth, and if you're not measuring that, you don't actually know whether it's working.
• Why Copying A Skill From The Internet Without Reading It Is A Bad Habit — A skill copied without being read isn't a shortcut, it's a decision to trust a stranger's judgement over your own, made without knowing what that judgement actually was.
• The Difference Between An Agent's Scope And Its Permissions — Scope is what you intend the agent to do; permissions are what it's technically able to do — write both down separately and check them against each other, because a platform's permission tiers are rarely a clean match for your actual scope.
• Skills That Should Come With An Expiry Date — Some skills are only ever going to be correct for a bounded window — tag them with an expiry condition when you build them, because a skill that still runs cleanly isn't the same claim as a skill that's still relevant.
• The Review Habit Every Skill-Builder Needs — Read your own skill's output cold — with enough distance that you're no longer supplying the context you wrote into the instructions — because same-day review from the author is the weakest check available, not the strongest.
• Building A Skill Around A Checklist You Already Trust On Paper — A checklist that works reliably on paper is a different claim from a skill that runs it reliably on its own — the gap between them is almost always the judgement calls nobody wrote down because they felt obvious.
• The Difference Between A Personal Skill And A Published One — A skill you use yourself can quietly assume what you already know; a skill you publish for others can't assume anything except what's written in it — and most of the real work in publishing is finding and removing those assumptions, not polishing the prose.
• What Breaks First When An Underlying Tool Changes Its API — An API change usually breaks a skill quietly before it breaks it loudly — treat a "success" response as a claim to verify, not a result to trust, especially for anything you depend on that you don't control the version of.
• The Skill You Write Once And The Prompt You Write Every Time — The line isn't how often you do a task, it's whether what changes between instances is the wording or the procedure — if only the inputs vary, write the prompt; if the steps themselves need enforcing even when you're rushed, build the skill.
• Giving An Agent A Budget, Not Just A Task — Give every agent a budget alongside its task — a time ceiling, a cost ceiling, and a hard stop when either is hit — because a task definition alone says nothing about how much effort or spend it's reasonable to burn chasing it.
• The Difference Between A Chain Of Skills And One Overloaded Skill — When one skill has grown enough scenario-branching that you skip whole sections depending on the input, the fix is splitting it into a chain of narrower skills, not writing a longer version of the same one.
• Reading A Skill's Permission List Like A Contract, Not A Formality — Read a permission list the way you'd read a contract — line by line, asking what the worst plausible use of each specific line is — because skimming to the "allow" button is agreeing to terms you haven't actually read.
• The First Sign A Skill Needs Retiring, Not Patching — The first real sign a skill needs retiring isn't a failure — it's the second patch to the same skill within a short window, which means you're accumulating fixes instead of asking whether the thing underneath needs rebuilding.
• Building A Skill For A Task You Do Weekly, Not Daily — The sweet spot for building a skill sits at weekly frequency — often enough that the time saved actually adds up, infrequent enough that you've usually half-forgotten the exact steps by the time you're doing it again, which is precisely when a documented, repeatable procedure earns its keep.
• What A Skill Marketplace Doesn't Tell You About Provenance — A marketplace listing describes what a skill claims to do; it doesn't verify who built it, what it actually touches, or whether that's still true — check provenance yourself rather than reading a rating as a substitute for it.
• The Difference Between Testing A Skill Once And Trusting It Forever — A skill has earned exactly the trust its testing actually covered — not open-ended trust that keeps compounding every time it runs cleanly afterwards — so treat any real use outside what was tested as untested, however long the streak since has run.
• Your Skill Library Is A Codebase Now — Treat It Like One — Once your skill collection grows past a handful, apply the same basic discipline you'd want from any codebase — naming, versioning, and documentation — rather than letting it stay a pile of individually reasonable files.

Prompting

How to ask so the first answer is usable.

• The Brief Beats The Prompt — A prompt asks for an output; a brief gives enough shape that a follow-up question doesn't start you over — write briefs, not prompts.
• Why "Be More Specific" Is Bad Advice — "specific" isn't a volume of words, it's an answer to a named question — specific about the audience, the constraint, the format, or the comparison, not specific in general.
• The Three-Part Prompt Structure Worth Memorising — Role, task, and constraints — three parts, in that order, and a prompt missing any one of them is missing something specific and fixable, not just "unclear."
• Asking For The Method, Not Just The Answer — Ask for the method alongside the answer — the reasoning is easier to fact-check than the conclusion, and bad reasoning is where wrong answers come from.
• The Difference Between A Constraint And A Preference In Your Prompt — Say plainly which parts of the request are fixed and which are just leanings — a constraint that reads like a preference will get quietly traded away the moment something else in the prompt pulls against it.
• Why Examples Beat Adjectives — Show a sample of the tone you want instead of naming it — a single example does more precise work than a paragraph of adjectives.
• The One-Sentence Test For Whether Your Prompt Is Actually Clear — Before you send a prompt, try to state its request back in one plain sentence — if you can't, the prompt isn't clear yet, no matter how long or detailed it is.
• Prompting For Disagreement — Asking It To Argue The Other Side First — Ask it to argue against your idea before asking whether it's good — forcing the counter-case first produces a far more honest answer than asking for a verdict directly.
• The Difference Between "Summarise This" And "Tell Me What I'm Missing" — Summarising compresses what's there; a gap-check looks for what isn't — decide which one you actually need before you ask for either.
• Writing Prompts That Survive Being Reused Next Month — Write the prompt for a version of you with no short-term memory — if it only works because you remember what you meant, it won't survive reuse.
• The Anti-Pattern: Prompting Like You're Placating A Toddler — A prompt is an instruction, not a negotiation — cut the coaxing language and replace it with the actual constraint it was standing in for.
• Asking For A Draft vs Asking For The Final Version — Decide whether you need something to react to or something to send, and say which — a draft and a final version are different requests, not two points on the same scale.
• The Confidence Check: Making Every Answer State Its Own Uncertainty — Ask the answer to grade its own confidence and name what would change it — a flat, undifferentiated answer hides exactly the information you need to decide how much to trust it.
• Why Longer Prompts Aren't More Precise Prompts — Length adds words; precision removes ambiguity — a prompt can gain the first while losing the second, and past a point, more words actively bury the request.
• The Difference Between Instructions And Context — Context is what's true, instructions are what you want done, and a prompt that doesn't separate the two will occasionally get them backwards.
• Prompting In Layers: Outline First, Then Fill, Never All At Once — Lock the structure before you spend any words on the content that fills it — fixing a bad outline is cheap, fixing a bad outline that's already been written into three thousand words of prose is not.
• The One Follow-Up Question That Improves Almost Any Answer — Ask what was left out and why, before you ask for anything else — a single targeted follow-up does more for the answer's quality than a second attempt at the original prompt.
• Writing A Prompt Template You Can Actually Hand To A Colleague — A template only works once every blank in it says what to type, not what you happened to mean the last time you used it.
• The Difference Between A Leading Question And A Fair One — If the phrasing already reveals which answer you want, what you get back is an echo, not a test.
• Why "As An Expert In X" Does Less Than People Think — A role label changes tone and framing, and only helps when that framing genuinely changes what's relevant to include — it doesn't grant access to better facts or more careful reasoning by itself.
• Prompting For A Second Opinion On Your Own Idea, Honestly — State the idea in neutral terms, without your case for it, before you ask anyone — human or model — what they think of it.
• The Habit Of Asking It To Grade Its Own Answer Before You Do — Before you judge an answer yourself, ask it to critique its own draft against the original brief — a self-critique surfaces gaps a first read tends to miss.
• Structuring A Prompt Around The Decision It Needs To Support — Name the decision and the real options first, and build the prompt around choosing between them — not around the subject they belong to.
• The Difference Between A Prompt That Informs And One That Persuades — Decide, before you write the prompt, whether the reader is meant to be informed or persuaded — the same words in a different order produce one or the other, and you get to choose which.
• Retiring Your Favourite Prompt When The Model Changes Underneath It — A prompt is tuned against a specific model's habits, and when the model changes, the prompt needs re-testing — not blind continued trust.

ChatGPT & Others

Choosing between tools without the hype.

• Claude vs ChatGPT: The Honest Difference, Not The Marketing One — Pick based on what you actually do most often, not on which tool "won" a headline comparison — the real differences are narrower and more practical than either company's marketing suggests.
• When Gemini Is Actually The Better Choice — Reach for Gemini for a specific, narrow set of jobs where its actual structural advantages apply — not because a comparison piece named it the overall winner this quarter.
• Running The Same Task Through Two Models On Purpose — For anything you're about to act on, running the same prompt through a second model is a five-minute sanity check, not a wasted subscription — the disagreement (or agreement) between the two answers is itself useful information.
• What Switching Tools Actually Costs You (Beyond The Subscription) — Weigh a tool switch against everything you'd have to rebuild — saved memory, saved prompts, learned habits — not just the price difference between subscriptions.
• The Case For Using More Than One AI Tool, Deliberately — Running two AI tools for genuinely different jobs is a deliberate choice with a real rationale behind it, not a failure to commit to one — the question worth asking isn't "which tool wins" but "which job is each one actually for."
• Reading A Competitor's Release Announcement Without The Hype — A release announcement is marketing copy written by the company that made the model, and it should be read the way you'd read any other marketing copy — for what it's actually claiming, not for the excitement it's built to produce.
• What "Multimodal" Actually Means For Your Actual Work — "multimodal" only matters to you to the extent that it maps onto a specific input or output format your actual work already involves — otherwise it's a capability you'll never open, dressed up as a headline feature.
• The One Feature Worth Switching Tools For (And The Dozen That Aren't) — Almost no single feature justifies a full switch on its own — only a feature that removes a structural limitation in your single most frequent, real task clears that bar, and everything else is a "nice to have" you can usually get without leaving.
• Comparing Two AI Tools Fairly — A fair comparison between two AI tools tests the same task under the same conditions and judges the output against a standard you set before you saw either answer — not a general impression formed from unrelated, uneven use.
• What You Lose When You Bounce Between Five AI Tools A Week — Switching tools per-task is only actually efficient if you're also willing to pay the switching cost every single time — and for most people, five tools a week means paying that cost far more often than the task-fit gain is worth.

Money & Business

Running a small business with AI in it.

• The Real Cost Of An AI Subscription, Once You Count The Time Saved — Judge a subscription by what an hour of your time is actually worth, not by whether the monthly fee feels big or small in isolation.
• Using AI To Audit Your Own Subscriptions — Use AI to do the tedious sorting of a subscription audit, but keep the judging of what's worth keeping entirely in your own hands.
• The Business Idea Test: Running It Past An Evidence Ledger, Not A Hunch — Before you build anything, sort what you actually know about the idea into fact, assumption, unknown, and constraint — most "obviously good" ideas turn out to be built almost entirely on assumptions once you do this honestly.
• What AI Can Actually Do For Your Small Business This Month — Pick one task you already do every week that's repetitive and low-judgement, and use AI only there first — not everywhere at once.
• The Difference Between An AI Tool And An AI Employee — Price your time against what a tool actually replaces — a discrete task, or an ongoing role — because those two have completely different true costs, whatever the product calls itself.
• Pricing Your First AI-Assisted Service — What Clients Are Actually Paying For — Price the outcome the client actually needs, then let your own speed determine your margin — don't price your hours and hand the AI efficiency gain back to the client for free.
• The One-Person Business Stack: What's Actually Worth Paying For — A one-person stack should have exactly one paid tool per genuine bottleneck in your business, and nothing paid for a task that happens less than weekly.
• Using AI To Read A Contract Before You Sign It — Use AI to translate a contract into plain language and flag what to ask about, never to tell you the contract is safe to sign.
• The Honest Case For Charging More For AI-Assisted Work, Not Less — Clients pay for the problem being solved, not for the number of hours it took you — if AI made you faster without making the result worse, that's margin you earned, not a discount you owe.
• What A Local Business Should Actually Automate First — Automate the task furthest from the customer's view first, and move toward customer-facing tasks only once you trust the tool with the boring stuff.
• The Difference Between Cutting Costs And Cutting Corners With AI — A genuine cost cut leaves the thing your customer or client actually experiences unchanged or better; anything that quietly lowers what they experience is a corner cut wearing a cost-cutting costume.
• Using AI To Model A Pricing Decision — Before you change a price, sort what you know about the decision into fact, assumption, unknown, and constraint — then model the range those unknowns create, rather than modelling a single confident number.
• The Side Project That Pays For Itself In A Month, And The One That Never Will — A side project that will pay for itself has a specific person willing to pay for it before you've built the whole thing — a project that only pays for itself "once it's finished" usually never will.
• Reading Your Own Numbers Before You Ask AI To Explain Them — Form your own rough read of the numbers first, then use AI to check, extend, or challenge that read — never as the first pass over data you haven't looked at yourself.
• The Real ROI Question: What Would You Have Paid A Person To Do This? — The real ROI question isn't "how much faster am I," it's "what would I have paid a person to do this specific task" — that number is concrete, comparable, and usually settles the question fast.
• Using AI For Invoicing Without Losing Track Of What's Actually Owed — AI can draft, format, and chase invoices, but the record of what's owed and by whom has to live in a system you check, not in your memory of having automated it.
• The Difference Between A Free Tool And A Tool That's Free Until It Isn't — Before you build a real workflow on a free tool, work out which kind of free it is — because the cost of migrating off it later is often higher than any subscription fee would have been.
• What Changes When You Treat AI Spend As A Line Item, Not A Curiosity — Once your combined AI spend is a number you'd notice if it doubled, put it on its own line in your books and review it the way you'd review any other recurring cost — not tool by tool, but as a whole.
• The Honest Audit: What You're Actually Using vs What You're Paying For — Run a straight side-by-side of what you're paying for against what you actually opened and used in the last month — the gap between those two columns is the only number that matters, not the price of either tool alone.
• Building A Simple Financial Model With AI Without Trusting It Blindly — Build the model's structure with AI, but supply and verify every number that goes into it yourself — the assistant can build the scaffolding fast; it cannot know your actual costs, your actual conversion rate, or your actual runway.
• The Business Case You Should Write Before Any AI Tool Purchase — Before you pay for any AI tool, write down what you currently do without it and what that gap actually costs you — the subscription is only worth it if that cost is real and bigger than the price.
• Using AI To Find The Gap In Your Own Market, Not Just Ideas — AI is far more useful for spotting patterns in a market you already know than for inventing one from nothing — feed it what you and your customers actually see, and ask it to find the gap, not generate one.
• The Difference Between A Passive Income Pitch And An Actual Business — If it generates customers, it generates ongoing obligations — support, updates, disputes, marketing to keep sales flowing — passive income describes the pitch, not the business. Find out what still needs your attention after launch before you believe the label.
• What A Consultant Actually Charges For, And Where AI Changes That Math — A consulting fee is made of at least four separate things — diagnosis, judgement, delivery, and accountability — and AI has only made one of them faster. Price and value should reflect that, not collapse to the cheapest part.
• The One-Week Test For Any New Revenue Idea, Before You Build Anything — You can get a real answer on whether people will pay within a single week, before you build anything — if the idea can't survive that test, it isn't ready to be built yet.
• Using AI To Chase Invoices Without Sounding Like A Robot — A payment reminder works when it sounds like you noticed a specific overdue invoice, not like a system generated one — use AI to draft the structure of an escalation, then edit each message back into your own specific voice before it goes out.
• The Real Risk In "AI Side Hustle" Content — Every visible AI side-hustle success story is filtered by survivorship — you only see the ones that worked, often told by people whose main income is the story itself, not the side hustle it describes.
• What To Automate In A Small Business Before You Hire For It — Before creating a new role, separate the recurring low-judgement tasks piling up from the judgement-heavy work that genuinely needs a person — automate the first, hire only for what's left.
• The Honest Case For Not Automating Your Customer Relationships — Automation earns its keep when it's invisible and saves you time without the customer noticing. The moment a customer can tell they're talking to a system instead of you, you've spent trust to buy time — do that deliberately, not by default.
• Using AI To Sanity-Check A Big Purchase Decision — AI is far more useful as a devil's advocate on a big purchase than as a cheerleader — ask it explicitly to argue against the decision you're leaning toward, using only the numbers and constraints you give it.
• The Difference Between A Discount And A Devaluation — The question that matters isn't how big the discount is, it's whether it resets the anchor — a temporary, clearly bounded discount moves revenue in time; an unclear or repeated one teaches customers your real price is the discounted one.
• What A Real Financial Model Needs That A Chat Can't Give You — A financial model is only as useful as its assumptions register and its sensitivity range — a single set of numbers from a chat conversation is a guess with formatting, not a model, until you can see what it depends on and what happens when those numbers move.
• The Business Question Worth Asking Before Any Growth Tactic — Before running any growth tactic, ask what happens to quality, delivery, and support if it actually works — a tactic that succeeds at demand you can't fulfil well doesn't grow the business, it just moves the strain forward and adds reputational cost.
• Using AI To Track Where Your Money Actually Goes, Not Where You Think It Goes — Your mental model of where money goes is built from memory, and it's reliably wrong in specific, checkable ways — use AI to categorise your actual transaction history, not to guess at your spending pattern from a description of your business.
• The One-Page Business Case Template Worth Stealing — A one-page business case forces exactly the specificity a decision needs and no more — anything longer is usually padding, anything shorter is usually missing something load-bearing.

Career & Work

Job hunting, reviews and your day-to-day work.

• The Interview Prep Nobody Does: Rehearsing The Question You're Dreading — Name the question you're dreading before the interview, and practise answering it out loud — the research everyone does is useful; the rehearsal almost nobody does is what actually changes how you perform.
• Using AI To Read Your Own Resume Like A Stranger Would — Don't ask AI to improve your resume — ask it to read your resume with none of the context you're carrying in your head, and tell you where the meaning falls out.
• The Difference Between Tailoring A Resume And Lying On One — Tailoring changes emphasis and framing to match what's true; lying changes the facts underneath it — and the test is whether you'd say the sentence out loud to the hiring manager's face.
• What A Hiring Manager Actually Skims For In The First Ten Seconds — The first pass isn't reading your resume, it's scanning it for three or four specific things — know what they are, and put them where a skim will actually catch them.
• The Honest Case For Practising A Hard Conversation Before You Have It — Practising out loud against something that talks back is what changes how a hard conversation goes — silent mental rehearsal mostly just changes how confident you feel walking in, which is not the same thing.
• Using AI To Prepare For A Performance Review, Both Sides Of It — Prepare from a real record, not from memory — and prepare both the case you're making and the pushback you'll get, not just the highlight reel.
• The Career Move Worth Rehearsing Before You Make It — The decision is yours to make alone; the move — the conversation where you announce it, ask for it, or walk away from it — is worth rehearsing before you make it, because that's the part that can still go badly even after you've decided correctly.
• What "AI Skills" Actually Means On A Resume, And What Doesn't Count — "AI skills" is only a real claim when you can name what you used it for, on what, with what result — anything vaguer than that is a sentence a hiring manager has already learned to skip over.
• The Difference Between Automating Your Job And Making Yourself Redundant — Automating a task doesn't make you redundant — automating a task and having nothing to show for the time it freed does. The risk isn't the automation; it's the empty hours after it.
• Using AI To Negotiate A Raise Without Sounding Like You Used AI — Use it to build the case, not to write the script — the research and structure benefit enormously from AI help, the actual words in the room need to sound like you making a specific ask, not a template.
• The One Meeting Prep Habit That Actually Saves Time — The habit that saves time isn't preparing more, it's preparing the one thing — what decision or outcome this meeting needs to produce — before it starts, not during it.
• What To Actually Say When Asked "How Do You Use AI At Work?" — The answer that actually lands names one specific task, one specific tool-role, and one specific thing you check or wouldn't hand over — a real answer has all three; a vague one has none.
• The Honest Skills Gap: What AI Fluency Actually Requires — "AI fluency" isn't one skill — it's knowing what a tool is plausibly good at, checking its output like you'd check a junior colleague's, and knowing when not to use it at all. Most people have one of these and are missing the other two.
• Using AI To Draft A Hard Email You've Been Avoiding — Use AI to get past the blank page, not to say the hard thing for you — the draft should give you something to react to and edit, never a message you send without changing the parts that matter.
• The Difference Between Looking Busy And Being Useful, In An AI-Assisted Job — Volume of output and usefulness are different measures, and AI makes it easier than ever to maximise the one that doesn't matter — the real test is whether anyone downstream needed less from you because of what you produced, not how much you produced.
• What A Career Pivot Actually Needs Before The First Application — Before the first application, a pivot needs a tested answer to "why this, why now, why you" — not a rewritten resume. The resume is what you write once that answer survives contact with a sceptical listener.
• Using AI To Practise Saying No At Work — Use AI to rehearse the specific moment of declining, out loud, until the words are automatic — not to generate a script you read from, which collapses the second the conversation goes off-script.
• The Real Question Behind "Will AI Take My Job" — Don't ask whether your job disappears — ask which specific tasks inside it are getting faster or cheaper to do, because that's the part that's actually already changing.
• What Managers Actually Want From Someone Who Uses AI Well — Managers want the output to be trustworthy and the judgement behind it to be yours — how you produced it is background information, not the pitch.
• The Difference Between A Portfolio And A Pile Of Projects — A portfolio makes the case for you before anyone reads the details — a pile of projects makes the reviewer do that work themselves, and most won't bother.
• Using AI To Prepare For A Panel Interview, Not Just A Chat One — Prepare for the panel as a group with competing interests, not as one interviewer multiplied — the mechanism has to model the room, not just the questions.
• The One-Page Brag Document Worth Keeping Updated — Capture the evidence when it happens, not when you need it — a brag document is a running log, not a document you write from scratch under deadline.
• What A Reference Check Actually Reveals That A Resume Doesn't — A reference check exists to surface working texture a resume structurally can't show — how you handle pressure, disagreement, and being wrong — so prepare your references for that question, not for a character reference.
• Using AI To Draft Your Own Exit Interview Answers, Honestly — Use AI to separate what's true from what's safe to say out loud — draft the honest version first, then decide deliberately what to soften, rather than smoothing by default before you've even named the real answer.
• The Difference Between A Mentor And A Chatbot, And When You Need Which — A chatbot is good at information and rehearsal on demand — a mentor is good at judgement earned from experience and a stake in your actual career, and the two aren't interchangeable even when the chatbot's answer sounds equally confident.
• What To Automate In A Job Search Without Losing The Human Signal — Automate the repetitive mechanics of the search, never the part where you demonstrate specific interest — volume without signal just produces more applications that get filtered out faster.
• The Career Conversation Worth Having With Yourself First — Work out what you actually want before you're reacting to an opportunity or a bad week — the conversation with yourself has to come before the conversation with a recruiter, a manager, or a chat window, not after.
• Using AI To Map A Five-Year Plan Without Pretending You Can Predict It — Plan the direction and the decision points, not the destination — a five-year plan should tell you what to do next and how you'll know when to reconsider, not predict a job title you can't actually forecast.
• The Honest Case For A Boring, Steady Job Search Over A Flashy One — A steady, repeatable search process outperforms a search built around one clever move — because a clever move that doesn't land leaves you with nothing, and a steady process compounds even when any single application doesn't.
• What Actually Gets You Promoted, And Where AI Fits Into It — Promotion has always tracked visible impact and sound judgement, not effort or busyness — AI changes how fast you can produce work, not what actually gets noticed and rewarded.

Creative & Design

Writing, images and design without losing your voice.

• The Difference Between AI-Assisted And AI-Generated, And Why It Matters To Say Which — Say what AI touched and what a person touched, specifically — "AI-assisted" and "AI-generated" aren't a spectrum of honesty, they're two different descriptions of two different processes, and the vague version of either one is the dishonest one.
• Using AI For A First Draft Without Losing Your Own Style — The flattening happens when you describe your style instead of showing it — feed real examples of your own work in, and a first draft can stay recognisably yours.
• The Honest Case For Editing AI Output Harder Than You Edit Your Own — AI output needs a harder edit than your own drafts, not a lighter one, because polish and correctness are unrelated in a model's output in a way they usually aren't in your own.
• What Makes AI Writing Sound Like AI Writing (And How To Fix It) — AI writing has a handful of identifiable habits — name them, edit against them specifically, and the "sounds like AI" complaint mostly disappears.
• The Difference Between A Mood Board And A Finished Brief — A mood board captures a feeling; a brief captures decisions — and a feeling without decisions produces work that looks like the mood board and fits nothing else about the project.
• Using AI To Get Unstuck On A Design, Not To Finish It For You — Use AI to break a specific stall, not to skip past it — the moment you're asking a tool to finish the whole piece rather than answer one question, you've stopped designing and started outsourcing.
• The One Question To Ask Before You Use AI-Generated Art Commercially — Before any AI-generated image goes into commercial use, ask one specific question — what do this tool's current terms say about commercial rights and ownership of what it outputs — and get the actual answer, not an assumption.
• What A Client Actually Wants To Know About Your AI-Assisted Process — A client asking about your AI use almost always wants to know about ownership, originality, and reliability — answer those three, specifically, before you answer anything about ethics or craft.
• The Difference Between A Template And A Voice — A template is a structure anyone can fill in and get a competent result; a voice is a set of specific, consistent choices that only you would make — and AI tools are extremely good at the first and cannot substitute for the second.
• Using AI To Critique Your Own Work Before Anyone Else Sees It — A self-critique pass only works if you ask a specific, answerable question instead of a general one — "is this good" gets you flattery, "does this achieve X for audience Y" gets you an actual answer.
• The Honest Case For Doing The First Version By Hand — Doing the first version by hand isn't slower in any way that matters — it's the step where you find out what the piece needs to be, which a generated first option skips past rather than answers.
• What Changes When You Give AI A Real Reference Instead Of A Description — A real reference removes an entire layer of translation that a description can't avoid — the tool stops guessing what your adjectives mean and starts matching something concrete instead.
• The Difference Between Fast Content And Good Content, And Why AI Only Fixes One — AI is very good at collapsing the time between idea and draft; it does nothing on its own about whether the idea was worth having — speed and quality are separate variables, and a tool that's excellent at one tells you nothing about the other.
• Using AI To Storyboard Before You Shoot Anything — A storyboard's job is to surface problems before they cost you anything — a generated board that does this in minutes instead of hours is worth using precisely because it removes the excuse to skip the step, not because the images themselves are the deliverable.
• The One Creative Habit AI Makes Easier To Keep — AI doesn't make you more original, but it makes iteration — another version, another angle, another pass at something you already made — cheap enough that you'll actually do it, and iteration is where most real improvement in creative work comes from anyway.
• What A Good Creative Brief Gives An AI Tool That A Vague One Never Will — A creative brief needs a reference, an audience, and a constraint — without at least one of the three, "make it good" has no target to aim at, human or AI.
• The Difference Between Inspiration And Imitation, And Where The Line Actually Is — Inspiration changes how you make something; imitation changes what you're allowed to call your own — the test isn't how closely the result resembles the source, it's whether the source did the work or you did.
• Using AI To Finish The Boring 20% Of A Creative Project, Not The Interesting 80% — The right place for AI to take over completely is the mechanical tail of a project, not the front of it — the test is whether the task has a creative decision left in it at all, not whether it's tedious.

Everyday Life

Home, health admin, travel and family.

• The Honest Case For Not Automating Family Time — Automate the logistics of family life freely — automate the attention, and you've automated away the point.
• Using AI To Plan A Week Of Meals Without Losing Track Of What's In The Fridge — A meal plan is only useful if it's built from your fridge outward, not from a recipe list inward — the ingredients come first, the meals get assembled around them, not the other way round.
• The Difference Between A Reminder And A Nag — Setting Up AI Check-Ins Properly — A reminder is only doing its job if you'd actually notice it missing — if you've started dismissing it automatically, it's already become a nag, and the fix is redesigning it, not just tolerating it.
• What AI Actually Helps With In A Health Scare, And What To Leave To A Professional — AI is genuinely useful for organising a health scare and genuinely bad at being the authority inside one — use it for the former, and get a professional for the latter every time.
• Using AI To Plan A Trip Without Outsourcing The Judgement Calls — AI is a fast first draft of a trip, not a finished one — the logistics and the taste calls are still yours to check and make.
• The One Household System Worth Building With AI First — Build one household system that runs continuously before you build ten one-off prompts — a single working system beats a dozen clever answers you never reuse.
• What A Financial Check-Up At Home Actually Looks Like With AI's Help — A financial check-up needs a defined scope before AI is any use — bring it a specific question with your own numbers, not an open invitation to tell you how to be better with money.
• The Difference Between Delegating A Chore And Delegating A Decision — A chore is the execution of a choice already made; a decision is the choosing itself — AI can take almost any chore off your hands, but a decision handed over is a decision you've stopped making, whether or not you notice.
• Using AI To Prep For A Hard Family Conversation — AI is genuinely useful for preparing the ground of a hard conversation and useless — worse than useless — for supplying the actual words, because the words only land if they're recognisably yours.
• The Honest Limits Of AI As A Study Partner For Your Kids — AI is a genuinely good study partner for explaining and practising, and a genuinely bad one for producing the actual answer — the test is whether your child could redo the problem alone five minutes later.
• What Changes When You Use AI To Plan A Wedding, Realistically — AI collapses the coordination overhead of a wedding dramatically and changes nothing about the decisions that were the actual point of planning one together — treat those as separate categories from the start.
• The One Home Admin Task Worth Automating Before Any Other — Start with whichever recurring task currently causes the most avoidable friction — usually the one you're most likely to forget or do late — not the one that sounds most impressive to automate.
• Using AI To Track A Habit Without Turning It Into Another Chore — A habit tracker that costs more attention than the habit itself is a chore wearing the habit's clothes — the tracking should shrink over time, not the habit.
• The Difference Between A Journal And A Log — A log records what happened; a journal works out what it meant — AI is excellent at the first and structurally bad at doing the second for you, because the meaning only counts if you're the one who found it.
• What A Long-Distance Relationship Actually Needs From An AI Tool — AI is good at the coordination that long distance makes harder — time zones, planning visits, keeping shared logistics straight — and it cannot generate the actual connection, which has to come from you, in your own words, at your own pace.
• Using AI To Plan A Birthday Without Forgetting The One Thing That Matters — AI can handle everything about a birthday except the one thing that has to come from you noticing this specific person — get that one thing right first, then let it help with everything else.
• The Honest Case For A Digital Detox Week, Scheduled Like Anything Else — A digital detox that isn't scheduled with an actual start date, end date, and a plan for what happens around it isn't a detox, it's a wish — treat it like any other commitment worth keeping and put it on the calendar.
• What AI Gets Wrong About Grief, Illness, And The Things That Aren't Tasks — AI can take real weight off the administration around grief and illness, and it has nothing to offer the part that isn't administration — it can't grieve for you, it can't tell you how you should feel, and treating its fluency on the subject as insight is where this goes wrong.

Judgement & Guardrails

When to trust it, when to check, when to stop.

• The Two-Minute Check Before You Trust Any AI-Generated Number — Any number you're about to act on, quote, or forward gets a two-minute check before it leaves your hands — no exceptions for how confident it sounded.
• What "Hallucination" Actually Costs You If You Don't Catch It — The cost of a hallucination is not fixed — it multiplies with every step it takes before you catch it, so the only real question is where in that chain you're planning to catch yours.
• The Honest Case For Reading The Source, Not Just The Summary — A summary is a map, not the territory — treat anything you'll rely on, quote, or act on as requiring a pass over the actual source, not just the summary of it.
• When To Not Use AI At All — Some situations aren't a "how to prompt this well" problem — they're a "don't" problem, and no amount of careful prompting fixes that.
• The Difference Between A Confident Answer And A Correct One — Treat tone and correctness as two entirely separate variables — a hedged answer can be right, and a confident one can be wrong, with no reliable pattern connecting the two.
• Building Your Own Error Log Instead Of Trusting From Memory — Your own error patterns are only knowable if you write them down as they happen — a real log beats a strong impression every time, because impressions are exactly the kind of thing that get quietly rewritten by memory.
• What A Second Opinion Actually Requires, And Why One AI Chat Isn't It — A second opinion requires genuine independence — a different method, a different source, or a different reasoning path — not just a second question asked to the same kind of answer-generator.
• The Honest Limits Of AI On Anything Legal, Medical, Or Financial — AI is genuinely useful for understanding and preparing in all three domains — it's not a substitute for the licensed person who's accountable for the final answer, and the line between those two uses is worth being precise about.
• Reading An AI Citation Like You'd Read A Stranger's Homework — Treat every AI-generated citation as an unverified claim of existence until you've found the source yourself — the citation format proves nothing on its own.
• The Difference Between Verifying And Just Asking It Again — Verifying means checking a claim against something outside the system that produced it — asking again only checks whether the system repeats itself, and those are not the same activity.
• What Changes When The Stakes Go Up — Your pace and your checking should scale with the stakes of the decision, not stay constant across every task just because the tool feels the same to use each time.
• The One Habit That Catches Most Bad AI Advice Before It Costs You — Before acting on anything an AI tool told you, ask one question — "what would tell me this is wrong?" — and if you can't answer it, that's the signal to slow down, not a formality to skip.
• Why "It Sounded Right" Is The Most Dangerous Sentence In This Whole Topic — Fluency is not evidence. A wrong answer and a right answer can read identically confident, so confidence can never be your check — only a separate, independent verification can.
• The Honest Case For Slowing Down When AI Makes Something Feel Easy — How easy something was to produce tells you nothing about how correct it is — slow down in proportion to what's at stake, not in proportion to how much effort the output cost you to get.
• What A Confident Wrong Answer Looks Like, In Practice — Confident wrong answers take a small number of recognisable shapes — learn the shapes themselves, not just the abstract warning, because the abstract warning doesn't fire on its own when you're actually reading one.
• The Difference Between Trusting A Tool And Trusting Its Output — Trust in a tool is a slow-moving average built from many uses; trust in any one output is a separate judgement made fresh each time — a good average doesn't earn a pass for the next individual answer.
• Reading AI-Generated Legal Or Financial Language Without Getting Fooled By Formatting — Legal and financial formatting signals nothing about accuracy or enforceability — the format can be flawless around substance that is wrong, unenforceable, or doesn't apply in your jurisdiction at all.
• The One Question That Separates A Real Fact From A Plausible One — Before you accept a stated fact, ask one question — can I trace this to something outside the model itself? — because that's the only question that actually separates a fact from a plausible-sounding guess.
• What To Do When You Catch AI Being Wrong — Catching one error is information about the whole output, not a single fix to apply and move past — treat it as a prompt to check scope, not just correct the line.
• The Honest Case For A Human Checkpoint On Anything Irreversible — Anything irreversible gets a deliberate human pause before it happens, regardless of how routine or low-stakes the step felt a moment earlier.
• Why Consensus Between Two AI Tools Isn't Proof Of Anything — Two AI tools agreeing tells you they were shaped by similar training data and similar incentives, not that the answer is correct — real independent verification comes from an outside source, not a second model.
• The Difference Between A Guardrail And A Suggestion — A guardrail is enforced regardless of pressure to skip it; a suggestion is followed when convenient — know which one you actually have, because they behave completely differently the one time it matters.
• What Privacy Actually Means When You Paste Something Into A Chat — Anything you paste into an AI chat is sent to that company's servers under whatever terms apply to your specific account — treat it as a message sent to a company, not a private thought, until you've actually checked otherwise.
• The One Audit Worth Running On Anything AI Touches At Work — Build one map of everywhere AI touches your actual work, once, and keep it current — the risk isn't any single tool, it's the sprawl nobody has looked at all at once.
• Reading Permissions Before You Connect Anything To Anything — Read what's actually being requested before you grant it — a one-time click creates a standing permission, and standing permissions are worth more scrutiny than the click itself suggests.
• The Honest Case For Distrusting Your Own First Reaction To A Good Answer — Your immediate positive reaction to an AI answer is a signal about how much you wanted that answer to be right, not a measurement of whether it is — treat the two as separate and check the second one separately.
• What Changes About Responsibility When AI Did Part Of The Work — Your responsibility for anything you submit, send, or act on is total the moment you do it, regardless of what proportion of it an AI tool produced — there is no partial-credit version of accountability.
• The Difference Between A Tool That's Wrong And A Tool That's Lying — An AI tool being wrong and an AI tool producing output shaped by what it was trained to be rewarded for are both real failure modes, but neither is "lying" in the sense that word implies — and telling them apart matters more than deciding what to call it.
• Why "The AI Said So" Is Never A Complete Answer To Anyone — "the AI said so" describes provenance, not justification — it tells someone where an idea originated, not whether it's right, and only the second one is actually a complete answer.
• The Guardrail Habit Worth Building Before Any Other On This List — Build one habit before any other — pause and ask "what happens if this is wrong, and would I know before it mattered?" — because that single question is what actually decides whether any of the other mechanisms in this library get used at all.

Trend Watch

Reading the AI news without getting played.

• The Habit Of Waiting A Week Before Trying Any New AI Tool — A new tool gets seven days of you watching, not using — if it still looks worth an hour once the launch noise has cleared, it gets a proper test; if it has faded, you've lost nothing.
• What "Agentic" Actually Means, Cutting Through The Buzzword — "agentic" means a system takes a sequence of actions toward a goal with some autonomy, deciding its own next step — if a product can't tell you what it decides on its own versus what it just responds to, the label is doing marketing work, not descriptive work.
• The Difference Between A Real Capability And A Demo — A demo shows that something is possible; a capability is something that happens reliably, on inputs nobody picked in advance, at a cost you can live with — judge every showcase by the gap between the two.
• Reading An AI Company's Announcement Like A Sceptical Journalist — Read every announcement as a press release until shown otherwise — separate what is actually being shipped, to whom, and when, from everything written to make you feel something about it.
• The Honest Case For Ignoring Most AI News This Month — A story only earns your attention if it changes something you'll actually do in the next month — everything else can wait, and most of it will turn out not to have needed you at all.
• What Changes When A Tool You Rely On Gets Acquired — An acquisition rarely changes the tool on day one, but it does change who decides its future — so don't move yet, but make sure you could.
• The Difference Between A Feature And A Product — Before relying on a new tool, ask whether it would still make sense if the platform underneath it, or the big tool next to it, shipped the same thing — if not, treat it as a feature and don't build anything load-bearing on it.
• Why Most "AI Will Replace X" Predictions Are Wrong In The Same Way — Almost every failed "AI will replace X" prediction made the same mistake — treating a job title as one task instead of a bundle of many — and you can spot a shaky prediction by checking whether it's made that same error.
• The One Question To Ask About Any New AI Regulation That Affects You — Ask one question — "what, specifically, would I have to do differently, and from when?" — and don't spend further time on any regulation until you can answer it, even if the answer is "nothing".
• What A Price Change Actually Signals About A Company's Plans — Read a price change as a statement of priorities, not a mood — ask who it makes happier, who it nudges out, and what behaviour it rewards, and you'll have a fair guess at where the product is heading.
• The Difference Between Adoption And Hype, Measured Honestly — Hype is measured in attention and sign-ups; adoption is measured in repeated, unprompted use that survives the novelty wearing off — whenever someone cites a number, ask which of the two it actually counts.
• Reading A Benchmark Chart Without Being Fooled By It — A benchmark measures performance on a specific, narrow task — treat the chart as evidence about that task specifically, not as a general verdict on which tool is "better."
• The Honest Case For Scepticism About "AI Agents That Run Your Business" — Treat "runs your business" as a claim about accountability, not capability — until you can say who checks the agent's work and what happens when it's wrong, it isn't running anything; you're just not watching.
• What Changes When Your Favourite Free Tool Starts Charging — When a free tool starts charging, decide as if you were choosing it for the first time today — at the new price, against your real alternatives — not as someone protecting a habit or punishing a company.
• The Difference Between A Tool Update And A Tool Downgrade — An update is judged on your tasks, not on the release notes — keep a small, fixed set of your own test tasks, rerun them after a change, and call it a downgrade only when those results say so.
• Why Everyone's AI Predictions From Last Year Were Mostly Wrong — Predictions fail in patterns — wrong timing, straight-line extrapolation, capability mistaken for adoption, the wrong mechanism, and incentives dressed up as forecasts — so read any new prediction by asking which pattern it's most exposed to, and hold it that loosely.
• The One Thing Worth Tracking In This Industry, And The Fifty Things Not To — Track one thing — how well your own recurring tasks get done with the tools you use — and let everything else reach you only when it would change that.
• What A Competitor Copying A Feature Actually Tells You — A copied feature tells you what a category has decided is table stakes, not which company is winning — so stop scoring the race and start checking whether the now-common feature is any good for your task.
• The Difference Between An Open Model And An Open Company — "open" describes a specific artefact released under specific terms, not a company's character — so ask "open how, and what exactly?" before letting the word do any work in your decision.
• Reading An AI Safety Report Without Skipping To The Conclusion — A safety report's conclusion is only as meaningful as what was tested, how, and against what threshold — so read those three things before you let the conclusion inform anything you think or repeat.
• The Honest Case For Boredom — The calmest users get the best results — boredom, not excitement, is what actually lets a workflow settle into something reliable.
• What Changes When A Tool Adds Ads, And What Doesn't — The question isn't whether a tool has ads, it's whether the ads can reach the answers or your data — so check those two boundaries specifically and decide from what you find, not from the headline.
• The Difference Between A Community And A Marketing Channel — A community is somewhere honest problems survive in public; a marketing channel is somewhere they get managed out of sight — judge a space by how it handles bad news, not by how warm it feels.
• Why The Loudest AI Account On Your Feed Is Rarely The Most Useful One — Posting volume and posting confidence are optimised for engagement, not for being right — treat a loud, frequent poster as entertainment or sentiment, not as a reliable source for what to actually do.
• The One Habit Worth Building Before The Next Big Model Release — Keep a small, fixed set of your own real tasks — a personal test kit — and run it on every new model you're considering, so each release gets judged against your work instead of someone else's demo.
• What A Layoff Announcement At An AI Company Actually Tells You — A layoff announcement tells you a company is reallocating resources, not why, and rarely what it means for the product you use — so look for concrete changes to the thing you depend on, and ignore the narrative until those appear.
• The Difference Between A Partnership Announcement And An Actual Product — A partnership is an intention until you can use it — so treat any announcement as "not yet real" until you can name what's available, to whom, and when, from something other than a press release.
• Reading Your Own AI Usage Data Like A Researcher Would — Treat your own AI use as a small study — define a question, collect a sample, and look at what the record shows rather than what you remember — before deciding whether a tool is earning its place.
• The Honest Case For Not Switching Tools Every Time Someone Posts A Thread — Switching has a cost the thread never counts — your setup, your habits, and your accumulated know-how — so only switch when a new tool clearly beats your current one on your own tasks by more than that cost.
• What Changes When A Government Actually Regulates This Industry — Regulation affects you through specific obligations on specific uses, phased in over time — so find out which uses it covers, who carries the obligation, and when it applies before deciding it matters to you.
• The Difference Between A Leak And A Confirmed Feature — A leak is a claim about the future from an unaccountable source — treat it as a maybe, give it a confidence grade, and don't let it change any decision until the company confirms it and you can use it.
• Why "Everyone's Using It" Is Never A Reason To Use Anything — Popularity tells you a tool is worth a look, never that it's worth using — so turn "everyone's using it" into a specific question about your own work before it gets a place in your workflow.
• The One Trend Actually Worth Your Attention This Quarter — The trend worth your attention is the one that changes what you personally do, this quarter, not the one generating the most headlines — use a filter to find it, don't just absorb whatever's loudest.
• What A Data Breach At An AI Company Should Change About Your Habits — Assume anything you type into an AI tool could one day be exposed, and shape your habits so that if it were, the damage would be small — then a breach becomes an inconvenience rather than a crisis.
• The Difference Between A Roadmap And A Promise — A roadmap tells you what a company currently wants to build; a promise tells you what they've committed to deliver. Plan only around the second, and treat the first as useful weather, not a schedule.
• Reading An Earnings Call For What It Says About The Tools You Use — An earnings call is written for shareholders, not users — so read it for the handful of signals that predict product changes, and ignore the rest.
• The Honest Case For Waiting To See What Sticks — For most new AI tools, waiting a short, defined period before committing costs you very little and saves you from a lot of churn — provided the waiting is deliberate, not avoidance.
• What Changes When Two AI Companies Merge — After a merger or acquisition, trust the documents rather than the announcement, and check the five things that tend to change — on a schedule, not once.
• The Difference Between A Rumour And A Reason To Plan Ahead — A rumour becomes a reason to plan ahead only when it's both credible and consequential — and even then, you plan a cheap contingency, not a commitment.
• Why The Best Users Aren't The Earliest Adopters — The people who get the most from an AI tool are usually the ones who adopted it for a specific job and stuck with it long enough to learn its limits — not the ones who got there first.
• The One Question To Ask Before Believing Any "Leaked Roadmap" — Before believing any leaked roadmap, ask one question — "Who, specifically, could lose something if this turned out to be false?" If the answer is nobody, weigh it at nearly zero.
• What A New Model's Weaknesses Tell You That Its Strengths Don't — A model's strengths tell you its ceiling; its weaknesses tell you whether you can depend on it. For deciding whether to use a model for real work, study the weaknesses first.
• The Difference Between Following The Industry And Being Led By It — Following the industry means news informs decisions you were already going to make; being led by it means news creates decisions you wouldn't otherwise have. Keep the first, and catch yourself doing the second.
• Reading A Company's Blog Post Versus Its Actual Terms Of Service — When a company's blog post and its terms of service seem to say different things, the terms win. Read the post for intent and the terms for what you've actually agreed to.
• The Honest Case For A Quarterly Tool Audit, Not A Weekly One — Review your tools and workflow once a quarter, deliberately — frequent enough to catch what's genuinely stale, infrequent enough to judge each thing on real, accumulated evidence rather than a single week's impression.
• What Changes When An AI Tool Goes From Free To Freemium — When a free tool adds a paid tier, the free tier becomes a product with a new purpose — getting you to upgrade. Re-evaluate it as a new product rather than assuming it's the same one with an extra option.
• The Difference Between A Feature Request And A Complaint That Got Lucky — A shipped feature that matches a complaint doesn't prove the complaint caused it. If you want something changed, write a request that would be useful to the people deciding — not one that's merely loud.
• Why Most "10 Tools You Need" Lists Are Written By People Selling Something — A genuinely useful tool recommendation explains why, for what task, compared to what alternative — a bare numbered list with no reasoning attached is a format optimised for clicks and commissions, not judgement.
• The One Filter Worth Applying To Every AI Headline You Read — Before a headline changes what you believe or do, ask "What, specifically, can I do today that I couldn't do yesterday?" If the answer is nothing, file it as context, not news you need to act on.
• The Habit Of Checking Back In Six Months Before Declaring Anything A Winner — Don't declare anything a winner until you've checked back on it after about six months. Early verdicts measure excitement; later ones measure whether it actually stuck.