The week’s meals aren’t hard to plan. Any one week is trivially easy. Fifty-two of them, while tracking three people’s food preferences, a rotating set of things nobody wants to eat again yet, what’s already in the fridge, and whether anyone has energy for anything that takes more than 30 minutes on a Wednesday — that’s the part that quietly drains you.
I built a Claude skill to handle it. What I learned in the process was less about meal planning and more about where AI actually earns its keep.
TL;DR: Weekly meal planning is a small decision repeated 52 times a year, and it accumulates because you’re holding the same context in your head every single time.
I built a Claude skill that encodes our household’s preferences once and produces a menu and shopping list on demand. The recurring cognitive negotiation is gone.
The same principle I use professionally, just pointed at real life.
The invisible tax of the same decision, made again
Mental load — the cognitive work of tracking, planning, and anticipating — doesn’t announce itself. It accumulates. Sociologist Arlie Hochschild identified it in her 1989 book The Second Shift: the unpaid management work that sits behind the visible tasks, always in someone’s head, rarely acknowledged. In 2017, Emma Clit’s comic “You Should’ve Asked” made the concept visible to a much wider audience with a simple observation: the problem isn’t who does the task, it’s who manages the system. The manager has to know the current state of everything, all the time. That knowledge has a cost.
Meal planning sits squarely in this category. It’s not a big decision. It’s fifty-two small ones, each of which requires the same context load: who eats what, what we’ve had too recently, what constraints apply this week, what’s realistic on a given evening. You don’t sit down and think hard about it. You just carry it, week after week, never quite finishing it, never quite delegating it because delegating requires first exporting your entire mental model to someone else.
That friction — the cost of exporting context — is exactly what encoding removes.
What a skill actually does (and why that matters more than what it says)
I’ve written before about how I use AI in my work as a Product Owner, and in how I run this blog. The most useful frame I’ve found isn’t the model doing clever things. It’s the skill: a set of encoded instructions that removes the need to re-explain context every time.
You’re not asking a smarter question each week. You’re removing the need to ask the question at all. That’s a different category of value.
The meal planning skill works on this principle. It holds our household’s preferences and constraints once: who eats what, what stays off the list, what kinds of variety actually matter to us, any ongoing constraints. When I invoke it, I don’t re-explain any of this. I get a week’s menu and a categorised shopping list. I can push back, adjust the brief slightly, or accept. The cognitive negotiation I used to conduct every Sunday — the “what do we actually feel like, but also what’s efficient, but also what have we already had” internal loop — is gone. Not delegated to someone else. Just gone.
One setup. Fifty-two fewer annual decisions.
The parallel to professional AI use is exact
This isn’t a coincidence of phrasing. The same mechanism I use at work is what’s happening here.
The workflow that publishes this blog involves a Claude skill that encodes the content standards, SEO requirements, pillar logic, and voice once. Each post doesn’t require me to re-derive those standards from scratch. They’re in the skill. The question disappears.
A shopping list is not a publishing pipeline. But the underlying principle is identical: identify what’s genuinely variable, encode everything that isn’t, and run the variable part against a stable structure instead of a blank page.
What scales between these two examples isn’t complexity. It’s the same idea applied at different scope. A household roster of preferences is smaller and less formal than a content system, but both are contexts that would otherwise require re-explanation on every use. Encoding them once is always worth more than having a smarter conversation every time.
Where the real work is
I’m not going to describe the exact implementation here, partly because it’s still evolving and partly because the technical structure isn’t the interesting part.
The interesting part is the thinking that goes into encoding the context in the first place. What does the household actually need to capture? What stays constant week to week? What changes? What constraints matter and which ones are vague preferences that don’t actually hold?
That thinking is the work. The skill is just where it lives once you’ve done it. And it takes meaningfully less time than you’d expect to build something useful — because once the context is encoded, the compounding starts immediately.
The thing about mental load is that you don’t notice it until it’s gone
There’s a version of the AI conversation that’s all about work productivity: automating tasks, reducing time on low-value activities, moving faster. That’s real, and I write about it here. But the more interesting shift I’ve noticed is that the same patterns work in personal life, and personal life is where invisible load tends to concentrate.
The cognitive overhead of running a household is relentless and completely untracked. Nobody measures it, it’s rarely named, and it almost never gets delegated because the friction of delegation is usually higher than just doing it yourself. AI doesn’t eliminate that friction the way another human would — but encoding does. You pay the delegation cost once, upfront, and it disappears from the recurring budget.
Practical takeaway
Pick one decision you make every week from scratch — not one that requires genuine fresh judgement every time, but one where you’re mostly re-doing the same reasoning over the same stable facts. Encode the stable facts. Let the variable part become a parameter, not a fresh start.
That’s it. That’s the move.
It works for a shopping list. It works for a publishing pipeline. The scope is different. The principle is the same.
