Mostly things like recovery time recommendations, body battery, training status, some scores, stuff like that.

There are tons of secondary apps that provide all of those things. Fundamentally the Garmin records less baseline parameters than the Apple Watch does for instance it does not do blood oxygen level monitoring, so whatever stats it’s providing are just software algorithms.

To my knowledge, Apple Health is the only health/fitness data storage with end to end encrypted data, which is one of my main reasons to stay out of other fitness eco systems even if their hardware is way better.

Garmin lets you connect your device as an USB storage device and manage everything manually though.

I do this to completely skip online uploading, and am keeping track of stats using a mashup of bash scripts and cli tools.

I feel like there has to be a middle ground between giving everything to an untrusted cloud and manually downloading raw data and building home grown tools to try and process and make sense of it. As a user, I don't want either of those extremes.

There is https://gadgetbridge.org, which seems like a cool project but I never used it since it is Android only and don't know how good the support actually is.

That sounds good and I will look into it.

I love how so many blog posts that criticize AI generated code are completely AI written.

It's engagement bait and marketing blogposts like this should be banned on HN.

Of course they are not. That is the whole point.

The author confirms that they ARE, so what's your "of course they are not" about? You might have misunderstood my obvious meaning: is the output webpage fully generated without human tweaking just from the paper alone?

You asked that on a post with examples of data journalism articles which are obviously not AI generated. So when you say ask about „those“ it was clear to me that you meant these examples.

All of the links I posted were published before ChatGPT, no AI.

I do something very similar, also with Claude and Codex, because the workflow is controlled by me, not by the tool. But instead of plan.md I use a ticket system basically like ticket_<number>_<slug>.md where I let the agent create the ticket from a chat, correct and annotate it afterwards and send it back, sometimes to a new agent instance. This workflow helps me keeping track of what has been done over time in the projects I work on. Also this approach does not need any „real“ ticket system tooling/mcp/skill/whatever since it works purely on text files.

+1 to creating tickets by simply asking the agent to. It's worked great and larger tasks can be broken down into smaller subtasks that could reasonably be completed in a single context window, so you rarely every have to deal with compaction. Especially in the last few months since Claude's gotten good at dispatching agents to handle tasks if you ask it to, I can plan large changes that span multilpe tickets and tell claude to dispatch agents as needed to handle them (which it will do in parallel if they mostly touch different files), keeping the main chat relatively clean for orchestration and validation work.

semantic plan name is important