How I AI: Hilary Gridley’s “Anti-System” for Automating Life with Claude Code

Hilary Gridley does not want a life operating system. She does not want to maintain a dashboard, organize a second brain, or spend Sunday evening grooming a personal backlog. She wants to remember the pediatrician appointment, protect time for work she cares about, and still go have a picnic.

That is why her Claude Code setup is an anti-system. It starts with almost no setup, uses plain files, and learns from what actually happens instead of demanding that Hilary define her ideal process in advance.

In this episode of How I AI, Hilary builds a daily planner, a return-tracking skill, and a privacy mode without pretending she will maintain a complicated automation stack. Her rule is simple: complexity has to earn its keep.

The opportunity cost of time has never been higher

Hilary is an entrepreneur and a new mom. Her attention is fractured, and every hour carries an obvious tradeoff. She likes working. She also wants a life. The problem is not identifying her most important work. It is the cloud of small commitments around it that leaks out of her brain.

Her system is designed around two kinds of friction: capturing the thing before it disappears, and turning an overwhelming task into an action small enough to fit into a real day.

Capture first. Organize later

Hilary put an iPhone Shortcut on the back-tap gesture. When she remembers that she needs to reschedule the pediatrician, she double-taps the phone, dictates the task, and it lands in her Reminders inbox. No AI is involved yet.

That detail matters. The right first step is often a two-minute shortcut, not an agent. Hilary only adds automation after the rough version proves it belongs in her life.

Claude Code periodically moves those reminders into a markdown file and sorts them by category. The file lives in one folder with the rest of the context Claude may need. Hilary sometimes opens the markdown in Obsidian, but the storage layer is ordinary text. She does not hand-edit the organizational system.

The complete setup is in the Plan My Day workflow. It is intentionally janky at first: a shortcut, a folder, a few files, and a command.

"Plan my day" is one command

plan my day

Each morning Hilary types plan my day in Claude Code. The command pulls from her reminders, calendar, and accumulated preferences. It shows the day she already has, asks what must move forward, and proposes where the work can fit.

Hilary uses dictation for almost everything. In the demo, she says she must make progress on her baby's passport and use another open block to prepare for a podcast. Claude does not simply place "baby passport" on the calendar. It recognizes that the task is too large.

The useful recommendation is: you are not doing the passport today. You are making the post-office appointment. That takes ten minutes. Tomorrow, gather documents and complete the forms.

That tiny reframing has changed how Hilary handles life admin. Procrastination often begins with a task that cannot fit into the margins of the day. Claude turns it into the first physical action and gives that action a home on the calendar.

The system learns from the gap between the plan and the day

Hilary does not want a background agent silently connecting to everything. She prefers what she calls the Yappers API: she looks at one screen and tells Claude what is happening on the other.

Claude stays open in the terminal beside her work. Hilary says she finished the first passport step, wrote a post, or got pulled into something else. Claude records the observations in a daily markdown note alongside the planned schedule.

The record makes the gap visible. Claude can notice that building keeps crowding out writing, that time boxes are not working, or that Hilary lists three priorities while only the first receives real time. Then it can ask the uncomfortable but useful question: are you choosing the right number one?

This is why Hilary refuses to design the whole system up front. She would have been wrong. She assumed three priorities and an end-of-day reflection would work. The actual behavior showed otherwise. The system changes as she changes, and Claude does the maintenance.

Complexity has to earn its keep

Hilary estimates that only about 20 percent of the personal automations she imagines become durable habits. If she connects every API and builds every polished interface before testing the behavior, most of that work becomes waste. If something breaks, she is now troubleshooting infrastructure for a workflow she did not need.

Her progression is deliberate:

• Start with dictation, screenshots, manual context, or a plain file

• Use the rough workflow for about a week
• Connect an API only after the behavior proves valuable
• Integrate it into a daily command only after it survives the test

This is also a practical path inside companies with strict tool permissions. Demonstrate value with the information and tools already available. A half-baked idea is not a strong case for access to every company system.

Automate work that does not compound your skill or your joy

Hilary uses a sharp test to decide what deserves automation: if I became ten times better at this task, would it create ten times the impact?

If the answer is no, automate it. Becoming ten times better at moving pixels around a slide deck may not make an experienced speaker ten times better at the job. Becoming ten times better at extracting important product decisions from user research might.

The same test applies outside work. Baking bread may look inefficient and still be worth doing because getting better at it enriches your life. Scheduling the return of a package may never become meaningful. Protect the work that compounds expertise or joy. Give the rest to the machine.

The answer also depends on where you are in the learning curve. Slide construction may be important practice for a new presenter even if Hilary has already reached the point where more repetitions add little. Automation is personal, not a universal list of chores beneath human dignity.

Build skills by describing the problem

Hilary does not browse giant skill libraries. She starts with a complaint. Her example: I keep forgetting to return things on time, and I hate doing returns. Come up with ways to make this easier.

Claude asks a few questions. Hilary tolerates about three, then says: use your judgment. The first idea is to add a reminder whenever she buys something. Hilary pushes further: I do not want to tell you what I ordered. Can't you figure it out?

That question expands the solution. Claude realizes it needs email access. It finds the order, return deadline, retailer policy, and drop-off location. Then it writes a slash command, a markdown skill file with English instructions, and the code required to run it.

The point of the conversation-to-automation workflow is not the returns script itself. It is the altitude of the request. Hilary describes the outcome and constraints; Claude product-manages the implementation.

She still keeps the new skill separate from Plan My Day until it proves reliable. A new automation should not be allowed to break the system that already works.

A privacy mode beats a second demo environment

Hilary records demos using her real workspace, which contains names and personal details. Her first instinct was to maintain a sanitized copy of the entire context directory. That would double the complexity.

Instead, she created a Recording On privacy skill. When active, Claude substitutes consistent fake names and hides identifying information before it reaches the screen. Recording Off restores normal behavior. The source files remain unchanged.

The lesson travels beyond Claude Code. Any product demoing from rich production-like data could benefit from a presentation mode that preserves realistic workflows while masking customer and financial information.

The anti-system is a habit, not a build

Hilary once considered the terminal a non-starter. She only tried Claude Code after hitting Cursor limits. A week of begrudging use made it familiar; familiarity made it fun.

That is the real starting point. Put Claude beside the work. Tell it what is happening. Capture the problem in the lowest-friction form available. Let the useful patterns earn another layer of automation.

The goal is not to own an impressive personal operating system. It is to spend less time maintaining systems and more time doing work, caring for people, and protecting the parts of life that get better when a human is fully present.