I spent a Sunday afternoon designing a skill that produces my morning AI and security news brief. I wrote no code. By the time I shut the laptop I had a working architecture, a master plan document, and fifteen Trello cards with descriptions and “done when” criteria, all sitting on a board waiting for me. The whole design was out of my head and into something stable.

That last bit is the bit that mattered.

The default move

The default move with a problem like this is to open one chat with one model and ask it to do everything. Search the web, pick the sources, sketch the architecture, suggest the dedup logic, write the code. The whole job lives in one giant context window.

For small tasks it works. For a design problem with breadth, where you’re choosing between things you know little about (RSS aggregators in 2026, Bluesky’s RSS support, the state of X scraping, which news APIs are still alive), it bloats fast. The model spends most of its tokens citing things, the citations are uneven, and at the end you have a wall of text and no obvious next move.

The other default is to do the research yourself, write the design from scratch, and commit it to a doc somewhere. That works fine if you’ve got the time and you already know the landscape. For something I knew almost nothing about, starting from a blank page meant a half-day of clicking around before I’d even got to the design.

I wanted neither.

What I actually did

Four tools, each doing one job.

Perplexity for breadth and citations, about fifteen minutes of prompting and skimming. I asked it broad questions: how do people actually source curated AI and security news? What’s the state of Twitter scraping? Are RSS aggregators still a thing? It came back with long answers, citations, comparison tables, and a lot of fluff. Most of what it produced was filler I’d never use, but the citations were real, the URLs worked, and the tables saved me an hour of research per question.

Claude in Cowork mode for synthesis and steering, about twenty minutes of back-and-forth. I pasted Perplexity’s output in and asked it to strip the fluff, give me a conceptual architecture, no code, and prepare to discuss. Then we iterated. I’d push back (“you forgot the general web search, that’s kind of key”), it’d revise, I’d push back again (“you forgot the Bluesky aggregators, the whole point of cards is that you don’t forget shit”), it’d revise again. Each round tightened the design and the model produced a clean architecture markdown to disk at the end.

Trello for persistence, about five minutes. Once the architecture was solid, I had Claude break it into about a dozen discrete cards, each with a description and a “done when” criterion, and write them straight to a list on my AI board. A card 00 holds the full architecture as a reference for the others.

Claude Code for future execution. I haven’t touched this yet. The point is that when I open Claude Code in a dull moment next week, the plan is right there as a list of cards, each scoped tightly enough that I can knock one out in an hour without re-deriving the design.

About forty minutes start to finish, most of it conversational. The split feels obvious in retrospect, but I’d argue it isn’t. Each tool is doing what it’s actually good at, and the handoffs between them are deliberate.

A few small choices that made it work

The design was produced collaboratively but is captured statically. Claude can’t remember our conversation next week. I won’t reliably remember either. What we both can read is a markdown file and a column of Trello cards.

A few specific choices that made this hold together:

• Numbered card prefixes. 00. through 15.. Trello sorts alphabetically inside a list, so the cards stay in build order without needing manual repositioning. Boring but bulletproof.
• “Done when” criteria on every card. Not a vague description, an actual statement of what counts as finished. When I come back to card 03 in three weeks I don’t have to re-decide what “implementing the NewsBlur adapter” means.
• Standalone Python before skill integration. Cards 01 through 13 are pure Python, debuggable in Claude Code. Cards 14 and 15 are the Hermes wrapper and a tuning week. The orchestration layer is the last thing I touch, not the first.

The Bluesky moment was the one place I had to push back hard. Claude had decided that because I’d called the Bluesky aggregator layer “optional” in the architecture doc, it didn’t need a card. I disagreed strongly. Optional means decide later. It does not mean forget about it. The whole reason for putting things on cards is that the cards are the memory, and if something doesn’t make it onto a card it dies the moment I close the laptop.

That’s the test I keep coming back to. Will I remember this without the card? If no, the card has to exist.

The cognitive offload

I have spent thirty years in security engineering, most of it carrying around design context in my head across projects and days. I am quite good at it. I am also quite tired of it. The mental cost of holding a half-formed design while you also do the rest of your life is not zero, and it’s not even particularly small.

The flow above offloads almost all of that cost. The architecture lives in a markdown file on disk. The implementation plan lives as fifteen cards on a Trello board. The actual work, when I get to it, will live in a git repo. None of those places require me to remember anything in order to use them. I open the next card, I read the description, I do the thing.

What this buys me is the ability to design something properly, walk away, come back in a week, and pick up exactly where I left off without paying any reconstruction cost. Reconstruction cost is the silent killer of side projects. You design something on a Sunday afternoon, you’re excited, you write some scratchy notes, life happens for two weeks, and when you come back the notes are inscrutable and the design feels half-remembered. So you start over, and start over, and never ship.

The fix is not to be more disciplined. The fix is to make capture cheap enough that you do it by default. Claude is good at producing the document. Trello is good at storing the cards. I steer the design and then offload it. The model handles the parts I’d otherwise skip because they’re tedious (writing card descriptions, embedding the plan in card 00, ordering things sensibly).

What it’s actually about

The post isn’t really about the AI news brief. The brief is an excuse. What it’s actually about is the workflow.

For the first time in a while I have a sensible answer to the question how should I be using LLMs to do real work? As one piece of a deliberate flow where each tool plays its role, and the artefacts of the flow are designed to outlive any single session.

The corollary is to stop being precious about which tool I use. Perplexity is great at breadth research and weak on considered design. Claude in Cowork mode is great at synthesis and pushback, less good at hunting down forty citations. Claude Code is great at writing and debugging code, not where you go to whiteboard the architecture. Trello is just a list with metadata, but it’s a list with metadata that survives.

Use each one for what it’s good at. Hand off cleanly. Capture the output somewhere stable. Walk away.

That’s the whole thing.

A note on the meta-loop

This post itself was written by Claude using my own write-post-colindomoney skill. The skill is a captured, persisted thing that lives in my plugin folder, encodes my voice and structure preferences, and does the same offload trick for blog drafts that the architecture doc does for the news brief. Another fifteen minutes, including the sign-off checks (em dash grep, word count, banned-words scan, all the boring stuff I’d skip if I were doing it manually).

Total elapsed time from “I want a daily news brief” to “blog post about how I designed it, written and committed”: just under an hour. The flow eats its own dog food.