Tagged “workflow”

Published AgentOS: The Agent Environment That Gets Smarter As You Build, a post about the project environment I am building around AI agents so a fresh session does not have to rediscover the same context every time.

It uses ProjectSpire as the working example: instructions as project memory, plans for intent, Captain Logs for collaboration taste, devlogs for technical history, and skills or workflows for repeated mechanical steps.

Published The Accelerated Speed of Creation, a reflection on how much faster the path from thought to shipped artifact has become with coding agents handling the translation layer around writing, blog workflow, and routine Git operations. I also kept the earlier Encoding My Blog Workflow for Coding Agents draft as a note rather than a post, because it was useful and concrete but still did not meet my standard for what the real piece needed to be.

This past week I shipped across code and writing at a pace that would have felt unrealistic before AI. The surprising part was that it did not feel frantic; it felt like less friction between thought and artifact. It truly feels like working at warp speed, 😜.

Look at this. This is what I have shipped so far in a single week and growing (full list here):

I split the blog editing rules into repo-local skills in 22c4d7d. post-and-note-workflow now makes the timeline-entry rule explicit, while frontmatter-editing routes posts/, notes/, and timeline/ to canonical front matter docs instead of burying that guidance in CLAUDE.blog.md. I also cleaned up timeline-entry so its tag guidance matches the repo defaults.

I published Smart AI Token Consumption as a note on matching model choice to task complexity instead of defaulting to the biggest model. It captures the split I keep using in practice: light models for mechanical work, stronger reasoning only when the problem actually needs it.

I moved the timeline-entry workflow into a repo-local skill in f7fceef. It now sits at .claude/skills/timeline-entry/SKILL.md, with the date/time quoting rules, status tags, and commit-based workflow close to the files it writes.

I added a /release skill to 11ty-subspace-builder in f1cb3a3. It captures the release ritual in one place: choose the semver bump, update package.json, commit chore: release vX.Y.Z, push, and create the GitHub release with the right title, body, and compare link.

I published The Limits of AI and Where Humans Shine — a devlog about a tiny timeline sorting bug that turned into a useful comparison between AI confidence, runtime verification, and human judgement. It follows the fix from plausible-but-wrong timestamp changes to a quoted-date guard that keeps the timeline honest.

I hit a bug that looked too small to be interesting: entries on my timeline page were not sorted correctly within the same day.

The page had a date, a time, and a custom Eleventy collection sort. That sounds like the whole problem space. Sort by date plus time, reverse the collection for newest first, done. Instead, April 12 was rendering in a strange order: 00:01, 10:11, 22:16, 15:49, 22:20.

I've been building a habit-logging iOS app called ProjectDawn. Not because the App Store needs another habit tracker, but because I wanted a personal project that was genuinely mine and open source, and a project that can answer this openly: what does it feel like to build a real, modular, native iOS app with AI as a primary collaborator?

This post is part personal log, part technical retrospective. It covers the tools I used, what surprised me, where the AI fell flat, and the biggest shifts in how I think about building things now.

I’ve had the Umami + Ansible post in my head for ages, but it touched three different repositories and a whole bunch of code snippets. Totally doable, but undeniably tedious — which is why it kept slipping down the backlog. You can read the finished article here: Private Analytics With Umami, Docker Compose, and Ansible.

The idea that finally nudged it forward was simple: why not let GPT (Codex) do the heavy lifting while I steer?

I want tmux to feel like one cohesive environment that never goes away. When I am docked at my desk, I spread iTerm across multiple Mission Control desktops and keep a different project on each space, with some other tools I need for that specific project. Later, when I grab my MacBook Air or open Blink on my iPhone or iPad, I want those exact same panes, command histories, and scrollback.

Plain tmux attach gets close, but the shared "current window" breaks the illusion. When I switch to another window in my main terminal, all other tmux clients jump to the same window and interrupts whatever flow I was in. I wanted tmux to be stateful and multi-focus.

Building small websites with GPT-5 Codex turned out to be less about typing code and more about collaboration. From crude sketches to polished sites, the model took on the heavy lifting while I guided direction and design.

Along the way I discovered both the joy of fast iteration and the limits of relying on an AI partner. These projects became less about the sites themselves and more about exploring a new style of programming — conversational, creative, and sometimes flawed, but always eye-opening.

Last month, my girlfriend mentioned she needed a sleek portfolio site, and I realized I’d been meaning to start a personal tech blog.

I wanted something lightweight—easy to spin up and even easier to tweak. So I dove in: building a small 11ty + Tachyons site from scratch, pushing every iteration live in under a minute, and watching her face light up with each update even though she’s halfway across the country.