
I published a Swamp model that makes packing lists.
That sounds like a fairly silly thing to spend time on. It is also exactly the kind of thing I want software to be good at.
We have taken enough trips that the same categories keep showing up: clothes, toiletries, documents, chargers, food, vehicle prep, things for the kids, and the handful of weird items that only make sense once you are already halfway to wherever you are going. Every list is different, but not that different.
For a long time, those lists lived as old notes: a Vegas trip, an Ohio trip, camping trips, engineering retreats. They were useful, but only if I remembered they existed, found the right one, copied it, and noticed which parts no longer fit.
So I made @mgreten/trip-packing.
It takes a few ordinary trip details—how many days, car or plane, lodging, kids, work gear, activities—and turns them into a categorized packing plan. A five-day car trip with kids gets a different list than a short hotel stay. It is not trying to know everything about our family. It is just applying the boring, repeatable parts consistently.
It is a real Swamp model with two deliberately different modes. preview is read-only, and not just by convention—it never touches the network or the clock. It normalizes the trip characteristics and runs them through a fixed set of category rules: four or more days adds a laundry bag, hiking adds boots and a daypack, an international trip adds a passport and a travel itinerary, work gear or a work activity adds a laptop and a headset. The same normalized input always produces the same plan, which is what makes it safe to look at before anything gets created.
createProject is the other mode. It creates the Todoist project, sections, and tasks—but only when I repeat the exact project name as a confirmation. That is probably overkill for a packing list. But actually, that is the point. The check is enforced twice: once as a swamp pre-flight check labeled policy (skippable only with an explicit --skip-check-label policy, never silently), and again inside the method itself, which throws if the confirmation string doesn’t exactly equal the project name. Belt and suspenders for a mutation that touches a real account.
A little automation should not get to make a mess just because it guessed that I meant yes.
The recovery mechanism underneath that is a marker, and the marker is not decorative. It is an FNV-1a hash of the normalized trip inputs—project name, days, travel mode, lodging, sorted activities, traveler count, any custom items—wrapped as [[swamp-trip-packing:v1:<hash>]]. createProject writes that string as the first section in a brand-new project, before any user-facing category section exists. On every later run, before creating anything, the model looks for a Todoist project with the matching name and scans its sections for that exact marker. Finding it is what turns a create into a reconcile: for each category, find-or-create the section by title; for each item, find-or-create the task by section and content. Nothing gets deleted or duplicated, so a project half-built by an interrupted run just picks up where it left off.
That guard has a real edge, worth saying plainly: Todoist’s REST API has no external idempotency key of its own, so if someone manually deletes that marker section, the model loses its only way of recognizing the project as already-managed, and a later retry can create a second project with the same name. Not a hypothetical—it is called out in the extension’s own README as a documented limitation, not something the model quietly works around.
The model is now public: @mgreten/trip-packing. It is intentionally generic. The old family packing notes stayed private; the reusable patterns became inputs and rules.
I like this project because it is a small example of what I think personal automation ought to look like.
Not a giant agent that silently rearranges your life. Not a chatbot response that disappears into the scrollback. A small tool that does one familiar job, has clear inputs, makes its preview visible, asks before it changes anything, and leaves enough evidence behind to recover from a bad moment.
A packing list is mundane. But mundane is where I spend most of my life.
And if software can take one repetitive little decision off the list without asking me to trust magic, that is a pretty good use of it.