I’m training for a triathlon and I was tired of staring at dashboards trying to make sense of my own data. So I built a CLI that wraps the intervals.icu API. Now I just tell Claude Code what I need, it queries the data, and we figure out the week together.

The setup

intervals.icu is where all my training data lives — activities auto-sync from my devices, I log wellness daily, and I can see fitness and fatigue trends over time. Most of it is accessible via API.

The architecture is simple: intervals.icu holds the data → icu CLI wraps the API → Claude Code calls the CLI → I have a conversation. The key insight is that Claude Code already knows how to invoke shell commands. If you give it a CLI that returns structured JSON, it becomes a capable analyst in any domain. No MCP server, no custom integration — just a binary that prints clean JSON when piped.

The CLI auto-detects context. Run it in a terminal and you get a rich TUI with charts, sparklines, and interactive tables. Pipe it or pass --output json and you get structured data Claude can parse. That dual-mode behavior is what makes it work well for both human and AI workflows.

What a session looks like

Three real examples. Use the send button to to start the conversation — the commands Claude ran are visible inside each response.

A few things to notice across these examples. Claude Code is pulling from three different commands in the weekly planning scenario: fitness data for CTL/ATL/TSB, wellness trends for HRV context, and the activity list for what I actually did. It reasons across all three before suggesting anything. And when I ask it to reschedule, it writes directly to the calendar via icu events create — no copy-pasting, no manual entry.

The post-workout scenario is the one I use most. Pull up the activity, look at zone distribution, compare against intent. Ten seconds versus clicking through five pages in the app.

What it gets right, and where it breaks

This is the part that matters for deciding whether to trust any of it.

It’s genuinely good at:

• Balancing load across three disciplines. It considers the full week — if I’ve done a long ride with high TSS, it naturally suggests lighter run days without me having to think about it.
• Spotting patterns I’d miss. Across several weeks of data, it can see things like “your swim sessions are consistently shorter on weeks with high bike volume” that I’d never notice in the moment.
• Remembering context within a session. If I mention my knee is sore at the start of a conversation, it factors that into every subsequent suggestion without me repeating it.

Where it breaks:

• Conservative bias. Any HRV dip and it wants to pull the plug on the day. It doesn’t know I was just dehydrated.
• No feel data. It can see my HR zones but it can’t know that the three-hour ride felt easy because it was 8°C outside. Perceived effort is invisible to it.
• Occasional physiological nonsense. It will sometimes suggest “threshold power at zone 2 HR” which isn’t a thing. It doesn’t deeply understand how zone targets interact across metrics.

Here are four recommendations it made recently. See if you can spot which ones I overrode:

The pattern: trust it on load management, override it on intensity and feel.

What’s next

I want to add a icu wellness update workflow that feeds subjective RPE and notes back into the calendar automatically, so there’s less re-establishing context at the start of each session. I’m also looking at persisting a short training context file that Claude can read at the start of each conversation — something like a structured summary of the current training block, goals, and any flags.

The broader pattern is simple: wrap a domain API in a CLI that returns JSON, and Claude Code becomes useful in that domain. It works for training data. It would work for anything where the data is structured and accessible.

The icu CLI is available on my GitHub if you train with intervals.icu and want to try it:

::github{repo=“tomdiekmann/icu”}