I Track Calories and Plan Groceries from My Terminal

Nobody expects a coding CLI to order groceries. If you told me a year ago that I'd be logging meals and planning weekly shopping lists through the same terminal where I write Python and debug React components, I'd have been skeptical. But once you understand that Claude Code skills are just markdown instructions with access to tools like Playwright, APIs, and SQLite, the question shifts from "can it do that?" to "why wouldn't it?"

I wrote earlier in this series about my full setup -- 19 plugins, 23 skills. A few of those skills got the most questions. Not the code review tools. Not the design system auditor. The lifestyle automation skills. People want to know how I track calories from my terminal and how I automate grocery runs at Wegmans from a coding tool.

This post is the deep dive.

The Calorie Tracker

This is my most-used non-coding skill. I run it multiple times a day. It's replaced every calorie tracking app I've ever tried, and I've tried most of them.

Here's what a typical interaction looks like. I finish lunch, open my terminal (which is already open because I'm working), and type:

Copy/calorie-tracker log chicken salad with avocado and a glass of orange juice

That's it. Natural language. No searching through a database of foods. No tapping through dropdown menus to specify portion sizes. No scanning barcodes. Just a description of what I ate, the way I'd describe it to a friend.

Behind that simple input, several things happen.

First, the food description goes to the FatSecret NLP API. FatSecret is an underappreciated nutrition API that can parse natural language food descriptions into structured nutritional data. "Chicken salad with avocado and a glass of orange juice" becomes individual food items with estimated calories, protein, carbs, fat, and fiber. The parsing is surprisingly good. It handles compound meals, common preparations, and reasonable portion estimates.

Second, the parsed items get enriched through the USDA FoodData Central database. FatSecret gives you the macros, but USDA FoodData Central adds 25+ micronutrients -- vitamins, minerals, amino acids. If you care about whether you're hitting your iron or B12 targets, this is where that data comes from. Most tracking apps stop at calories and macros. This goes deeper.

Third, everything gets stored in a local SQLite database called nutrition.db. Every meal, every item, every nutrient value, timestamped and tagged. The database is the foundation that makes everything else work -- dashboards, trends, exports, all of it queries this same database.

But the feature that surprised me most is image-based logging. Claude Code has vision capabilities through Claude's multimodal model. So instead of describing my meal in text, I can do this:

Copy/calorie-tracker log [photo of my plate]

Claude looks at the image, identifies the foods, estimates portions, and logs the nutritional data. Is it as accurate as weighing everything on a food scale? No. Is it accurate enough for practical tracking? Yes. And the friction reduction is enormous. Taking a photo is faster than typing a description, which is faster than searching an app's food database, which is faster than manually entering macros.

The daily dashboard is where the data becomes useful. I type /calorie-tracker summary and get a breakdown of everything I've eaten that day with progress bars for each macro. Calories consumed versus target. Protein grams versus goal. Carbs, fat, fiber -- all with visual progress indicators rendered right in the terminal. It looks something like this:

CopyDaily Summary - March 18, 2026
Calories:  1,847 / 2,200  [================----]  84%
Protein:     142 / 160g   [===============-----]  89%
Carbs:       198 / 250g   [===============-----]  79%
Fat:          62 / 75g    [================----]  83%
Fiber:        24 / 30g    [================----]  80%

Simple. No animations. No achievements unlocked. No social features. Just the numbers.

For longer-term patterns, /calorie-tracker trends week or /calorie-tracker trends month generates reports showing averages, consistency, and whether I'm trending toward or away from my targets. This is where tracking becomes genuinely useful. A single day's data is noise. A month of data is signal.

The system also has a favorites mechanism. Foods I eat regularly -- my go-to breakfast, my usual coffee order, the salad I get from the place down the street -- get saved as favorites. Instead of re-describing them every time, I just reference the favorite. /calorie-tracker log fav morning-eggs logs my standard two-eggs-and-toast breakfast with the exact nutritional data from the first time I logged it.

Everything exports to Obsidian. My daily nutrition summaries get written to my Obsidian vault as structured notes with metadata that Obsidian's databases feature can query. I can pull up my average protein intake for any arbitrary date range, see which weeks I was consistent and which I wasn't, and cross-reference with other notes in my vault. The calorie tracker is a data collection tool. Obsidian is the long-term analysis layer.

Why does terminal beat apps? No ads. No subscription upsells. No gamification trying to manufacture engagement. No social features I didn't ask for. No dark patterns nudging me toward premium. Just data, stored locally, queried on demand. The app ecosystem has turned calorie tracking into a retention game. I just want to know what I ate and whether it was enough protein.

The Grocery Planner

Every week, I need groceries. Every week, the process used to be the same: open a recipe app, pick some meals, manually build a shopping list, open the Wegmans website, search for each item, add it to the cart, arrange for pickup or delivery. Thirty to forty minutes of tedious, repetitive clicking.

Now I type /grocery-planning shop and let Claude handle it.

The skill starts with meal planning. It pulls from a SQLite database of my past orders, my food preferences, and the recipes I've saved. It suggests meals for the week based on what I usually buy, what's in season, and what I haven't had recently. This isn't random recipe generation. It's personalized suggestions grounded in my actual eating habits.

I can accept the suggestions, modify them, or specify exactly what I want to cook. "Plan for chicken stir-fry, pasta carbonara, and salmon with roasted vegetables this week" works just as well as letting it suggest. The interactive planning phase is a conversation -- Claude proposes, I adjust, we converge on a plan.

Once the meal plan is set, the skill generates a shopping list. It aggregates ingredients across all meals, handles unit conversions, and groups items by category. It also checks the past orders database to see if I recently bought something that I might still have. If I bought a bag of rice two weeks ago, it asks before adding rice to the list again.

Here's where it gets interesting. The skill can import past orders from screenshots. If I have a Wegmans order confirmation or a receipt photo, I can feed it to the skill and it extracts the items, prices, and quantities. This bootstraps the past orders database. After a few weeks of importing orders, the system has a solid model of what I buy, how often, and at what price points.

But the real magic is the Playwright automation. This is the part that makes people's eyes widen.

When the shopping list is finalized, the skill opens a headless browser through the Playwright MCP plugin. It navigates to the Wegmans website, logs in (credentials stored securely in the config), and starts shopping. For each item on the list, it searches the Wegmans site, finds the best match, and adds it to the cart. It handles quantity selection, checks for availability, and moves on to the next item.

This isn't a simple API call. Wegmans doesn't have a public API for adding items to carts. The skill is controlling a browser the same way a human would -- clicking search boxes, typing queries, clicking "Add to Cart" buttons, handling popups. Playwright gives Claude Code programmatic control over a real Chromium browser.

The whole process takes a few minutes. At the end, I have a full cart on Wegmans, ready for review and checkout. I do review it -- I'm not going to blindly check out a cart that an AI filled. But reviewing a pre-filled cart takes two minutes. Building it from scratch takes thirty.

The skill also suggests recipes based on what I usually buy. If I'm not sure what to cook, /grocery-planning suggest generates meal ideas using ingredients I've purchased frequently. It's a recommendation engine built on my own purchase history, not some generic recipe database.

The Playwright MCP connection is the key enabler here. Without browser automation, this skill would stop at generating a shopping list, which is useful but not transformative. With Playwright, it closes the loop from "what should I eat" to "it's in your cart." That's the difference between a planning tool and an automation tool.

The YouTube Downloader

This one is simple. No complex API integrations. No SQLite databases. Just a clean interface to yt-dlp.

Copy/youtube-downloader https://youtube.com/watch?v=... 720p mp4

That downloads the video at 720p in mp4 format. You can specify quality (360p, 480p, 720p, 1080p, 4K), format (mp4, webm), or extract audio only as MP3. "Download this as audio only" gives you an MP3 file. "Best quality available" gets you the highest resolution.

I use this for conference talks and tutorials I want to watch offline. Sometimes I'm on a flight and want to watch that 45-minute talk about transformer architectures without depending on connectivity.

Under the hood, it's yt-dlp doing the real work. The skill is just a natural language interface that translates my request into the right yt-dlp flags. Simple, but it removes the friction of remembering yt-dlp's extensive and unintuitive flag syntax.

How These Skills Are Structured

All three skills follow the same architectural pattern. Once you understand the pattern, building new lifestyle skills becomes straightforward.

SKILL.md with argument routing. The skill's markdown file defines the entry point and routes different commands to different workflows. /calorie-tracker log goes to the logging workflow. /calorie-tracker summary goes to the dashboard workflow. /calorie-tracker trends goes to the reporting workflow. This routing is just conditional logic written in natural language inside the markdown file. Claude reads it and follows the instructions.

A Python virtual environment for dependencies. Each skill that needs external libraries has its own venv. The calorie tracker needs requests for API calls and sqlite3 for the database. The grocery planner needs Playwright's Python bindings. Keeping dependencies isolated per skill prevents conflicts and makes each skill self-contained.

SQLite for persistent data. Every skill that needs to remember things uses SQLite. The calorie tracker has nutrition.db. The grocery planner has its orders and preferences database. SQLite is perfect for this -- it's file-based, requires zero configuration, handles concurrent reads well, and Claude Code can query it directly through Python scripts or even raw SQL.

Config files for API keys and preferences. Each skill has a config file that stores API keys, default preferences, and user-specific settings. The calorie tracker config has FatSecret and USDA API keys, daily macro targets, and Obsidian vault paths.

Obsidian export for long-term notes. Skills that generate data worth keeping long-term export to Obsidian. Nutrition summaries become daily notes. Meal plans become weekly notes. This isn't required -- the skills work fine without Obsidian -- but it connects the ephemeral terminal interactions to a permanent knowledge base.

The skills compose with each other. The calorie tracker's macro targets inform the grocery planner's meal suggestions. If I'm consistently under my protein goal, the grocery planner starts suggesting higher-protein meals. The Obsidian export from the calorie tracker creates notes that the grocery planner can reference when planning the next week's meals. It's not a tightly coupled system. Each skill works independently. But the shared data layer in SQLite and Obsidian creates natural connections.

Why the Terminal Works for Life Automation

The obvious question is: why do this in a terminal instead of dedicated apps?

The answer is friction. Specifically, the absence of it.

I'm already in the terminal. All day. I'm writing code, running builds, managing git, doing code reviews. My terminal is open from 8 AM until I stop working. When I finish lunch, the terminal is right there. Logging a meal takes ten seconds. Opening a calorie tracking app, waiting for it to load, searching its food database, adjusting portions, and saving the entry takes two minutes. Multiply that by three meals plus snacks, every day, and the friction adds up.

Context switching is the real cost. Every time you switch from your terminal to an app, your brain has to context-switch too. You were thinking about code. Now you're navigating a mobile UI. Then you switch back and need a minute to re-engage. These micro-interruptions accumulate into meaningful productivity loss over a day.

With terminal-based skills, there's no context switch. Same environment, same interface, same mental model. Logging a meal feels like running a git command. Planning groceries feels like running a build script. The cognitive overhead is nearly zero.

The compounding effect matters too. I log meals more consistently from the terminal than I ever did from an app. Because the friction is lower, I actually do it. The best tracking system is the one you actually use. A sophisticated app with beautiful charts is useless if you stop logging after two weeks because it's annoying. A terminal command that takes ten seconds is something I'll do every meal because it costs me almost nothing.

Building Your Own Lifestyle Skill

The pattern is replicable. If you're using Claude Code and you have a repetitive life task, you can probably automate it.

Here's the process I follow.

Identify the task. Pick something you do regularly that follows a predictable pattern. Grocery shopping, expense tracking, workout logging, travel planning, meal prep. The key criterion is regularity -- you need to do it often enough that the automation pays for the setup time.

Figure out the tools. What APIs or services does the task touch? Nutrition tracking needs food databases. Grocery planning needs a store's website. Weather-aware planning needs a forecast API. Some tasks need Playwright for browser automation. Some just need HTTP requests to an API. Some don't need external tools at all.

Write the SKILL.md. This is the core of the skill. It's a markdown file that describes the workflows, the argument routing, and the expected behavior. Write it like you're explaining the task to a smart colleague who's never done it before. Be specific about the steps, the data flow, and the edge cases.

Add the supporting code. If the skill needs to call APIs, process data, or interact with databases, write Python scripts that handle the heavy lifting. The SKILL.md tells Claude when and how to use these scripts. Keep the scripts focused -- one script per capability, not one monolithic script that does everything.

Set up persistence. If the skill needs to remember things between sessions, create a SQLite database. Define the schema, write the initial migration, and add queries for the common operations. SQLite is almost always the right choice for skill-level persistence. It's simple, reliable, and Claude Code works with it natively.

Iterate. The first version of every skill I've built was rough. The calorie tracker's first version didn't have image logging, didn't have favorites, and had terrible portion estimation. I improved it over weeks of actual use. Don't try to build the perfect skill on day one. Build the minimum useful version and refine it.

The hardest part is the initial API setup -- getting keys, configuring auth, understanding rate limits. Once that's done, the rest is just markdown instructions and straightforward Python. The API setup is a one-time cost. The skill pays dividends every time you use it.

The Line Is Arbitrary

Here's what I've come to believe after months of using Claude Code for both coding and life automation: the line between "coding tool" and "personal automation tool" is completely arbitrary.

Claude Code doesn't know or care whether it's refactoring a React component or logging your lunch. It reads instructions, uses tools, and produces results. A SKILL.md for code review and a SKILL.md for calorie tracking have the exact same structure. Same tool access, same persistence layer, same argument routing.

The terminal has always been a general-purpose interface. Claude Code inherits that generality. It can do anything the terminal can do, guided by natural language instead of memorized commands.

Once you internalize that, the terminal becomes the most versatile interface on your computer. I explore this idea fully in my post about how Claude Code is a new way to use a computer, not just a coding tool. Not just for development. For everything that can be expressed as a series of steps with inputs and outputs. Tracking nutrition is inputs and outputs. Planning groceries is inputs and outputs.

The skills I've built aren't impressive because of the underlying technology. APIs, SQLite, and browser automation are not novel. They're impressive because of the interface. Natural language in, structured results out, no context switching, no app hopping, no subscription fees, no ads. Just the terminal doing what it has always done best: executing your instructions without any opinions about what you should be using it for.

If you're only using Claude Code to write code, you're leaving most of its capability on the table. Start with the task that annoys you most. The one you do every week and wish you didn't have to think about. That's your first lifestyle skill.