0xZ

Shell in the Ghost: Migrating my blog to Astro

Oz Tamir — Sun, 21 Jun 2026 10:00:00 GMT

Back in 2020, in the thick of COVID quarantine, I started this blog. I wrote about it in my very first post, Hello World: two weeks stuck at home, rediscovering how much I love messing with technology, and finally deciding to write some of it down.

I needed somewhere to put the words. I picked Ghost.

It was, honestly, the path of least resistance. Ghost was the easy answer in 2020: spin up a VPS, install it, convert a theme into something I actually liked in an afternoon, and start typing.

And for years, it delivered. It got out of my way. I wrote, it published, the thing just worked.

But over the past few months, something shifted. A string of nasty exploits started landing for Ghost. Serious ones, the kind that let a stranger read your entire database or run their own code on your server.

My last-ever Ghost update.

And at some point, mid-update for the umpteenth time, I just stopped and asked myself the obvious question:

Why is my blog running on a CMS in this day and age?

I mean, really. It’s a stack of articles that never change after I hit publish. There’s no reason for it to be a living, internet-facing server that I rent, patch, and pray over. I could just… vibe-code a static site.

A whole class of these problems evaporates the second there’s no server to attack and no database to read. And going static would come with a pile of other benefits I’d been wanting anyway:

No server to babysit. A blog is text. It should be a folder of files a CDN hands out: nothing to log into, nothing to exploit, nothing to patch at 11pm.
Hosting I’m already using. I’ve got a bunch of projects running on Cloudflare already, and the experience has been fantastic: fast, painless, and costing me exactly nothing. Meanwhile I was paying for a VPS just to keep Ghost alive. It wasn’t a lot of money, but it had started to feel like a bill I had no business still paying.
Total control. My markup, my styles, my routes, my rules. If I want the blog to do something weird, it should do something weird.
Markdown for the robots. I wanted agents (crawlers, LLMs, whatever) to be able to ask for a post and get clean Markdown back instead of a soup of HTML. Ghost flat-out can’t do this, and it bugged me more than it probably should have.
A modern stack. I wanted to build on the tools I actually enjoy using now (Astro, Tailwind, the modern web) instead of living inside Ghost’s theme world. (And sure, open-sourcing the result on GitHub was a nice bonus, but that was a side perk, not the point.)

I’d been circling this idea for a while without actually doing anything about it. What finally tipped me over wasn’t the blog at all. It was a side-quest.

Last week I built myself a new site to host and share my public-speaking stuff.

I had a fun design session with Claude, and once that was live, I thought - why not do the same for my homepage? So I went ahead and redesigned it as well.

And at that point, I was on a roll - and I thought: “well, now’s as good a time as any to finally do that blog migration I keep postponing.”

So I did.

Choosing the weapon

First, the boring-but-important question: what do you build a blog out of?

Three real contenders:

Hugo. The old reliable. Fast, battle-tested, boring in the good way.
A vibe-coded, self-made generator. Roll my own from scratch. Maximum control, maximum yak-shaving.
Astro. Component-based, content collections built in, ships zero JS by default.

I went back and forth longer than I’d like to admit. What tipped it was this write-up on migrating from Ghost to Astro with Claude Code. It walked almost exactly the path I was about to take. Astro it was.

So now it was time to actually build the thing, and, frankly, it wasn’t much to write home about. I fired up Claude, wrote a careful spec, and set it running.

One choice that mattered: I asked it to operate as an orchestrator and lean heavily on sub-agents. And the single most important instruction I gave, the thing that kept the output high-quality, was that it should not port any of Ghost’s code.

It had to rebuild the behavior natively, as if the site had always been Astro. That turned out to be the challenging part: Ghost CSS styles and other cruft kept sneaking back in, and it took a long session with Claude before we’d scrubbed all of it out.

There were also some decisions around JavaScript. I built the site to have fully static output - by default, Astro ships no JavaScript to the client. But I did want a little interactivity: for example, the “load more” button on the main page.

Luckily, Astro has a feature called islands: tiny bits of JavaScript, shipped only where needed, which let the site eat the cake and have it too.

Beyond that it was a long tail of small details: fixing some styles, swapping out a few broken fonts, making sure none of my assets were too heavy, and (while I was at it) renaming them from Screenshot 2021… and WhatsApp Web into something readable.

Finally, I built a set of Astro MDX components to hold all the various elements my posts rely on: figures, videos, embedded tweets, and the like.

The result builds to a folder of static files that Cloudflare serves on every push. No server, no database, nothing to patch.

Plot twist: I was already haunted

Partway through the migration, while Claude was going through my old Ghost export to port the posts over, it flagged something: every single one of my 41 posts had the same obfuscated <script> tucked into its footer, not in the post bodies but in Ghost’s per-post “code injection” field.

It was base64-encoded. When I decoded it, it pointed at a domain I’d never seen, pulling a remote script onto my blog for anyone who visited. It was also built to be quiet (it fired only once per visitor), which is part of why I’d never caught it myself.

Not the way you want to find out.

My blog, the one I was in the middle of leaving because Ghost sites were under attack, had already been compromised.

What are the odds, right?

But once the irony wore off, it stopped being funny. This wasn’t a defaced homepage or a cosmetic prank. Code I hadn’t written was running in my readers’ browsers.

Sitting in the footer of every single post.

So I sat down and did some research with Claude, and what I found made it worse, not better: this wasn’t personal. My blog hadn’t been singled out. It had been swept up in a broad, automated campaign that hit hundreds of Ghost sites, Oxford and Harvard among them. The injected script was a loader for a ClickFix attack: the kind that shows a visitor a fake “verify you’re human” box and tricks them into pasting a command that quietly installs malware on their own machine.

For some stretch of time, a real person could have landed on one of my posts and walked away infected, because of my blog. I genuinely, deeply hope nobody did. If you ever visited the site and saw a prompt telling you to press Win+R and paste something to “verify” yourself: don’t, and run a scan.

Even though I was only hours away from replacing the whole site with the clean static version, I knew that waiting it out was not an option. So I stopped everything, went into the live Ghost install, and stripped the malware out of all 41 posts by hand, right then.

If anything, finding this on the way out didn’t shake my decision to migrate. It validated it. The whole problem traces back to one thing: a server. Ghost is software, running on a machine, exposed to the internet, and software running on a server is something that can be attacked and compromised.

A static site has none of that. There’s no application to exploit and no database to read: just plain web pages sitting in storage, handed out exactly as they are. No server means no attack surface, and with no attack surface there’s nothing there to compromise in the first place.

A blog the robots can read

Remember the “Markdown for the robots” bullet from way back at the top? This is where it pays off, and it’s the part I’m most pleased with.

Quick context. There’s a growing push to make websites legible to AI agents: not just human browsers, but the crawlers and LLMs that increasingly read the web on our behalf.

Cloudflare actually wrote up a good framing of this they call “agent readiness”: the idea that a modern site should present itself cleanly to machines, not only people. There’s even a checker, isitagentready.com, that audits your site against a pile of emerging standards.

I ran my freshly-migrated blog through it and, naturally, set out to turn every red X green.

Where I landed: ‘Agent-Integrated.’

A few were easy, static wins:

llms.txt is a plain-text index of the whole blog (every post, newest first, with excerpts), generated from the same content collection that powers the RSS feed, so it can never drift out of sync.
Content signals in robots.txt explicitly tell crawlers what they may do: yes to search, yes to being cited in AI answers, no to training models on my writing.
Discovery headers: an RFC 8288 Link header and a .well-known API catalog pointing agents at the endpoints that actually exist (/posts.json, the sitemap, the RSS feed) and nothing else.

The content signals are my favorite of the bunch, three lines that just say what I want out loud:

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Allow: /

Search engines, welcome. Cite me in AI answers, sure. Train a model on my writing? No thanks. It’s advisory, not enforcement. But it’s nice to be able to state the preference at all.

That “nothing else” matters to me. A lot of the checklist is about advertising APIs, OAuth flows, and tool endpoints, none of which a static blog has. The honest move isn’t to publish that metadata anyway; pointing an agent at endpoints that don’t exist is worse than staying quiet. So I shipped what’s real and skipped what isn’t.

But the one I actually cared about was serving Markdown. The idea: when an agent asks for a post with an Accept: text/markdown header, hand it clean Markdown instead of rendered HTML. Browsers still get the pretty page; machines get the source. This is the exact thing Ghost couldn’t do, and the reason it’d been nagging at me for months.

Funny enough, Cloudflare does have a native “Markdown for Agents” feature that does precisely this: flip a switch, done. Except it’s gated behind their paid plans, and my little blog is very much on the free one. So the built-in path was out. Fine. I’d build it myself.

So how are we doing it? The first part is a generator that emits a .md version of every post straight from the source at build time (resolving image and video URLs to their real paths along the way). The second part is a tiny Cloudflare Worker (all of 2 KB) that sits in front of the static files, checks the Accept header, and serves the Markdown twin to anything that asks for it. Everyone else gets HTML, untouched. The whole interesting bit is about a dozen lines:

// Only HTML page routes reach this Worker. If the client prefers Markdown,
// serve the build-time .md sibling; everyone else gets HTML, untouched.
if (mdPath && prefersMarkdown(request.headers.get('Accept'))) {
  const md = await env.ASSETS.fetch(new URL(mdPath, url));
  if (md.ok) {
    return new Response(await md.text(), {
      headers: { 'Content-Type': 'text/markdown; charset=utf-8', Vary: 'Accept' },
    });
  }
  // No Markdown variant for this page. Fall through to HTML.
}
return env.ASSETS.fetch(request);

The whole thing weighs nothing, costs nothing, and does something my old CMS fundamentally couldn’t. If you’re an agent (or just curious), you can watch it work:

curl -H "Accept: text/markdown" https://posts.oztamir.com/shell-in-the-ghost-migrating-to-astro/

You’ll get this very post back as clean Markdown. Open the same URL in a browser and you’ll get the page you’re reading now. One URL, two representations, picked by who’s asking.

That’s the kind of thing “total control” was supposed to buy me. Turns out it did.

So, was it worth it?

A weekend of work to replace something that already worked fine. No new features my readers will notice. Same posts, same URLs, same font (okay, for the first time, actually the right font).

But that was never the point.

What I came away with is a blog with nothing to patch and no server for anyone to break into, that costs me nothing to run, and that I have complete control over.

For years, the common wisdom has been that hand-rolling your own version of popular services is almost never the efficient call. There’s always something off-the-shelf that’ll get you most of the way for a fraction of the effort.

But with coding agents, that math changes. Building exactly what you want is suddenly cheap enough to be worth it. And what you get for the effort is the one thing no off-the-shelf product can hand you: a blog that does exactly what you want, because you’re the one who made it do that. That’s the part that makes it yours.

My blog used to be something I rented. Now it’s something I own, and I can get back to the only part I actually cared about in the first place: writing.

Let's write a harness (or: Harness Engineering 101)

Oz Tamir — Sat, 06 Jun 2026 12:57:11 GMT

I was sitting with a few colleagues a while back - the kind of engineers who make you feel slow in a code review - and we got to talking about coding agents. Which one’s worth paying for, where they fall on their face, the usual.

Somewhere in there one of them said, more thinking out loud than asking, “honestly I’m not sure how the agent even picks what to read. Does it just get the whole repo?”

Nobody answered. We moved on.

But it nagged me. Look at everything packed into that one shrug. Something reads the file off the disk. Something decides which file, how much of it, and whether reading a file is even the right move right now. Something holds onto what you said three turns ago so it’s still around on the next one. That’s a pile of work and a pile of decisions - and all of it is plain code that somebody sat down and wrote.

That code has a name. It’s the harness. And the people leaning on it every single day had never looked inside it.

What got me is how boring it is in there. No secret sauce, no orchestration trick the Cursor or Claude Code people figured out that the rest of us are just renting. A harness is an HTTP POST in a while loop: send the model some text, get some back, run whatever it asked for, go around again. That’s not me simplifying for the blog. That’s the shape of the whole thing.

So I ran a workshop for my team and we built one from scratch, together, in an afternoon. This is that workshop, on the page.

We’ll start with an empty file and end with a working coding agent - every line that matters, nothing hand-waved. By the last section, the only thing between you and your own harness is the time it takes to type it out.

No magic. Let me show you.

Agent = Model × Harness

Before any code, one piece of vocabulary - and it’s worth borrowing the real-world meaning, because it’s the whole point.

A harness, the original kind, is the rig of straps you put on a horse. It doesn’t make the animal any stronger - it gives you reins, so all that power goes where you want it. Without it you’ve got a very capable animal and no way to steer.

An agentic harness is the same idea, pointed at a model instead of a horse.

The model is the power - it can write code, reason about a bug, plan a refactor. But on its own it’s a horse with no reins: text in, text out, and that’s the end of its reach. It can’t open your files, run your tests, or remember what you said a minute ago. The harness is everything we strap around it to fix that.

Concretely, it’s the code that:

feeds the model context - the system prompt, your files, the conversation so far
runs the tools the model asks for - reading a file, running a command, searching the web
remembers - holding the whole back-and-forth so the model isn’t a goldfish
closes the loop - taking what a tool returned and handing it back to the model to react to
enforces the limits - deciding what the model is and isn’t allowed to touch.

None of that is the model. All of it is plain code we’re about to write.

So the agent you use every day is both halves together: Model × Harness

That’s why the same model feels like a different tool depending on where you meet it. It’s the same Claude Opus 4.8 behind Cursor, behind Claude Code, behind OpenCode - same brain every time. What changes is the rig around it. The harness is the part you can shape, which makes it the part worth understanding.

So let’s go build one. From the most boring possible starting point.

A REPL with a borrowed brain

For the purpose of the story, let’s say we are the maintainers of a tiny open source Python library called slugkit with one function, slugify, that’s supposed to turn "Hello, World!" into a clean URL slug.

Someone filed a bug: it’s spitting out hello--world with a double hyphen instead of hello-world. Our goal is to build an harness that can fix that bug.

We start, of course, with crafting our “brain” - a function that uses Anthropic’s Messages APIto allow us to make inference calls to the LLM:

def model(messages, system="", tools=()):
    return requests.post(
        "https://api.anthropic.com/v1/messages",
        headers={"x-api-key": ANTHROPIC_API_KEY,
                 "anthropic-version": "2023-06-01"},
        json={"model": "claude-opus-4-8", "max_tokens": 4096,
              "system": system, "messages": messages, "tools": tools},
    ).json()

That’s the model. You POST some messages, you get a response. There’s no state hiding in there, no session, no memory - every call is a blank slate. Hold onto that, because half of what the harness does is paper over it.

Wrap it in a loop and you’ve got the world’s dumbest REPL:

while True:
    user_input = input("> ")
    reply = model([{"role": "user", "content": user_input}])
    print(reply["content"][0]["text"])

Let’s give it the job:

> fix slugify
Sure! Here's a haiku about garden slugs:
  a silver trail glints -
  the slow wanderer at dawn
  leaves its mark, then gone.

…okay. In fairness, I said “fix slugify” to a thing that has no idea it’s a coding agent. It’s a general-purpose chatbot, “slugify” reads like a cute writing prompt, and we never told it otherwise.

Step 1: Adding a system prompt

So let’s tell it. The API has a system parameter that sits outside the conversation and allows us to specify the system prompt for our little agent - a set of foundational instructions given to an AI model that defines its role, behavior, tone, and constraints. It acts as the AI’s “job description,” guiding how it should respond to all subsequent user requests.

Here’s the system prompt that we will provide our little agent with:

SYSTEM = """You are a coding agent.
Make small, focused edits.
Prefer existing project patterns.
Run tests after every change.
Ask before anything destructive."""

reply = model(messages, system=SYSTEM)

Run it again:

> fix the slugify bug
Happy to help - which file is it in?
> src/text_utils.py
Thanks! So - what are we working on today?

It knows it’s a coding agent now. It asked the right question. There’s only one, tiny issue - it has no memory! That’s the blank slate biting us. Remember - each model() call stands alone - the second time around, the agent has no clue the first exchange ever happened. It’s a goldfish.

Step 2: Adding conversational history

The fix is almost insultingly simple: keep the conversation in a list, and replay the whole thing every turn.

messages = []                                          # the harness's memory

while True:
    user_input = input("> ")
    messages.append({"role": "user", "content": user_input})
    reply = model(messages, system=SYSTEM)
    text = reply["content"][0]["text"]
    messages.append({"role": "assistant", "content": text})
    print(text)

There’s the “memory.” It’s a list. Nobody’s keeping your conversation in some clever store in the server - the harness hangs onto every message and ships the entire transcript back, top to bottom, on every call. The model re-reads the whole thing each time and picks up where it left off.

It’s also why a long session gets slow and pricey, and why the agent eventually “forgets” something you said an hour ago. It’s all riding in that one list, and the list has a ceiling. More on that later.

For now: the agent has a job and a memory. It still can’t touch a single file.

The model is sealed in a box

Here’s the thing that took me longest to internalize: the model genuinely cannot do anything except produce text. It’s like a brain in a jar - it can think, but without the harness it cannot see or interact with the real world.

Which means tools aren’t a feature we’re bolting on for power. They’re the model’s only window onto the world. No tools, no eyes.

Step 3: Adding tools

So let’s give it one. Reading a file seems like a reasonable first verb:

@tool   # builds the JSON schema from the function signature
def read_file(path, offset=0, limit=120):
    """Read a line-numbered window of a file."""
    lines = open(path).read().splitlines()
    window = lines[offset : offset + limit]
    return "\n".join(f"{offset + i + 1:>4} | {ln}"
                     for i, ln in enumerate(window))

TOOLS = [read_file]

As you can see, tools are just ordinary Python functions - no LLM magic, everything deterministic.

The interesting part is what the @tool decorator does with it (and again, this is just a sample code - the code itself is not the point, it’s the concept that matters): it reads the signature and docstring and turns them into a plain JSON object - a contract the model can actually read. That object is the tool, as far as the model is concerned:

{
    "name": "read_file",                              # what the model calls
    "description": "Read a line-numbered window.",    # WHEN to reach for it
    "input_schema": {                                 # WHAT it must hand over
        "type": "object",
        "properties": {"path":   {"type": "string"},
                       "offset": {"type": "integer"},
                       "limit":  {"type": "integer"}},
        "required": ["path"],
    },
}

Four things: a name to call, a description telling the model when this is the right move, an input schema spelling out what arguments it can pass, and (back in our code, never sent) the actual function that runs. The model only ever sees the first three. It has no idea there’s a Python function on the other end - it just knows a verb exists and what shape the arguments take.

Now watch what actually goes over the wire. We send the conversation plus the tool contract:

POST /v1/messages
{
  "model": "claude-opus-4-8",
  "messages": [
    { "role": "user", "content": "fix the slugify bug" }
  ],
  "tools": [
    { "name": "read_file", ... }
  ]
}

And the model answers - not with text, but with a request to use the tool:

{
  "stop_reason": "tool_use",
  "content": [{
    "type": "tool_use",
    "id": "toolu_01abc",
    "name": "read_file",
    "input": { "path": "src/text_utils.py", "offset": 0, "limit": 120 }
  }]
}

When the harness sees this tool_use request, it calls a dispatch function that resolves the tool id to a handler function and runs it:

TOOL_HANDLERS = {"read_file": read_file, "edit_file": edit_file, "bash": bash}

def dispatch(block):                       # one tool request from the model
    name, args = block["name"], block["input"]
    try:
        handler = TOOL_HANDLERS[name]      # the model only handed us a name
        output = str(handler(**args))      # plain Python, running on your machine
    except Exception as e:
        output = f"Error: {type(e).__name__}: {e}"
    return {
        "type": "tool_result",
        "tool_use_id": block["id"],        # ties the answer back to the question
        "content": output,
    }

With the tool result in hand, the harness then sends the result back as the next message - wrapped so the model knows which request it’s answering:

POST /v1/messages
{
  "messages": [
    { "role": "user",      "content": "fix the slugify bug" },
    { "role": "assistant", "content": [ /* the tool_use block from above */ ] },
    { "role": "user", "content": [{
      "type": "tool_result",
      "tool_use_id": "toolu_01abc",
      "content": "   1 | import re\n   2 | def slugify(text):\n   3 | ..."
    }]}
  ],
  "tools": [ { "name": "read_file", ... } ]
}

The tool’s output goes with a tool_use_id that matches the id from its request, so it can line the result up with the right ask when it fired off several at once. Then the model gets the whole transcript again, sees the file it wanted, and decides what to do next.

That’s the whole mechanism. The stop_reason flips to tool_use, and the model hands back a name and a bag of arguments that match the schema we sent. It didn’t read anything. It can’t. It asked us to, and then it stopped and waited - because running the thing is our job, not its.

Which is the loop. Here’s the whole agent, every line:

messages = []
while True:                                   # one turn per thing the user types
    messages.append({"role": "user", "content": input("> ")})

    while True:                               # the agent loop
        response = model(messages, system=SYSTEM, tools=TOOLS)
        messages.append({"role": "assistant", "content": response["content"]})

        if response["stop_reason"] != "tool_use":
            print(text_from(response["content"]))   # no tool wanted - just answer
            break

        results = [dispatch(b) for b in response["content"]
                   if b["type"] == "tool_use"]
        messages.append({"role": "user", "content": results})

Read it slowly, because that inner loop is the entire game

We send the conversation and the tools.
The model either answers in plain text - in which case we print it and go back to waiting for the user - or it asks for a tool.
If it asks, we run the tool, drop the result into the conversation, and loop straight back to the model without stopping for input.
The model sees the result, decides what’s next, and around it goes.
Read, run, observe, repeat, until it’s got what it needs and finally just talks to you.

That’s a complete coding agent. After we added some more tools (ls tool, write_file tool, and some other basic ones) we can try to give it the bug again:

> fix the slugify bug in src/text_utils.py
  → read_file("src/text_utils.py", 0, 40)
  Found it: re.sub(r"\s", "-", text) replaces each whitespace character on its
  own, so "Hello, World!" - which has a comma AND a space - becomes "hello--world".
  → write_file("tests/test_slugify.py", ...)
  Added a failing test: slugify("Hello, World!") should be "hello-world".

It read the file. It actually found the bug - the regex matches single whitespace characters, so two in a row produce two hyphens. It wrote a test to prove it. With about forty lines of harness, the thing genuinely works.

Then it says:

  Now let me run the test to confirm the fix...
  → ??? there's no tool for that
  I can't actually execute anything - could you run `pytest -q` and paste the output?

Ah. It can read files and write them, but we never gave it a way to run anything. It’s stuck asking me to be its hands.

We could fix that by adding a tool for every command under the sun - one for pytest, one for git, one for grep, on and on forever. Or we could give it the one tool that already runs every command there is.

So we handed it a shell

The “tool for everything” plan falls apart the second you write it down. You’d need pytest and ls and cat and grep and find and mkdir and mv and git status and git diff and sed and curl and wc and… In the deck I gave for the workshop, had a slide that was just forty of these in tiny type, and the joke is that it isn’t even close to all of them.

You’d be writing tool wrappers until the heat death of the universe, and the agent would still hit the one command you forgot.

Step 4: Command Execution

Luckily, there’s already a program that runs every command there is. It’s the shell. So why don’t we just give the agent bash?

@tool
def bash(cmd, cwd, timeout=30):
    """Run a shell command. Truncate output to the last 8 KB."""
    proc = subprocess.run(cmd, cwd=cwd, timeout=timeout, capture_output=True)
    return tail(proc.stdout, 8 * 1024)

TOOLS = [read_file, edit_file, bash]

One tool. Now the model can run anything - pytest, git, a one-liner it makes up on the spot - and we don’t have to anticipate a thing. The tail is the only bit of taste in there: command output can be enormous, and we don’t want a find / dumping a megabyte into the conversation, so we keep the last 8 KB and toss the rest.

There’s only one tiny problem - we just gave a language model an unsupervised shell on our machine. It can run whatever it wants - including rm -rf, including curl something-sketchy | sh, including things neither of us thought of. The model is usually trying to help. “Usually” is not a security model.

Step 5: Sandboxing

But it’s not all bad. Remember - the model can only see and interact with the world through the lenses that the harness gives it. If we want, we can just give it lenses that, for example, can’t read your .env files! Or ones that prevents it from running dangerous commands!

The dumbest version that does anything is an allowlist and a denylist:

ALLOWED = ["pytest", "ruff", "git diff", "git status", "ls", "cat"]
DENIED  = [r"rm\s+-rf", r"sudo", r"curl.*\|.*sh", r"\bnc\b"]

def bash(cmd, cwd, timeout=30):
    if not any(cmd.startswith(p) for p in ALLOWED):
        raise SandboxError("not in allowlist")
    if any(re.search(p, cmd) for p in DENIED):
        raise SandboxError("matches deny pattern")
    return subprocess.run(cmd, cwd=cwd, timeout=timeout, capture_output=True)

Every command the model wants now has to pass through us first - allow it, refuse it, or rewrite it - before a single byte hits the shell. That’s the real shape of a sandbox: the harness sits between the model and the machine and gets the final say.

I want to be honest about what this is, though: this is not nearly good enough, and it will not save you. The model can write pytest; rm -rf ~ and sail straight past startswith("pytest").

Real isolation happens a level down - a locked-down process, a throwaway container, a filesystem the agent can’t escape - not a regex hoping to outguess a model that’s better at strings than you are.

Back to our slugify bug, the agent now has bash wired up, and it can finally close its own loop:

> fix the slugify bug in src/text_utils.py
  → read_file(...)        found the regex
  → edit_file(...)        \s → \s+
  → bash("pytest -q")     14 passed
  "Fixed - the test that was failing now passes."

It read the bug, fixed it, and proved the fix without me touching the keyboard. That’s the whole job, done.

So we’re finished, right? Ship it?

Not quite.

Context is scarce - and it’s the harnesses’ job to keep it clean

A one-line regex fix is the easy case. The real world looks more like this: before I let the change ship, I want to know if anything depends on the old buggy behavior. If some other code is feeding "a, b" to slugify and expecting a--b back, my fix just broke it.

So I ask:

> collapse the repeats in slugify - but first, does any caller depend
  on the old "a--b" output?
  → bash("grep -rn 'slugify(' src/")    31 hits across 18 files
  → read_file("src/api/routes.py")      1/18
  → read_file("src/cli.py")             2/18
  ... 16 more reads ...
  → read_file("src/feeds.py")           18/18
  "Reviewed all 18. Honestly? Hard to tell now - probably safe?"

Probably safe. On a question about whether it’s safe to change shared behavior, “probably” is the one answer I can’t use.

And it’s not that the model got dumber. Look at what we did to it. Every one of those eighteen files got read into the same conversation, and that conversation is the only thing the model sees on each turn. By the time it reached feeds.py, the window looked like this:

Thousands of tokens for file contents, and somewhere in the middle of it the actual question - does anyone rely on the double hyphen? - got buried under a landslide of imports and helper functions it didn’t need. The thing it was supposed to be reasoning about was a needle in a haystack the model built for itself.

This is the trap with one big context window: every tool result piles into the same place, relevant or not, and the signal-to-noise ratio quietly tanks. More reading made it worse, not better.

What I actually wanted was for someone to go read all eighteen files, think hard, and come back with one sentence - “checked them all, nobody depends on it, you’re clear” - without dumping the raw files on my desk. I wanted to delegate.

Step 6: Subagents!

Which is exactly what a sub-agent is. It’s the same loop we already wrote, running in a fresh, empty context, reachable as just another tool:

def run_subagent(task, tools):
    messages = [user(task)]                       # a brand-new context
    while True:                                    # the same loop. literally the same loop.
        r = model(messages, system=SUBAGENT_SYS, tools=tools)
        messages.append(assistant(r.content))
        if r.stop_reason != "tool_use":
            return summary_of(r.content)           # hand back the conclusion, not the mess
        for b in tool_uses(r):
            messages.append(user(dispatch(b)))

There’s no new machinery here. It’s model in a while loop with its own message list - the agent we built, called from inside the agent we built. The parent reaches it like any other tool:

report = run_subagent(
    task="Find every caller of slugify; flag any that rely on the old 'a--b' output.",
    tools=[read_file, grep, glob],
)

The sub-agent burns its own 22k tokens reading those eighteen files - in a context the parent never sees. All that comes back across the wall is the verdict:

"31 callers, all of them feed URL slugs; none depend on the doubled hyphen. Safe."

Eighty tokens instead of twenty-two thousand. The parent stays clean, keeps the thread, and gets a real answer instead of a shrug. The exploring happened somewhere else and only the conclusion made the trip back.

This is the first decision that isn’t about wiring at all. Nothing forced us to spin up a sub-agent - the single-context version ran fine, it just gave a worse answer. Where context goes, and what’s allowed to pile up next to what, turns out to be one of the biggest levers you’ve got. We’ll come back to that.

Don’t make the user the agent’s memory

There’s only one thing that still keeps this harness from being real - you still needs to tell it the same stuff, again and again.

Every. Session. The context resets, the agent shows up fresh and clueless, and the only thing standing between it and a repeat mistake is the user, remembering to brief it again. That’s backwards - humans are the ones with the bad memory. The harness should manage it!

And guess what? Most harnesses do.

Step 7: Agent Rules

Some knowledge is always relevant - the conventions, the gotchas, the “here’s how this repo works.” You want that in front of the model every single time, no questions asked. We call those rules.

Rules go in a file the harness reads on startup and staples to the system prompt. By convention it’s AGENTS.md:

# AGENTS.md
- String utils live in src/text_utils.py; tests in tests/.
- slugify must collapse repeated separators ("a, b" -> "a-b").
- We've had unicode regressions twice - keep the boundary tests.
- Verify with: python -m pytest tests/test_text_utils.py

That’s it. SYSTEM = BASE_PROMPT + open("AGENTS.md").read(), and now every session starts already knowing the lay of the land. The agent never asks “which file is slugify in” again, because the answer was sitting in its context before it read your first word.

This is the same AGENTS.md (or CLAUDE.md, or .cursorrules) you’ve seen in real repos - and now you know exactly what it does. It’s a string that gets concatenated onto the system prompt. That’s the entire mechanism.

It’s important to note, however, that rules do not actually mean that the agent can’t do what they say to avoid doing - they’re the same as regular prompts. The agent can choose to ignore them - which is why you shouldn’t rely on them for guardrails or for keeping the agent from causing harm.

Skills: expertise, written once, loaded on demand

The other type of knowledge only matters sometimes - the step-by-step for a specific job you do occasionally. Loading all of it on every turn would just be more haystack. You want it to show up only when the task calls for it. We call those skills.

For example - “How to safely fix a bug in text_utils.py” is a real procedure - reproduce with a failing test, make the smallest edit, run the unicode boundary suite, update the changelog - but it’s only relevant when the user is actually fixing a text_utils bug. Bolting all of that onto the system prompt for every task, including the ones that never touch text utils, is just noise.

So a skill lives on disk as its own file, and stays there until it’s needed:

# skills/fix-text-utils/SKILL.md
---
name: fix-text-utils
description: Fix a bug in src/text_utils.py safely.
---
1. Reproduce: add a failing test for the bug.
2. Fix the smallest thing - prefer an anchored edit.
3. Run the unicode boundary suite (accents, CJK, emoji).
4. Update CHANGELOG.md.

Now, how does it get loaded only when relevant? You might reach for some clever intent-matching router. You don’t need one. You already have a mechanism that picks the right thing at the right moment based on the task - it’s the model, choosing a tool.

load_skill is just another tool. The trick is what goes in its description: a tiny index of every skill and one line on when to use it.

load_skill = Tool(
    name="load_skill",
    description="Load a skill's full instructions. Available skills:\n"
                "  fix-text-utils - fix a bug in text_utils.py\n"
                "  cut-release    - bump version, tag, changelog",
    handler=lambda name: open(f"skills/{name}/SKILL.md").read(),
)

TOOLS = [read_file, edit_file, bash, run_subagent, load_skill]

The model sees the menu - just the names and descriptions, cheap. When I say “fix the slugify bug,” it reads fix-text-utils - fix a bug in text_utils.py, decides that’s the one, and asks for it like any other tool:

{ "type": "tool_use", "name": "load_skill", "input": { "name": "fix-text-utils" } }

dispatch runs the handler, which is one line - open the file, return its contents - and the full procedure lands in context exactly when it’s useful and never when it isn’t. The expensive part (the whole checklist) only gets paid for on the turns that need it.

And now the agent runs the unicode suite every time it touches that file. Not because it is smart and understands that this is the right way to do it - no. It’s because the knowledge lives in the harness, and the harness put it in front of the model at the right moment.

The loop is small. The decisions are not.

Let’s step back and look at what we built. Stripped to its bones, the whole thing fits on a napkin:

messages = []
while True:
    messages.append(user(input("> ")))
    while True:
        messages = compact(messages, BUDGET)
        response = model(messages, system=SYSTEM, tools=TOOLS)
        messages.append(assistant(response.content))
        if response.stop_reason != "tool_use":
            print(text_from(response.content))
            break
        for block in tool_uses(response):
            messages.append(user(dispatch(block.name, block.input)))

That’s a fully working coding agent.

A list, two loops, one HTTP call, one dispatch. There is genuinely nothing else. So if the loop is this small, where does all the difference between a good agent and a useless one actually live? Not in the loop

It lives in a handful of decisions, and every one of them maps to a line you just read:

What does it SEE? → model(messages, system=SYSTEM). The system prompt and everything you choose to put in the messages. Get this wrong and the model is flying blind or buried in noise.
What can it DO? → TOOLS = [read, edit, bash]. Three sharp tools or thirty dull ones. The verbs you hand it are the ceiling on what it can accomplish.
What’s its REACH? → TOOLS += [run_subagent, *skills]. Can it delegate, can it pull in a procedure, can it spin up help. How far past a single conversation it can stretch.
What’s REMEMBERED? → compact(messages, BUDGET). What stays in the window, what gets summarized away, what’s lost. Memory is a budget you spend on purpose.
What’s ALLOWED to run? → dispatch(name, args). The gate between “the model asked” and “the machine did.” Allow, refuse, rewrite.
What comes BACK? → response.content. The shape of every tool result. A raw file dump or a tight window. Garbage in here is garbage the model has to reason through.

None of these is in the model. All of them are choices someone made in the harness. That’s the punchline of the whole build: when people say one coding agent is “smarter” than another running the same underlying model, this is what they’re feeling. Not a better brain - better answers to these six questions.

Two of them carry more weight than the rest, and they’re worth naming. Tool design - what the model can do and what shape the results come back in - and context engineering - what’s in the window and what isn’t. Most of the gap between an agent that nails the task and one that shrugs “probably safe?” comes down to those two. The rest is plumbing.

From theory to practice: the harness we actually run

That whole build was a toy. Forty lines, a slug bug, a story to hang the concepts on. But the reason I care about any of this is I actually got to build a real one for our GTM team at Orb, which is how I got to dive into Harness Engineering at the first place.

Some context. From day one, our goal at Orb was to build an AI-first culture - which meant that we wanted everyone at the company, not just R&D, to be using AI the way engineers already do - not as a novelty, as the default way work gets done.

The problem is that an account executive is not going to configure an MCP server or paste an API token into a config file. The tools they live in - Salesforce, Linear, Slack, Notion, Granola - each have their own auth system, and stringing them together is a wall most people bounce off before they get any value. Handing them Claude Code and a setup guide was never going to work.

So we built our own harness for them. It’s called gtm-os, it’s built on pi.dev and it’s the same model everyone else uses - we just wrapped it for how this team actually works. Three choices made the difference.

No MCP. Every integration is a native tool the harness calls directly - using the platform’s native APIs. While this required more work for us up front, it allowed us to make our decisions on how we want the tools to look like and how the authentication story looks like.

Since we own the auth flow, we could use our SSO solution to login into everything! Which means that the AE logs in once through the browser with our company SSO - and everything else is auto-magically logged on, with nothing to install or configure. The harness holds that session and reuses the token for every native tool. Salesforce, Linear, Slack, Notion - they all authenticate silently behind the one login. The setup wall is gone because there’s no setup.

It’s mission-specific. This isn’t a general-purpose agent pretending it can do anything - it has one job, so we baked the flows straight in. On launch it caches the deals the AE owns and watches every prompt for a company, contact, or competitor we track. When it spots one, it injects that context before the model even runs - so the agent walks in already briefed instead of spending its first three tool calls figuring out who you’re talking about. That’s the “what does it SEE” lever, cranked all the way up.

Here’s what that buys, concretely. Same request, two harnesses.

A generic agent, pointed at the same tools over MCP:

Six round trips, ~18k tokens, about two minutes, and it dead-ends on an auth prompt the AE can’t clear. So they close the tab and do it by hand. That’s the setup wall winning.

gtm-os, same prompt:

One tool call, ~3k tokens, about six seconds, done. Nothing about the model changed between those two runs. It’s the same brain. Every bit of that difference - the instant recognition, the silent auth, the answer instead of the shrug - lives in the harness.

There’s nothing stopping you

Go back to that conversation with my colleagues - the smart ones, stuck on “maybe it just sees the whole repo?” The gap was never that harnesses are hard. It’s that nobody had shown them the inside, so the whole thing stayed filed under magic.

There’s no magic. You watched the entire trick: a list, two loops, one HTTP call, and a function that runs what the model asks for. Everything that makes an agent feel smart - the memory, the tools, the sub-agents, the skills, the sandbox - is plain code wrapped around a model that, left alone, can only emit text. The model is the horse. The harness is the reins. And the reins are the part you can actually build.

That’s the bit I most want you to walk away with. The same model sits behind Cursor and Claude Code and the thing we run at Orb. They feel different because someone made different choices about what it sees, what it can do, and what comes back - not because anyone had a better brain to work with. Those choices were the whole job.

They’re also choices you’re completely capable of making.

Go deeper

If you want to push past the toy version, here’s where I’d send you. Roughly in the order I’d read them.

Anthropic - Context Windows - the clearest diagrams I’ve seen of what’s actually piling up in the window turn over turn. The pictures alone are worth it.
Anthropic - Context Engineering - the deep version of the lever I called the most important, with a real worked agent (run_research_session) you can read top to bottom.
LangChain - Anatomy of an Agent Harness - the same teardown I did here, from a different angle. Good for triangulating the concepts.
Martin Fowler - Harness Engineering - less of a build guide, but the graphics are great and it takes the “harness as its own discipline” framing seriously.
Inside the Agent Harness - how Codex and Claude Code actually work under the hood, for when you want the real ones instead of my forty-line one.
learn-claude-code - a full reference implementation of a harness, if you’d rather read working code than prose. There’s a web version too.

And the two API docs everything above is built on:

Messages API - the model() function from the very start, documented properly.
Tool Use - the contract, the tool_use / tool_result round trip, all of it.

Syncing skills, rules and subagents across repos with amgr

Oz Tamir — Wed, 04 Feb 2026 12:58:20 GMT

If you’ve spent any real time with agentic tools, you’ve felt this: rules, skills, and configs scattered across half a dozen projects with no real linkage. You spin up a new repo and immediately face the same boring questions: where’s my base rule set, what’s the right boilerplate, which tools need which files?

Even with the ecosystem moving in the right direction, the core problem doesn’t go away. Tools like Vercel’s skills.sh help with what an agent can do, but not how you bootstrap a new project, or how you keep different kinds of rules in sync across personal, work, writing, and side projects.

Last week I ran into it again. I was setting up another repo and caught myself copying the same Cursor rules and docs guidelines I’ve already pasted into three or four other places. It wasn’t hard - just dumb. And it never ends.

That’s when the question finally landed:
why am I rebuilding the same agent setup every time I start a new project?

I wanted one source of truth: write once, use everywhere. I couldn’t find a sane way to do it - so I built one.

The Problem: One Brain, Many Contexts

The mess isn’t just file formats. It’s that I need different agent setups for different kinds of work, and I’m doing that across a pile of repos.

Backend repo: heavy coding rules, test commands, debugging skills. Frontend repo: UI patterns, different MCP servers. Writing repo: tone and structure, zero coding noise.

I can build these setups manually, but it doesn’t scale. If I tweak my base rules, I have to remember which repos should inherit it and which ones shouldn’t. If I add a new “writing voice,” I have to thread it through the right places without leaking into code projects.

So the real pain is this: I want one source of truth, but I need selective deployment.

That’s the hole amgr (agents manager) is trying to fill.

The Idea: One Rules Repo, Selective Sync

amgr’s mental model is simple: keep a single “rules repo” that holds your agent brain, then sync only the parts each project actually needs.

In practice, that looks like a repo with:

shared/ - rules that should apply everywhere
development/ - a nested profile, with sub‑profiles like frontend/ and backend/
writing/ - a flat profile for tone, templates, and docs
(and any other profile you might want)

Then each project gets a tiny .amgr/config.json that says: which tools, which features, and which profiles to pull in.

You write once. You sync everywhere. And the right rules land in the right repos without manual glue.

Examples: one repo, selective sync

So what does that look like in practice? Here’s the short version.

amgr uses a rules repo: one repository where your agent configs live (rules, skills, subagents, commands). You don’t copy files between projects anymore. You sync slices.

Create one like this:

mkdir ~/Code/my-agents && cd ~/Code/my-agents
amgr repo init --name "my-agents"

Then I split it into profiles (think: contexts):

amgr repo add development --description "Coding and debugging"
amgr repo add writing --description "Documentation and content"

Now the repo has a home for shared rules, and separate buckets for dev vs writing. Mine ends up looking like this:

~/Code/my-agents/
├── shared/
│   └── rules/
│       └── tone.md            # applies everywhere
├── development/
│   ├── _shared/
│   │   └── rules/
│   │       └── testing.md     # shared across dev sub‑profiles
│   ├── backend/
│   │   └── agents/
│   │       └── db-tuner.md    # a subagent for database work
│   └── frontend/
│       └── skills/
│           └── ui-checker/    # a skill for UI reviews
│               └── SKILL.md
└── writing/
    └── rules/
        └── voice.md           # writing voice + style

Now the fun part: each repo only pulls what it needs.

Example 1: backend repo (dev:backend)

.amgr/config.json:

{
  "targets": ["claudecode", "cursor"],
  "profiles": ["shared", "development:backend"]
}

amgr sync brings in:

shared/rules/tone.md
development/_shared/rules/testing.md
development/backend/agents/db-tuner.md

No frontend UI skills. No writing voice.

Example 2: writing repo (writing)

.amgr/config.json:

{
  "targets": ["claudecode"],
  "profiles": ["shared", "writing"]
}

Now you get:

shared/rules/tone.md
writing/rules/voice.md

No coding rules. No dev subagents. Clean writing context only.

Example 3: frontend repo (dev:frontend)

.amgr/config.json:

{
  "targets": ["opencode", "cursor"],
  "profiles": ["shared", "development:frontend"]
}

You get the shared rules, the dev‑shared testing rules, and the ui-checker skill - but none of the backend‑only subagents.

That’s the trick. One repo. Many profiles. Each project gets the right slice.

Why this matters (and why now)

The ecosystem is moving. As I mentioned, Vercel recently shipped the skills CLI and skills.sh directory, and that’s a big deal. It makes skills shareable and discoverable across tools.

But skills solve only one part of the problem: the “what can my agent do?” question. The daily pain is still “how do I spin up a new project with the right brain and keep it in sync?” That’s where a rules repo + selective sync matters.

If this stuff becomes native across tools, amgr should disappear. Until then, I want one source of truth and a clean way to slice it per project.

Let's create a Wolt Extension for Raycast

Oz Tamir — Sat, 20 Dec 2025 11:31:01 GMT

Over the past week, I was introduced to a tool called Raycast. Raycast is a macOS launcher that turns your keyboard into a control center for… pretty much everything.

Naturally, once I got comfortable with it, I started mapping my daily services into Raycast. Linear? Covered. Home Assistant? Of course. GitHub? Naturally.

This became sort of a game - looking for new extensions to try, as each one meant a new functionality incorporated into this tool I began to use daily.

Then I started thinking deeper - what tools don’t have an extension, but an extension for them might be useful?

I immediately knew the answer - I wanted a Wolt extension! And since none existed, the only solution was to write it out myself.

Getting Wolt Data

The first order of business, even before I opened the docs for Raycast, was getting the relevant data from Wolt.

This is not my first time playing around with the Wolt API - I had previously wrote a Telegram bot that interacted with the API, and even made it into a private app a few months later.

But that was almost 4 years ago - I had no idea if the same API is still in use, and since Wolt does not provide a consumer facing API docs, I had no way of knowing if it changed.

Luckily for me, I didn’t had to put in the hard work myself - Upon a short google search, I found a repo called PyWolt which had already implemented a lot of the required functionality. I played with the examples from the README, and was happy to learn that it works perfectly.

The only problem? Raycast extensions are written in Typescript, not Python, meaning that I couldn’t just use the library as it is - I needed to rewrite it in Typescript.

Good thing we live in an AI age.

Rewriting a Python SDK in Typescript with Codex

As it just happened to be, it was only a few days ago when I read this articleby Simon Willison about using Codex, OpenAI’s agentic coding tool, to port a Python library called JustHTML (itself written by coding agents) into Typescript.

This seemed to me like an interesting concept to play with, and an interesting detour from my main quest - but a one worth taking. My plan was simple, and it involved two steps:

I will first generate a specs docs based on the existing Python implementation.
I will then use this document to create a Typescript library.

As a side note, this is quite different from the approach used by Simon, who had just gave Codex access to the full library code. The reason I went with a different path is that unlike JustHTML, here I cared less about the actual library - it’s just a wrapper around the Wolt API, and I cared more about the API itself than about the library.

Creating a Spec document

To kickoff the first step, I cloned the PyWolt repo and started Codex in it. I gave it a short prompt - read this codebase and produce a markdown documentation of the Wolt API and sent it on its way.

Along the process, I also asked it to add cURL examples and to run these examples by itself beforehand to ensure that they work and that the document is accurate.

The completed document is available as a gist here.

Creating a library

For the actual implementation of the spec, I choose to again deviate from Simon’s article and used Cursor with Composer 1 as the model. I had a good experience with it, its blazing fast, and since this project does not require a lot of heavy thinking, I figured I could get away with not using the SOTA thinking models in this project.

Much to my delight, this proved to be a good decision - as Composer 1 was able to effectively one-shot this task. The only missing item was tests, but after pointing it out Composer stepped up and finished the job.

After ensuring that everything work, I used npm publish to push the library to npm, where it is now available to install. The source code is available here.

Creating a Raycast Extension

Once I had the library ready to go, it was time to get back to the main storyline - and start working on the Raycast extension.

I read the documentation and learned that in order to create a Raycast extension, one should - how convenient - use Raycast! This is done through a command called “Create New Extension”, which opens a configuration dialog.

An interesting part of this process is that you can configure the commands and tools that will be made available through your extension through this creation command. While I will be adding multiple commands and tools, I elected to start with a simple one - venue search - in order to get acquainted with the SDK before diving into deep water.

I let the wizard run, and was greeted with a new repository containing a template of a command that searches npm - exactly the same experience I wanted to replicate with my extension!

Implementing Commands and Tools

From that moment onwards, most of what I did was prompting an agent to wrap the library we wrote at the beginning with commands and tools.

The first tool I implemented was the venue search - and it was a delight to create, as the Raycast SDK is very easy to use. It was simply about getting a response from the API and rendering it into a list view.

Once I added the basic commands, I started adding more and more functionality - I added a way to pick a city (using the Raycast preferences APIs), I allowed users to view the menu of a venue through the extension, and more.

This was a really interesting experience because as I went along I found some issues in my library code. Luckily for me, I could simply use Cursor’s browser tab to debug any API calls that did not work, which saved me a ton of time and effort.

Publishing the Extension

The last part of this process is to publish the extension to make it available in the Raycast Store.

Like the other steps in this process, this was also fairly easy - all it took was to run a pre-configured npm script that opens a pull request at the Raycast Extensions repository on Github.

While this will (hopefully) be merge into the bigger repository soon, the code is also available on my personal repository.

Conclusion

This was a fun project, and I’m very happy with the result - while not the most practical thing in the world, this was a good experience for trying out Raycasts extensions.

Additionally, I think that I might make a lot of use out of this API wrapper - I already have plans to play around with a Wolt MCP for automatic food ordering.

Stay tuned 👀

From WhatsApp to Todoist: an n8n + Whatsmeow automation

Oz Tamir — Tue, 14 Oct 2025 13:58:26 GMT

I make a lot of promises on WhatsApp.

“Yeah, I’ll send that later.”
“Sure, I’ll ask him.”
“Remind me to book it tomorrow.”

But more often than not, I never do.

It’s not that I don’t want to do these things. It’s just that unless I stop everything I’m doing right there, open Todoist, and add the task manually, there’s a solid 50/50 chance I’ll forget about it entirely.

After this had happened one time too many, I figured that it’s time to do something about it. After all, this is 2025 - the age of AI! It’s simply unacceptable that so many of the tasks I commit depend on a me remembering to file them. There has to be a better way.

The plan: Monitoring messages with AI

Once I accepted that I clearly can’t be trusted to remember my own commitments, I figured I might as well outsource the job.

The goal was simple: I wanted something that could read my WhatsApp messages, figure out when I promised to do something, and make sure it ended up in Todoist - without me lifting a finger.

At first, I thought this would be easy. Just plug into WhatsApp somehow, run the messages through an LLM, connect Todoist’s API, done. Right?

Not quite.

Turns out, there’s no “nice” way to monitor your own WhatsApp messages. The official APIs are meant for businesses, so if I wanted to make this work, I’d need to start with step one: getting access to my own WhatsApp data.

What about the WhatsApp MCP Server?

If you recall, in a previous post I used a WhatsApp MCP server to do something similar. So you might ask - why not use it again?

Well, unlike in the previous post, this project was meant to run in a cloud hosted VPS. Now, while I trust in my ability to secure servers, this means that the risk is higher - and I wouldn’t want my entire WhatsApp history sitting in a VPS.

I also didn’t need all the bells and whistles that come with MCPs. I wasn’t trying to build a chatty AI that replies to people. I just needed a way to read messages.

Building A WhatsApp Listener

So, what did I do?

I read through the MCP Server documentation, and found out that it is using a Go package called whatsmeow that implements a WhatsApp client using their Web MultiDevice APIs.

So, I took the example code for this package and hacked together a small Dockerized application called whatsapp-aggregator.

This app uses the API to listen in on new messages and store them in a local Sqlite3 database:

client.AddEventHandler(func(evt interface{}) {
	switch v := evt.(type) {
	case *events.Message:
		senderType := "from"
		if v.Info.IsFromMe {
			senderType = "sent by me to"
		}

		log.Printf("Received message %s %s in chat %s: %s",
			senderType, v.Info.Sender, v.Info.Chat, v.Message.GetConversation())

		// Store message in database
		if err := messageDB.InsertMessage(v, client); err != nil {
			log.Printf("Failed to store message: %v", err)
		} else {
			log.Printf("Message stored successfully")
		}
	}
})

In addition, to make sure that we store as little data on the server as possible, a Python script is also running alongside the Go package.

This script runs every few minutes and deletes old messages - ensuring that the server only keeps the last 24-hours worth of messages.

Gathering Context for the Agent

With the messages now available on my server, I needed to deal with the automation part.

Like in previous cases, I decided that I would use n8n for the workflow, but quickly ran into an issue - n8n did not have a native Sqlite integration!

Luckily, the n8n community nodes came to the rescue - and I found a simple node that allowed me the query the DB called n8n-node-sqlite3.

Next order of business was getting existing TODOs out from Todoist. I didn’t want to get duplicates - so if there’s already a task for something I mentioned on WhatsApp, I didn’t want the agent to create another one.

To get the existing tasks, I initially used the n8n Todoist node - but I quickly ran into an issue. When using this node to query existing tasks, it would not return completed tasks - which meant that once I marked a task as done it would be re-added by the agent.

To go around this issue, I used a custom HTTP node that directly called the API to get the completed tasks.

Once I had both the completed tasks, the open tasks, and the messages history, I had all the context I needed to fire up the agent itself.

Creating a Gemini Agent…using Claude???

Now, I knew I wanted to use Gemini as the LLM for this agent because I had good experience with how it handles tasks. However, I knew that writing the prompt for this on my own would be a hard task.

Instead, I decided to use another LLM! I fired up Claude Sonnet, and fed it instructions on how I want this agent to work.

In addition to my instructions, I gave it this screenshot, from the Anthropic talk Prompting 101 - which I recommend watching for everyone working on agents.

Basically, this is the structure recommended by Anthropic researchers for how to construct a prompt - including things like context engineering, giving the model concrete examples, and more.

After some back and forth with Claude, I had a 500-lines long prompt that started like this:
You are an intelligent task management assistant that analyzes WhatsApp conversations and Todoist tasks to identify missing action items. Your goal is to help users capture commitments and action items that haven't been added to their task list yet. You should maintain a precise, analytical tone. Be conservative in your analysis - it is better to miss an action item than to create duplicate or unnecessary tasks.

The full prompt is available here.

Creating the task and notifying about it

Once the agent had came up with a list of tasks, all that’s left to be done is to add them to Todoist.

For this I am once again using the Todoist node - and I make sure to add the n8n-generated label to ensure that I know that these tasks were auto-generated.

Once the task had been created, I added one final node that uses Pushover to sends out a notification about the new task with a link to the task in Todoist.

This is useful to allow me to get feedback that the system is running properly and that new tasks are being added.

Conclusion

And that’s it. My “personal assistant” now quietly listens to my WhatsApp chats, figures out what I’ve committed to, and keeps Todoist up to date. This is what the final n8n workflow looks like:

It’s a small thing, but it echos my favorite type of hacks - ones that blend seamlessly into the background of your life, and help make them better - one message at a time.

Reverse Engineering APIs with Chrome DevTools MCP

Oz Tamir — Sat, 27 Sep 2025 11:36:47 GMT

As all good stories go, this one too starts with a wedding - my wedding.

As part of the preparations, I found myself working on a small vibe-coded project that required me to get my hands on a bunch of meme templates. We are not talking one or two - I needed every template I could get my hands on.

Luckily for me, I found an Israeli website loaded with a bunch of templates - thousands of memes, neatly categorized. Exactly what I needed.

The only problem: there was no easy way to get them out. No export button, no public API, just an endless scroll of templates locked behind the frontend.

So naturally, I decided I’d have to scrape it.

Enter: Chrome DevTools MCP

While I was pondering what is the right approach here, I was scrolling X when I came across a newly released tool.

The Chrome team had just announced that they are releasing a public beta of their DevTools MCP - way for agents to interact directly with the browser.

Reading through their announcement, one feature immediately caught my attention: the MCP provided tools for inspecting network requests.

Could this be exactly what I needed? Instead of manually digging through requests in DevTools, could I just point an agent at the site and ask it to figure out the meme website’s API for me?

Task Failed Successfully

I set up the new Chrome MCP and connected it to Claude Code, which I instructed to research the website and come up with an API client.

This is the prompt I was using:

You are a QA Engineer tasked with creating a Python script that interacts with an API in the company's website.

However, to ensure accurate testing, you were not provided with the API specs.

Instead, I want you to use your Chrome Tools to go to `[MEME_WEBSITE]` and inspect the network requests until you figure out how to interact with the API.

You can use other Chrome tools to interact with the website if needed.

Your output should be a Python script that implements an API client and another script that consumes it.

Use ultrathink .

(If you’re unfamiliar - ultrathink is a magic word that makes Claude work harder)

On paper, it sounded perfect. Claude would load the site, inspect the network requests through Chrome’s MCP, and reverse engineer the API without me having to touch DevTools manually.

In reality, it failed almost immediately.

The problem was that the website was sending too many requests, and when the agent used the MCP tool to get information, it would immediately hit it’s token limits.

The experiment had technically worked — the MCP was capturing requests just fine — but there was simply too much noise for the LLM to handle.

Open Source to the Rescue

At first I thought that was the end of it. If the MCP was going to drown in every single request, then this whole approach was dead on arrival.

But then I remembered — this wasn’t a black box product from Google. The DevTools MCP is open source. Which meant I didn’t have to accept its limitations. I could just… fix them.

So I cracked it open and started coding.

The main issue was that the list_network_requests tool returned everything in one giant dump. To overcome this, I added some parameters to the tool - allowing the calling agent to paginate and filter so that it would only get the requests it cares about, and would be able to process them in manageable chunks.

Half an hour later, I had a pull request open - and not long after, it was merged.

For me, this was yet another cool demonstration of how open source tools are the best - if something ain’t working for you, you can simply jump to the trenches and fix it for you and for everyone.

One-shotting API clients with Claude

With my little side-side-quest over, I got back to the original side-quest - getting Claude Code to reverse engineer an API for me.

This time, thanks to the new pagination option, Claude was able to process the API requests in small chunks - and what can I say?

IT CRUSHED IT.

First, it identified the endpoints behind the meme feed:

Then, it mapped out how the site organized categories, how the JSON payloads looked, and where the images were actually hosted:

And once it had a clear enough picture, it went ahead and started generating the Python API client:

Boom. Nearly 300 lines of clean, working code. A fully reverse-engineered client for an undocumented API, generated in one shot.

Watching this unfold in real time felt surreal - like pair-programming with an intern who could read Chrome’s network tab faster than humanly possible.

Conclusion

The Chrome DevTools MCP isn’t just another developer toy. It’s a genuine superpower for anyone doing web research, scraping, or API reverse engineering.

The ability to hook an agent directly into Chrome and let it see the same network requests you would in DevTools completely changes the workflow.

If your work involves poking at undocumented APIs, this tool deserves a spot in your toolbox. It takes what used to be a tedious, manual grind and turns it into a collaborative process with an agent that can actually do the heavy lifting.

And in my case? Well, all I got left is to make something worthwhile with all these meme templates.

Solving Multi-Calendar Conflicts with n8n

Oz Tamir — Mon, 02 Jun 2025 15:18:26 GMT

Like most folks, my work calendar and my personal ones live in different accounts. And when I schedule something over on my private calendar (one of them, I use four different ones because I’m crazy), my coworkers don’t see any of that - they only see my work calendar.

So when they’re looking for a free slot, it looks like I’m wide open - even if I’ve already committed to something else. And it’s driving me crazy.

This past week, after enough double-bookings and awkward “hey, can we reschedule?” messages, I got tired of manually fixing things. I wanted my work calendar to at least know when I’m busy, even if it doesn’t need to know why.

Like most recurring annoyances in my life, this felt like something I should be able to automate.

Oh yeah, it’s automation time

The idea was simple: take events from my personal calendars and reflect them onto my work calendar as generic “busy” blocks. No details, no descriptions. Just enough to stop coworkers from accidentally double-booking me.

To make this work, I had a few clear requirements:

Local-first - I didn’t want to give any third-party service read/write access to both my personal and work calendars.
Full control - I wanted to decide which events to sync, how they’d be translated, and what metadata (if any) gets shared.
Minimal setup - Ideally, something I could get running in under an hour without writing a pile of boilerplate.

Since I already had a local n8n instance running (left over from another automation I built around WhatsApp MCPs), it felt like the obvious choice. It ticked all the boxes — and I jumped straight into it.

Setting Up Google Calendar Access

Before I could do anything useful, I needed to let n8n access my personal calendars.

That meant setting up a Google Cloud project, enabling the Calendar API, configuring the OAuth consent screen, and creating OAuth2 credentials.

Nothing too surprising, just a series of Google Console forms you have to fight through. In the credentials setup, I selected “Web application” as the type and added n8n’s OAuth2 redirect URI.

Once Google gave me the Client ID and Secret, I dropped them into a new credential in n8n using the built-in Google OAuth2 option.

If you’ve ever done anything with Google APIs, you’ve seen this dance before. If not, the n8n docs explain it better than I want to.

Automating the Sync

The workflow I created runs every 6 hours. That’s usually frequent enough to keep things in sync without spamming the API or hammering my work calendar.

The first thing it does is fetch events from my personal calendars that were updated in the last 6 hours.

This includes new events, updates, and cancellations - basically anything that might require an update on the work calendar side.

Each calendar (I have a few) gets queried separately using the getAll operation on the Calendar API.

I use the updatedMin parameter to filter only recent changes, which is 6 hours in my case:

{{ $now.minus({ hour: 6 }) }}

After pulling from all of my personal calendars, the events are merged into a single list and processed from there.

Syncing Events to Work Calendar

Once all updated events are pulled and merged, the workflow goes over each one and decides what to do based on its state.

Cancelled Events

If the event was cancelled, it’s deleted from the work calendar. I check for status === "cancelled" and route those into a Delete node.

Nothing fancy. If it’s no longer happening, it shouldn’t block time on the work side either.

New Events

If the event is new, it gets copied over to the work calendar. The copied version keeps the same start and end time, but I override a few fields to keep things clean and private:

The event is marked as private
The title is just "Blocked for Personal Event"
Visibility is set to “busy” so it shows up as unavailable to coworkers

I might eventually include the original event title here, but since I don’t know exactly who can see what in our org’s calendar setup, I’m staying on the side of caution for now.

Updated Events

If the event already exists on the work calendar (based on ID), the creation step throws an error. I catch that and instead run an update, making sure the start and end times are synced.

This takes care of reschedules or time changes without having to delete and recreate anything.

Wrapping Up

This workflow has been running quietly in the past week, and so far it’s doing exactly what I wanted: keeping my work calendar aware of my personal time, without oversharing or manual juggling.

It’s not doing anything groundbreaking (just moving data from A to B with a bit of filtering and formatting) but that’s the kind of automation I like best. Clear input, predictable output, no surprises.

I might tweak it over time (maybe loosen up the visibility settings, or add color-coding per calendar), but for now, it’s doing the job.

My calendars don’t fight anymore.

That’s a win.

Claude is now my micro-manager

Oz Tamir — Wed, 16 Apr 2025 09:01:34 GMT

I recently sat down with my manager to lay out the plan for the coming quarter. We framed the conversation around OKRs as a way to get clear on what we actually want to achieve.

For those unfamiliar, OKR (which stands for Objectives and Key Results) is a goal-setting framework popularized by companies like Google.

The idea is simple: you set a few high-level objectives that define what success looks like and then attach measurable key results that tell you whether you’re getting there. It’s like a to-do list if your most ambitious self wrote it.

Source: Dmytro Yarmak

I know some people dislike OKRs, but I, for one, love them. They’re a great way to cut through the noise and focus on what matters. They force you to think strategically, pick a direction, and aim for impact - not just activity.

But while OKRs are great at helping you zoom out, they don’t always help when you zoom in. They tell you what to achieve but not how to get there. And if you’re anything like me, that’s where things can start to wobble - especially once the quarter is underway and your calendar is full of other people’s priorities.

So I enlisted some help - I asked an LLM to micro-manage me.

The idea? Let the LLM do the planning

Typically, once the OKRs were set, I’d sit down and try to break each Key Result into subtasks, estimate how long things might take, juggle dependencies, and then still get halfway through the quarter and realize I forgot something important.

But this time, I wanted to try something different. Instead of doing all the breakdown and planning manually, I asked an LLM to help.

My thinking was simple: this isn’t a creative task - it’s a reasoning task. It has structure, inputs, and constraints, making it perfect for a model good at structured reasoning.

Building the plan

To get started, I used OpenAI’s reasoning model - O1. The ask was simple: “Turn my OKRs into an actual execution plan: week-by-week, task-by-task.”

Because I know that I sometimes struggle with context-switching, I told it to assume a “one day = one task” cadence - no juggling multiple things in a single day. Additionally, I asked it to break down anything too big into smaller chunks. I asked it to consider task dependencies and keep the whole timeline in mind to ensure I hit the goals on time.

This is the prompt I used:

These are my OKRs for the coming quarter.
Today is April 16. The OKR target date is July 31.

Help me plan a week-by-week task list - each task should be something that can be done in a day (if something needs more time, break it down into smaller tasks).

For each task, you should write:
* Title
* Description
* Start date
* DoD (Definition of Done)

Organize the tasks into logical groups - each group should translate into one of the key results. For each group, set a start date and an end date.

Make sure you take into account both the target dates in the OKR and the fact that some of the KRs are dependent on one another.

The result wasn’t magic - but it was good. It was good enough that with just a little bit of back-and-forth, I had something that looked like an actual, trackable plan.

Each KR had a timeline. Each task had a clear outcome. And most importantly, I could look at any given week and know exactly what I needed to do.

Planning done. Now, it was time to get everything up on the board.

Getting the Tasks Into a System

With the plan in place, the next step was getting it into the tools I use.

My task management app of choice is Todoist. Historically, this is the part where I’d either:

Spend an hour manually copying tasks in, or
Spend two hours writing a one-off script to push them in via API.
(And then not touch it again until next quarter.)

But this is 2025, and we have better tools now - Specifically, MCPs.

There are a few Todoist MCP servers available. I used this one, and installed it via Smithery, which acts as a central repo for MCP servers.

I like Smithery because their CLI makes installing MCPs super easy - all you need to do is run the following command:
npx -y @smithery/cli@latest install @Chrusic/todoist-mcp-server-extended --client claude

Once installed, the only extra thing you’ll need is a Todoist API token:

Log in to your Todoist account
Navigate to Settings → Integrations
Find your API token under Developer
Press Copy API Token

Paste it when prompted, and you’re good to go.

Open the Claude app, and behold - it can now access Todoist on your behalf.

Watching the Magic Happen

With the Todoist MCP server up and running and my API token in place, I handed the rest to Claude.

I already used O1 to generate the execution plan earlier in the process. Now, all I had to do was give it a final prompt - this time, with instructions to take that structured task list and push it into Todoist using the MCP interface.

Here’s the prompt I used:

This is my OKR and my task list for hitting the goals in this OKR. I need your help in using your tools to put these tasks into my task-management app (Todoist).

Here's what I need you to do:
* Create Todoist Project called FY26H1 OKR.
* Under this project, create a section for each KR (name it [KR Title] (KR [KR Number])).
* Finally, populate each section with the task from the task list. Put the DoD and the Description together in the task description.

If you are not sure about something, don't assume my intent - ask me how to proceed.

Claude handled the whole thing in one go - no errors, no re-prompts.

It created the projects, slotted each task under the correct KR, and populated the fields precisely as instructed. Start dates, descriptions, labels, priorities - it all showed up as expected in Todoist.

There’s something very satisfying about opening the app and seeing a full quarter of structured, scoped, and scheduled work already laid out - without having to touch an API or spend an afternoon babysitting a migration script.

Conclusion

There’s something very satisfying about opening Todoist and seeing a full quarter of scoped, scheduled work already laid out - without touching an API, writing glue code, or falling into a planning spiral.

But the bigger shift here isn’t just about automation. We’re used to thinking of LLMs as assistants - tools that can help us write code, summarize text, and generate emails. And they’re great at that.

But this flow showed me that models can do more than assist - they can own operational pieces of your workflow. They can reason. Plan. Execute. It will not just help you work faster but also help you work smarter by pushing the low-leverage stuff off your plate entirely.

And that’s the point. I don’t want to spend time manually scoping key results into tickets. I want to focus on the hard parts - the parts that actually require judgment, creativity, and experience. Let the model handle the project management overhead. I’ll show up and do the work.

And the best part? This wasn’t some custom-built workflow with hardcoded paths and brittle dependencies. It’s just a good model, a standard interface, and a few lines of prompt. Which means I can do this again next quarter. And the one after that.

I now use AI Agents to text you back

Oz Tamir — Sun, 06 Apr 2025 11:15:39 GMT

As an ADHD person, I have a problem - I forget to get back to people.

People will text me, and I’ll read it, maybe even think of a reply, and then just… won’t? For days? Sometimes weeks.

It’s not that I’m avoiding anyone - on the contrary. It’s almost always people I like that I ghost. Friends, close family, people I genuinely want to keep in touch with. But if the conversation doesn’t require a reply right that second, odds are, I’ll forget.

Many of my friends have got this image when I first saw it on X

So I figured: can this be automated? Can I build a system that knows who messaged me, who I haven’t replied to in a while, and gently reminds me to say hi before I have to begin my reply with “sorry for not getting back to you sooner”?

Turns out: yes.

And to make it, I used the hottest game in town - AI agents and MCPs.

The Plan

This whole thing started when I stumbled across a new WhatsApp MCP server on GitHub. Naturally, I had to try it.

Around the same time, I’d been using n8n at work for some growth automation experiments at Blockaid - and I started wondering: what if I’d try to use this platform to solve personal problems too?

So here was the plan:

Set up a self-hosted n8n instance on a Raspberry Pi
The MCP node for n8n only works on self-hosted instances. So I couldn’t just spin this up on the n8n Cloud.
Set up the WhatsApp MCP server and connect it to an LLM agent
The MCP server would sync my WhatsApp chats via the multi-device API, and expose a tool interface for querying messages.
Use this setup to pull a list of conversations I missed
I’d query the server for chats where the last message was from someone else - and I hadn’t replied in a while.
Send myself a summary with everyone I should probably get back to
Ideally, with a little LLM-generated nudge like “Here’s what they said. Want to say hi?”
Once it works, turn it into a daily routine
Add a Cron trigger in n8n to run the whole flow each morning.

That was the idea. A little automation to help me be a better version of myself. Or at least a version who replies to messages before it gets awkward..

Setting up n8n

Step one was getting a self-hosted n8n instance up and running on my Raspberry Pi.

If you’re not familiar, n8n is a workflow automation tool - sort of like Zapier, but open-source, self-hostable, and way more powerful. It’s also AI native, which makes creating flows like what I wanted to achieve super easy.

While the n8n team is offering hosted versions, these don’t support community nodes - extensions to n8n developed by the open source community (The MCP node is one such node). To be able to run community nodes, one would have to run the self-hosted version of n8n.

That was fine - I always have a spare Raspberry Pi lying around for emergencies like these. I quickly 3D printed a case and was ready to go.

For the actual setup, I followed this excellent guide, which walks you through installing n8n. It’s not anything special - basically installing Raspberry Pi OS, installing node, and downloading n8n through npm. To make sure things are persistent, I used the pm2 setup that makes sure n8n runs on boot.

A good tip I got was to use pm2’s configuration file to pass environment variables to n8n. Specifically, I needed to give a parameter that allows insecure (http-based) access to the system. Since I only intend to access this setup locally for now, this is OK. To pass the variable, I used this ecosystem.config.js setup:

module.exports = {
    apps : [{
        name   : "n8n",
        env: {
            N8N_SECURE_COOKIE:false
        }
    }]
}

Now, I had n8n running and ready to go - it was time to install the nodes.

Adding MCP support to n8n

With n8n running, the next step was making it aware of my WhatsApp messages - or more specifically, giving it a way to ask about them.

That’s where whatsapp-mcp comes in. This MCP server connects to your personal WhatsApp account (using whatsmeow), and stores your messages in a local SQLite database. From there, it exposes an MCP Server which can be accessed using agents.

An MCP Server is part of a new open standard called the Model Context Protocol - a protocol designed to help AI agents interact with external tools and data sources. In practice, an MCP Server wraps a data source (like my WhatsApp messages), and exposes it to AI agents through a uniform interface.

When connected to an agent (like Claude or ChatGPT), it can respond to tool calls like:

“List messages I haven’t responded to in the past week.”
“Summarize this chat thread.”
“Draft a short reply.”

Because it’s just an interface layer, all the actual data stays local. And because it’s a standard, tools like n8n can now connect to any MCP server and use those tools inside workflows.

Or at least, that’s the idea - at the time of writing, n8n does not have a native MCP support. To connect n8n to an MCP server, I first needed to install the n8n-nodes-mcp community node. This node adds support for calling tools through an MCP interface.

Installing a new node is very easy - you can do it in the GUI:

Or simply by going to ~/.n8n/nodes and running npm install n8n-nodes-mcp. Once the installation is complete, you can verify that the new node is up and running by navigating to /settings/community-nodes and confirming that it shows up in the list:

Installing the WhatsApp MCP Server

With MCP support added to n8n, the next step was actually spinning up an MCP server that could serve my WhatsApp messages. Like I said, to make this connection I used whatsapp-mcp - a project that connects to your WhatsApp account and makes your chats queryable over MCP.

The server is using a project called whatsmeow, which is written in Go, to connect to WhatsApp - so I first needed to install golang on my Raspberry Pi.

I’m not a go programmer, so take what I say with a grain of salt - I initially used apt install golang to get it installed, but this method caused a mismatch with the projects expected go version.

What I ended up doing is just getting the binaries that matched my version:

wget https://go.dev/dl/go1.24.1.linux-arm64.tar.gz
sudo tar -C /usr/local -xzf go1.24.1.linux-arm64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version # To verify that everything went well

Next, I cloned the repo:

git clone https://github.com/lharries/whatsapp-mcp.git
cd whatsapp-mcp

And started the bridge:

go run ./whatsapp-bridge/main.go

On the first run, it displays a QR code in the terminal - you need to scan it with the WhatsApp app on your phone (it’s essentially the same process as pairing with WA Web):

This QR code will let you log into my WhatsApp, you should scan it!

Within a few seconds the sync started. From that point forward, the server quietly indexed all my messages into a local SQLite database.

Connecting the WhatsApp MCP to n8n

With the WhatsApp MCP server installed, the last step was registering it inside n8n so I could use its tools in workflows.

Instead of using the HTTP interface, I opted to connect it through the STDIO API, which runs the MCP server locally as a subprocess inside n8n. This approach is fully supported by the n8n-nodes-mcp node, and has the added benefit of not requiring a separate always-on process - n8n can spin it up as needed.

To do that, I first went to the Credentials section in n8n, created a new credential of type MCP Client (STDIO) API, and filled in the following (taken from the whatsapp-mcp docs):

This tells n8n to use uv to run the WhatsApp MCP server locally via its Python entrypoint. Since the server is structured as a Python module, this works out of the box.

I saved the credential and tested the connection - and just like that, n8n was able to discover the available tools exposed by the WhatsApp MCP.

Now, when adding an MCP node to a workflow, I could select the new “WhatsApp MCP” credential, choose a tool, and pass in any parameters or context I wanted.

Next up: building a workflow that actually uses these tools to figure out who I’ve been ignoring.

Building an Example Workflow

With the MCP credential set up and the tools exposed in n8n, it was time to build the actual workflow.

To start simple, I made a basic agent flow that could receive a message and call tools from the WhatsApp MCP server. The setup looks something like this:

A chat trigger node that kicks things off when I message the agent
An AI Agent node, configured with Claude 3 and given strict instructions to never send a message (just make suggestions)
A memory node to give the agent short-term recall
Two MCP tool nodes wired into the agent - one to register the available WhatsApp tools, and one to actually execute them

Here’s the system message I gave the agent:

You are a helpful assistant designed to help the user manage their social interactions on WhatsApp.

Whatever you do, you must never send any message. Do not do it. No matter what.

For context, the current date is: {{ new Date().toDateTime() }}.

To test this setup, I started small - I asked the agent to check what was the latest message I got from my partner. I had asked her to close the bedroom window, and hold and behold - the bot caught it instantly.

The integration is working! Then came the real test: Could it figure out who I genuinely needed to respond to?

So I asked it:

Go over all my chats from the past 72 hours. Anything I missed? Please reply in a prioritized list of items I should look into (if I should reply - it should be higher on the list).
Give me 10 items at most (ideally as few items as possible).

And the result was…very good?!

it pulled a few one-on-one threads where I had clearly dropped the ball, summarized the last thing said, and even proposed short replies. It’s working!

Next steps

With this proof-of-concept working end-to-end - from syncing chats, to querying missed messages, to getting back helpful suggestions - the next steps are to take this toy project and turn it into a “production” application.

To meet this criteria, here are the next items on my to-do list:

Run this workflow periodically - The obvious first step. n8n makes this very easy - and I plan to have this workflow run every morning to ensure I don’t miss anyone over too long of a time.
Actually deliver the results - Once I have a list of chats I should get back to, it should probably… go somewhere. Since we already have the WhatsApp MCP here, sending a WhatsApp reminder to myself seems like the easiest way to go.
Interact with a reminders MCP - I already saw people creating MCPs for to-do apps like Todoist. By adding in this integration (which, again, should be very easy), I could have the agent not only tell me to reply, but schedule a reminder that will bug me again later.
(Maybe) generate suggested replies - Right now the agent tells me who to respond to, and what they said. Eventually, it could also suggest what I might want to say.

Summary

The combination of agents and MCPs opens up a lot of new possibilities - and as a technical person, it’s hard not to get excited about that.

This wasn’t a huge project. Just a weekend’s worth of curiosity, some open source code, and a Raspberry Pi that was already sitting around. But it solved a real problem in my life, and it gave me a glimpse into what building with these tools can feel like when everything actually clicks.

I think everyone should be experimenting with this stuff - whether it’s a small, personal automation like this, or something bigger at work. AI is going to change the way we build software, and the engineers who stay curious and hands-on are the ones who are going to stay ahead.

And if you can explore this space while also becoming slightly less bad at replying to your friends - why not?

Building the MDR terminal from Severance

Oz Tamir — Sat, 15 Feb 2025 09:34:26 GMT

Like a lot of folks, I recently got hooked on Severance. This wasn’t my first time hearing about the show—back when Season 1 was running, people wouldn’t shut up about it. I even gave it a shot back then, watched a single episode, and decided it was way too dark for my taste.

That was a mistake.

With all the buzz leading up to Season 2, I figured I’d give it another chance. And wow—what a fantastic piece of television. I binged all the available episodes, and now I’m just sitting here, restless, waiting for the next one to drop.

Which means I needed something to do in the meantime.

See, when I get into a new piece of pop culture, I don’t just watch it—I dive in. Reading theories on Reddit, forcing my friends to watch along, the whole thing. But even that’s not enough. My brain won’t rest until I’ve made something out of it. It’s how I feel like I’m part of it. Some people buy merch—I build.

So, naturally, I decided to make my own MDR terminal.

Physical Parts

To get started, I needed to build the physical enclosure of the MDR terminal. Instead of modeling it from scratch, I used this MagSafe charger modal from @SeoulBrother - with slight modifications.

While the original modal is made to fit an iPhone and therefore is not hollow, I knew that I would need a lot of storage space for the electronics - so I used a negative cube to carve out a big chunk of the case. I will not upload this modified part to avoid breaking the license on the original upload - but here is how it looks like in my slicer. YMMY though.

Next, I needed to recreate the front-facing part of the enclosure. To do so, I looked up promotional images from the series - luckily for me, Apple had run a marketing campaign for the show which included an Apple-like product page for Lemon’s stuff. This gave me this great reference image:

Based on this reference, I fired up Fusion 360 and started modeling. Usually, when modeling off a reference image, I’ll start from tracing the features of the image - this time, I started with the screen dimensions and traced based on the enclosure size I already had - which is why the proportions are a bit off.

Of the flip side (literally…), I modeled a holder for the combined unit of the Raspberry Pi + screen:

One of the biggest reasons I am a strong believer in 3D printing is just how easy this manufacturing process is, and how this enables lighting fast iterations - within the two evenings I spent on this project, I went through quite a few iterations.

One of the biggest issues I had was making sure that the Pi stays in place and is not pushed back. After trying multiple approaches, I ended up with placing overhangs above the unit and adding holes for fixing it in place with nuts and bolts.

For anyone interested in building this themselves - the final modal (and the Fusion project file!) is available for download here.

Another issue I faced was the tight space for cables. If you’ve ever worked on a hobby project that was tight in space, you probably noticed the same thing as I did in this one - cables are f**king huge. The connector for USB-C? Giant! Where am I supposed to find a place for this?

No. Instead, I went ahead and got an angled cable, which is apparently a thing. I was very happy to discover that this is a solved problem, because I was inches away from splicing the cable and trying to make this on my own.

As a final touch, I added a small Pi-connected camera that I got a while back, accidentally broke, and never used again.

Electronics and Software

Right from the outset, It was clear to me that this is the type of project where I am better off with a Raspberry Pi rather than trying to use an Arduino or ESP platform - I know that I’ll need to run some heavy graphics, and I didn’t want to be strapped for resources.

Due to the small space constraints, I opted for a Raspberry Pi Zero - the small form factor made sense to me, and I thought that while the graphics are probably a lot for an ESP, the Zero should be able to handle the load. Using a full-form Pi seemed wasteful.

For the screen, I pulled an old touch display I had laying around for years. This display uses SPI for communications, and it seemed like a good fit. I connected the two, and started working on the software side of things.

However, after some tinkering around, It turned out that both of these decisions were ill guided. The display, which is based on a driver called IL9488, turned out to be very badly supported - the required drivers were removed from the Pi main kernel back in 2015. While there are a couple of projects that claim to solve this by providing their own drivers, after compiling a few It was clear that this avenue will be more hassle than reward - which is why I decided to drop it and just get a Waveshare LCD screen instead.

However, this screen was now using HDMI instead of SPI. While, again, it looked like it is possible to run this on a Zero using SPI, I did not want to invest any more time on this - so I just switched over to a Pi 4, which played nicely and was supported by the provided HDMI to Mini HDMI dongle.

At the end of the day, I think this switch was the right call - it went from being a shit show to “just work”. Since time is money, I am quite happy with this trade.

Software

Since I was using a Raspberry Pi, I figured that most of the software is already out there - and I was right. A quick search brought me to the Github repository for FullPageOS - a Raspbian fork customized to support kiosk mode, where you boot the device and it automatically loads up a web browser pointed to a website of your choosing.

For the actual MDR software, I used this project by the fake Lumons Industries Github page. This project is actually, and uncharacteristically, just raw Javascript - which meant that I didn’t need to play around with any fancy building solutions to run this on the Pi.

To get it running, I simply created a small nginx server and pointed the FullPageOS config to the server. First, I needed to turn off the existing HTTP server that ships with the distro:

sudo systemctl stop lighttpd
sudo systemctl disable lighttpd

Then, I installed ngnix and cloned the repo:

sudo apt update
sudo apt install nginx -y

git clone https://github.com/Lumon-Industries/Macrodata-Refinement mdr

Once I had everything I needed, I edited the ngnix config (/etc/nginx/sites-available/default) to serve the project files:

server {
    listen 80;
    server_name _;

    root /home/pi/mdr;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Finally, I made sure that the server is running with the new configuration:

sudo systemctl restart nginx
sudo systemctl enable nginx

And indeed, serving to the Pi’s IP address gave me the MDR interface:

The only missing piece was to set the FullPageOS configuration to point to the site. To edit the URL loaded on boot, all needed is to edit a simple file:

rm /boot/firmware/fullpageos.txt
echo 'http://localhost/' > /boot/firmware/fullpageos.txt

Final Result

Once all the printed parts, the electronics, and the software were all ready, it was time to put it all together. This took some back and forth, especially around getting the electronics to fit in the case.

In fact, I ended up having to break a tiny bit of the printed part to fit it in. While I fixed it in the final modal I published, I didn’t want to reprint - which is why the resulting terminal is using a broken part (as you can see in the “bolt” image above).

However, it was all worth it. Because the final result is stunning.

Conclusion

I have to say, looking at my completed MDR terminal sitting on my desk, I feel… oddly proud?

It’s weird to put this much effort into recreating a computer designed for soul-crushing corporate monotony, but here we are.

When I told some friends that I was working on this project, I got a recurring question - “but what would you do with this?”.

The honest answer? I’ll probably keep it for a while on my desk and then either dismantle it or store it in the closet somewhere.

I know that this is a bit underwhelming, but the truth of the matter is that I do these projects for the sake of the project - not for some “goal”. This is what makes this a hobby - and not a job.

But than again - maybe, like the folks at Lumon, I do have a hidden goal here. Only Kier knows.

Beating the Cold Room Syndrome with Zigbee

Oz Tamir — Tue, 11 Feb 2025 21:40:53 GMT

One of the feelings I hate the most around winter time is the striking temperature difference between my shower and the outside world.

Whenever I’m done washing up, I dread the moment when I’ll have to get outside of the bathroom and into my bedroom - which is often very cold, especially in comparison.

Sure, there’s an obvious fix: turn on the bedroom AC before I shower.

But here’s the thing—I never remember to do that. Not before stepping in, anyway. I only ever remember the second I step out, which, as you can imagine, is a little too late.

Finally, after one too many of these experiences, I decided enough was enough. It was time to automate my way out of misery.

Honey, are you in the shower?

The solution to this pain point is pretty easy - I just need to figure out when I shower, and trigger the bedroom AC. I already own a Sensibo, so the only hard part is the shower detection.

This is kind of a fickle problem, because I would not want to have any sort of optical solution - no cameras in the bathroom, thank you very much.

Another option I briefly considered using a motion sensor, but that would trigger every time someone walked into the bathroom—not just when someone was showering. A timed schedule was also a bad option - it’s too rigid.

I wanted something smarter; something that knows I’m showering without creeping on me. Luckily for me, I had the perfect device for this use case laying around.

Tracking showers using Zigbee Humidity sensor

I originally bought the SONOFF’s Humidity and Temperature Sensor (SNZB-02D) to try and help with fan control (our bathroom has an humidity problem…), but ditched it when I figured out that the fan should just be always on.

But now, I finally found a usage for it - I can use it to try and detect sharp changes in the humidity of the bathroom to detect when one of us is in the shower.

After setting up the sensor and pairing it with Home Assistant (via ZHA), we can take a look at the humidity history:

It’s not hard to see that there are obvious upticks in the graph, and these indeed map directly to our recent showers. Looking over the last month of data, the pattern was very clear—whenever someone showered, the humidity spiked past 85%.

It was a clean, repeatable cutoff, which meant that the solution was very easy - all I need is to set my automation to trigger when it crossed that threshold.

I should note that I’ve played around with derived sensors to try and see if we can optimize this flow (I assumed that by measuring the rate of change we might be able to detect a shower faster, thus giving us more time to heat up the room). However, these did very little to help, which is why I decided to stick with the simple solution.

What I did do was to set this automation with a bunch of extra conditions to help ensure that this is not triggered randomly if the humidity is too high - I ensured that the timeframe makes sense, that there’s someone home, etc.

So, how does the final automation looks like?

alias: Turn on Bathroom AC when someone showers
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.bathroom_temperature_sensor_humidity
    above: 85
conditions:
  - condition: time
    after: "17:00:00"
    before: "10:00:00"
  - condition: state
    entity_id: binary_sensor.someone_is_home
    state: "on"
  - condition: numeric_state
    entity_id: climate.bedroom
    attribute: current_temperature
    below: 20
actions:
  - action: sensibo.full_state
    metadata: {}
    data:
      mode: heat
      target_temperature: 24
      fan_mode: strong
    target:
      device_id: [ID]
  - action: sensibo.enable_timer
    metadata: {}
    data:
      minutes: 10
    target:
      device_id: [ID]
mode: single

Conclusion

As always, a little automation goes a long way.

I no longer have to remember to turn on the heater before I shower—Home Assistant does it for me.

No more shivering, no more rushed dives under the blanket, just a warm, comfortable room waiting for me when I step out.

To be honest, these kind of projects are my favorites. It’s not about the flashy, over-the-top automations—it’s about solving tiny annoyances that make life just a little better.

And, as a bonus, it finally gave me a use for that humidity sensor I impulse-bought months ago.

Syncing Home Assistant States to Exist.io

Oz Tamir — Mon, 04 Nov 2024 16:03:32 GMT

Recently, I dove head-first into a new hobby - the world of quantified self. If you haven’t heard this phrase before, it’s a really simple idea - track everything.

Steps, sleep, health, productivity, music listened to, food eaten. You name it.

The attraction was clear - like any good engineer, I wanted to see if I could optimize my life with a little data and some well-placed automation. How to Measure Anything, taken to the max.

Of course, tracking is only half the battle.

I wanted to figure out why certain patterns emerged: did late-night work affect my sleep? Did productivity take a hit when I had fast food the day before?

I started searching for a tool that could help me bring all these pieces together—something that would do more than just count steps or track hours. And that’s when I found Exist.io, a service that promised to make sense of all this data.

Exist.io connects to all kinds of apps for fitness, sleep, weather, even productivity, giving you an overview of how these daily factors stack up and interact.

Perfect, right? Well, almost.

Because once I started tracking, I realized there were still things I wanted to log that Exist didn’t support out of the box. The most pressing issue was that I was already gathering a bunch of data in Home Assistant - I wanted to use this data to enrich every insight I could get. But alas, there is no native Home Assistant integration in Exist.io.

The good news - they have an API, built for cases just like this one. With a little tweaking, I could create custom integrations to add my own data to Exist—bridging the gap and making sure every data I can find in Home Assistant can also be tracked on Exist.

Since I couldn’t find any walkthrough of how to do this sync online, I figured I’d share my system for anyone interested in doing something similar.

For this example, we’re going to be tracking how much 3D printing I’ve been doing each day, using the Bambu HA integration.

Exist API Overview

Before we dive into syncing data, let’s get familiar with the Exist.io API basics, as these will be key for integrating Home Assistant with Exist.

Exist.io revolves around attributes—metrics like steps, sleep hours, or, in our case, custom stats.

Attributes in Exist are tracked daily, which means it’s designed for summarizing data by day rather than capturing every minute change.

Key Concepts

Attributes: These are the fundamental data points tracked in Exist.io. Each attribute has:
- Name: A simple identifier like steps or daily_print_time (used in API requests).
- Label: A user-friendly title displayed in Exist, like “Daily Print Time.”
- Group: Exist organizes attributes into broad categories like Productivity, Sleep, or Weather.
- Value Type: Exist supports various data types for attributes, including integers, floats, strings, and durations (typically measured in minutes).
Custom Attributes: While Exist comes with a range of built-in attributes (e.g., sleep, workouts), you can create your own using the API.

In this example, we’ll define daily_print_time as a custom attribute to log 3D printing activity each day.

To access Exist’s API, we need to set up an OAuth2 client app. This involves creating an app on Exist.io, and using a token to authenticate Home Assistant with Exist.io:

Once the app is created, you will get an access token that will be used to authenticate the API calls done by Home Assistant.

Making Home Assistant Talk to Exist.io

With Exist’s API basics covered, it’s time to set up the commands that will let Home Assistant communicate with Exist.io. To do so, we will be using REST commands, an integration which allows HA to make HTTP calls.

To send data to Exist, we will create a different command for each operation we want to be doing - creating a new attribute, updating its value, and incrementing it by a specified amount.

Create Attribute

The first step is to create our custom attribute in Exist.io, like daily_print_time. This command only needs to be run once per attribute to set it up in your Exist account.

rest_command:
  create_exist_attribute:
  	url: "https://exist.io/api/2/attributes/create/"
    method: POST
    headers:
      Authorization: "Bearer YOUR_ACCESS_TOKEN"
      Content-Type: "application/json"
    payload: |
      [
        {
          "label": "{{ label }}",
          "group": "{{ group }}",
          "value_type": {{ value_type }},
          "manual": false
        }
      ]

In this command:

label is the name displayed in Exist.
group organizes the attribute under a category, like productivity.
value_type defines the data type (3 here, meaning a duration in minutes).

Update Attribute

The next REST command allows you to set a specific value for the attribute on a given day. This can be useful if you need to overwrite an existing daily value or set it manually.

rest_command:
	update_exist_attribute:
	  url: "https://exist.io/api/2/attributes/update/"
	  method: POST
	  headers:
	    Authorization: "Bearer YOUR_ACCESS_TOKEN"
	    Content-Type: "application/json"
	  payload: |
	    [
	      {
	        "name": "{{ attribute }}",
	        "value": "{{ new_state }}",
	        "date": "{{ now().strftime('%Y-%m-%d') }}"
	      }
	    ]

In this command:

name specifies the attribute to update (in this case, daily_print_time).
date sets the day the value applies to, using today’s date.
value is the new value we want to set this attribute to.

Increment Attribute

The last REST command increments the attribute value by a specified amount. This command is particularly useful for tracking cumulative stats like daily printing time.

rest_command:
	increment_exist_attribute:
	  url: "https://exist.io/api/2/attributes/increment/"
	  method: POST
	  headers:
	    Authorization: "Bearer YOUR_ACCESS_TOKEN"
	    Content-Type: "application/json"
	  payload: >
	    [
	      {
	        "name": "{{ attribute }}",
	        "value": {{ value }},
	        "date": "{{ date | default(now().strftime('%Y-%m-%d')) }}"
	      }
	    ]

Here:

name identifies the attribute to be incremented.
value specifies the amount to increase the current day’s value by.
date sets the day the value applies to, using today’s date.

With these commands in place, Home Assistant can now create, update, and increment Exist.io attributes directly, allowing you to push custom data from your setup into Exist.

Creating an Attribute

With the REST commands set up, the next step is to create the custom attribute in Exist.io.

This is the one-time setup that registers our attribute—daily print time—in your Exist account. This can be done either using an automation, or using the Home Assistant developer tools. Since this is a tutorial, let’s go with the latter:

Open Developer Tools in Home Assistant and go to the Actions tab.
Under Action, select rest_command.create_exist_attribute.
Hit Perform Action to execute the command, creating the attribute in Exist.io.

Based on the response, you can tell if the attribute was successfully created, Once it is, we can go ahead and create an automation to log 3D printing time in Exist.

Logging 3D Printing Time to Exist.io

With the daily_print_time attribute set up, we’re ready to start logging our 3D printing time.

For this, we’ll create an automation that gets called whenever a print starts, and increments the attribute in Exist.io based on how much print time is planned. This is done using the bambu_x1c_remaining_time attribute from the Bambu integration.

alias: Log 3D Printing Time to Exist.io
description: "Automatically logs 3D printing time to Exist.io as the printer runs"
trigger:
  - platform: state
    entity_id: sensor.ozs_bambu_x1c_remaining_time
    from: "0"
    to: "running"  # Adjust based on the sensor state representing a running printer
condition:
  - condition: numeric_state
    entity_id: sensor.ozs_bambu_x1c_remaining_time
    above: 0
action:
  - service: rest_command.increment_exist_attribute
    data_template:
      name: "daily_print_time"
      value: "{{ trigger.to_state.state | int }}"  # Replace with duration sensor if available
  - service: logbook.log
    data:
      name: "Exist.io Log"
      message: "Incremented print time on Exist.io by {{ trigger.to_state.state }} minutes"
mode: single

To make things debugable, we will also be logging the response into the logbook service.

Once this automation is active, you’ll start seeing your daily 3D printing time accumulate in Exist.io.

With each print session, Home Assistant updates the daily_print_time attribute, providing you with a running total that you can view alongside other life metrics.

Conclusion

And that’s it—my 3D printing time is now tracked, quantified, and rolled into Exist.io along with my steps, sleep, and the rest of my life metrics.

It’s honestly pretty satisfying to see data from this setup nestled right next to all the other insights Exist provides.

Not to mention, it’s also a bit addictive; once you see how easy it is to pull in one data source, it’s tempting to start thinking of all the other things you could track.

Of course, Exist.io is designed for daily summaries, so you won’t be analyzing every moment your lights turn on or every change in room temperature.

But that’s fine—this integration is perfect for capturing high-level stats that build into trends over time. And if you’re like me, you’ll start finding connections you didn’t expect.

Printing projects affecting your productivity? Sleep quality tied to home energy usage? Sure, why not.

So, if you’re the kind of person who loves to track, tinker, and optimize, integrating Home Assistant with Exist.io is a solid move.

It’s a great way to pull in unique data points that really matter to you, bringing them into the bigger picture of your daily life. An remember - if it can be tracked, it can be improved. So, why not?

Using EIP-6963 for Marketing

Oz Tamir — Sat, 19 Oct 2024 21:08:00 GMT

Working in a Web3 centered company, a lot of my online attention is spent on Twitter (X) - after all, this is where a lot of the people in the community are.

A few days ago, I was browsing the feed when I came across the impressive work that Zerion is doing with their UnblockCrypto campaign.

This campaign aims to promote the adoption of a new Ethereum standard, EIP-6963.

EIP-6963

For those unfamiliar, EIP-6963 (Multi Injected Provider Discovery) is a community-driven standard that introduces an alternative discovery mechanism to window.ethereum.

As written in the EIP document:

Currently, Wallet Provider that offer browser extensions must inject their Ethereum providers (EIP-1193) into the same window object window.ethereum; however, this creates conflicts for users that may install more than one browser extension.

This results not only in a degraded user experience but also increases the barrier to entry for new browser extensions as users are forced to only install one browser extension at a time.

In this proposal, we present a solution that focuses on optimizing the interoperability of multiple Wallet Providers. This solution aims to foster fairer competition by reducing the barriers to entry for new Wallet Providers, along with enhancing the user experience on Ethereum networks.

This is achieved by introducing a set of window events to provide a two-way communication protocol between Ethereum libraries and injected scripts provided by browser extensions thus enabling users to select their wallet of choice.

Realizing the Potential

Upon learning about this standard, I immediately saw an opportunity. At Blockaid, we pride ourselves on partnerships with major players like Metamask, Coinbase Wallet, Rainbow, and Zerion.

My idea? Use EIP-6963 to provide social proof to our website visitors.

By highlighting that the wallets they use are likely already compatible with Blockaid, we can build trust and assure them of their choice of us as their security provider—the same idea that is powering our messaging around the Blockaid Network.

The Integration Process

Integrating support for this standard was surprisingly easy. The injected providers that support EIP-6963 publish a window event with a simple interface providing necessary information, including the provider’s name and icon.

With this interface, the integration is very straightforward - all you need to do is to listen for window events that contain a provider announcement, make sure that the announced provider is one of our supported providers (list of our customers that integrated EIP-6963 into their extension), and set the state of the banner:

// Listener for wallet provider announcements
window.addEventListener("eip6963:announceProvider", (event) => {
    const {name, icon} = event.detail.info;
    if (Object.keys(supportedProviders).includes(name)) {
      setProvider(supportedProviders[name]);
    }
});

As you can see, the code listens for provider announcements and updates our website to reflect the connected provider, offering a seamless user experience. And the result? Stunning.

Conclusion

EIP-6963 is more than just a technical improvement—it’s a trust signal, a marketing asset, and a way to reduce friction for users navigating the Web3 ecosystem.

By showcasing compatibility with this standard, we’re not just improving UX; we’re reinforcing security, credibility, and seamless integration with the wallets users already trust.

For any crypto project looking to boost adoption, leveraging new standards like EIP-6963 isn’t just a technical decision—it’s a strategic one.

And in an industry where trust is everything, small details like these can make a big difference.

A special mention to this Metamask repository for being an invaluable resource during this process.

Putting an end to 3D printed Halloween models

Oz Tamir — Sat, 05 Oct 2024 14:09:25 GMT

Ah, October. It’s the time of year when every 3D printing model site goes Halloween-crazy. If you’ve been browsing Printables, Thingiverse, or Makerworld lately, you know what I’m talking about. Skeletons, witches, pumpkins—it’s as if every other model has been dipped in spooky sauce.

Now, don’t get me wrong—Halloween’s fun and all. But not when you’re just looking for cool new prints, and all you get is a flood of bats, cobwebs, and the same jack-o’-lantern model in 30 different styles. Since I’m not exactly in the Halloween spirit (being from a non-celebrating country and all), this overload felt more like spam.

So, instead of just scrolling past in frustration, I figured, why not do something about it? Thus, I built a browser extension that filters out all the Halloween-themed content and restores balance to my 3D model browsing experience. No more spooky clutter on my screen.

The Problem

Every October, these 3D printing sites look like they’ve been taken over by Halloween.

If you’re actually hunting for new prints, it becomes this endless scavenger hunt to sift through all the spooky clutter. Skeleton hands, pumpkin lanterns, ghost cookies—every search query ends up returning more of the same. It wasn’t long before I found myself spending more time filtering out seasonal stuff in my head than actually finding useful models.

Annoyed by this, I decided to take matters into my own hands and filter it all out—programmatically.

The Solution: Building a Halloween-Filter Browser Extension

So, how do you block out Halloween models without blocking the entire site? The solution was to create a browser extension that hides or removes items based on specific keywords, like “pumpkin,” “witch,” “ghost,” “skeleton,” etc.

The icon ChatGPT helped me create

This extension works by running a background script that detects when a user is visiting one of the aforementioned 3D printing sites. For those unfamiliar, a background script in browser extensions runs in the background, waiting for specific events or actions to occur.

In my case, the script listens for a page load event (i.e., when you load up Printables or Thingiverse), then executes the filtering logic to hide any Halloween-related models.

chrome.tabs.onUpdated.addListener((tabId, changeInfo, tab) => {
  if (changeInfo.status === "complete") {
    if (tab.url.includes("printables.com")) {
      chrome.scripting.executeScript({
        target: { tabId: tabId },
        files: ["halloweenRemovers/printables.js"],
      });
    } else if (tab.url.includes("thingiverse.com")) {
      chrome.scripting.executeScript({
        target: { tabId: tabId },
        files: ["halloweenRemovers/thingyverse.js"],
      });
    } else if (tab.url.includes("makerworld.com")) {
      chrome.scripting.executeScript({
        target: { tabId: tabId },
        files: ["halloweenRemovers/makerworld.js"],
      });
    }
  }
});

Once the page is fully loaded, the extension injects a specific script depending on the site you’re visiting. You might wonder why we need to inject a script at all—can’t the background script handle everything? Well, not quite.

In this case, the injected script needs to manipulate the HTML of the webpage directly. This means it needs to run in the same JavaScript context as the website to access and modify the DOM.

Imagine the webpage is a sandbox where JavaScript is running. To change things inside that sandbox (like hiding a Halloween model), the script itself must run within the sandbox. That’s where the injected script comes in—it gets dropped into the website’s sandbox and gets full access to modify the page as needed.

The Filtering Logic: Removing Halloween Models in Action

Once the extension detects that you’ve loaded one of the supported 3D printing sites, it injects a script tailored to the site’s specific layout.

The filtering logic works by scanning the page’s HTML and comparing each model’s details against a list of Halloween-related keywords (like “pumpkin,” “witch,” and “ghost”).

If a match is found, the offending model gets swiftly removed from the page. Before it does, though, it loads the list of words deemed to be related to Halloween:

let halloweenWords = [];

// Function to load Halloween words from chrome.storage
function loadHalloweenWords() {
  chrome.storage.local.get(["halloweenWords"], function (result) {
    if (chrome.runtime.lastError) {
      console.error("Error loading Halloween words:", chrome.runtime.lastError);
      return;
    }

    halloweenWords = result.halloweenWords || [];
    console.log("Loaded Halloween words:", halloweenWords);

    if (halloweenWords.length === 0) {
      console.warn(
        "No Halloween words loaded. Check if words are being saved correctly."
      );
    }

    removeArticles();
  });
}

Once we have the words, we can iterate over the items (in Printable’s’ HTML code, they appear inside <article> tags - which is why the code refers to articles):

function removeArticles() {
  // Updated selector to match the correct class name
  const articles = document.querySelectorAll("article.card.svelte-j1lj8e");
  console.log(`Found ${articles.length} articles`);

  articles.forEach((article, index) => {
    const link = article.querySelector("a[href^='/model/']");
    if (link) {
      const href = link.getAttribute("href").toLowerCase();

      if (halloweenWords.some((word) => href.includes(word))) {
        console.warn("Removed article:", {
          title: article.querySelector("h2")?.textContent || "No title",
          link: href,
        });
        article.remove();
      }
    }
  });
}

Finally, since these sites are loading more models on the go, I’ve also added a MutationObserver that will re-run the filtering logic whenever the body changes:

const observer = new MutationObserver(() => {
  console.log("MutationObserver triggered, running removeArticles");
  removeArticles();
});
observer.observe(document.body, { childList: true, subtree: true });

Keeping Things Dynamic: Updating the Keyword List

One of the nice parts of this extension is that the list of banned keywords is editable by the user. This way, it’s not just limited to Halloween. You can add keywords to filter out Christmas models in December or Valentine’s Day models in February.

The extension stores the user’s blacklist in chrome.storage.local, meaning it persists even after the browser is closed. This makes the extension highly adaptable for any kind of seasonal content—just add the words you want to avoid, and it’ll clean up your feed accordingly.

Conclusion

While 3D printing model sites haven’t (yet) introduced features to filter out unwanted seasonal content, this extension fills that gap. With a dynamic, customizable keyword list, I can now look for new models to print - without being bombarded by pumpkins and witches in October.

Same page - with FHM extension enabled

The final extension is available on GitHub here. Installation instructions are provided in the README file.

Whether you’re as tired as I am of seasonal model spam or simply want more control over what you see, this extension gives you the power to customize your 3D printing feed to your heart’s content.

It’s not perfect, but it sure makes for a less spooky browsing experience. 🎃

Broke: An Open Source Alternative to Brick

Oz Tamir — Sat, 24 Aug 2024 16:58:16 GMT

I recently came across a nifty little project called Brick. Brick is a simple yet powerful product - it’s a physical tag that allows you (using a dedicated iOS app) to block certain apps an activities on your phone, with unlocking only possible by using the physical tag that was used to lock them.

The idea behind this workflow is to enable you to create a physical barrier that keeps you from engaging with distractions on your phone - for example, you can use the Brick to block all non-vital apps on your phone before going to the coffee shop to get some work done. Once you’ve left the tag at home, you cannot be tempted into disabling the block - as you simply cannot disable it until you get back home and has the tag available again.

When I first discovered Brick, I was intrigued by its concept - However, as much as I liked the idea, I felt that Brick had more features than I personally needed—and I wasn’t keen on paying 50$ for something I felt I can hack together in a weekend. So instead of paying, I decided to do just that - build my own alternative, aptly named Broke.

This is a good opportunity to give a shoutout to the Brick team - if this concept seems valuable to you, I highly recommend checking them out - their app has a lot of features I didn’t bother implementing, and the experience they provide is much more production ready.

From Concept to Reality: Creating Broke

To get started, I ordered some affordable NFC tags from AliExpress. I initially ordered ones that matched the ones used by Brick, but later I’ve decided to make my app stand on it’s own completely, and wrote the code to support any NFC tag supported by iOS.

I also spent some time creating a 3D Printed case, to allow for a sleek experience. After a few iterations, I built a case that had magnet holes (to allow leaving it on the fridge) and a keychain hole, to allow carrying it around.

It took multiple tries, but I’m really happy with the end product

Writing the iOS app, with a little help

Once I had a physical tag and a case, it was time to write the app that would implement the real functionality. There was only a tiny problem - I had zero experience with iOS development.

However, I did had a good idea of how I wanted the app to work. I knew that it would need to support reading and writing NFC tags (to allow the interaction of scanning a tag to trigger an action), and that it would have to interface with the Screen Time APIs that iOS exposed to allow developers to limit interaction with other apps.

Armed with this outline, I embarked on a quest that I suspect would be my first foray into the future of programming, and how it’s gonna look like for all code projects in the not so distant future - pair programming with AI. I used Claude, my LLM of choice, to start building the user interface.

Working with Claude was great - I was quickly able to put a basic PoC that allowed me to demonstrate that the app worked.

The Proof of concept design

But the real game changer was when I followed a recommendation from a fellow developer on Twitter - which prompted me to start using Cursor - a VS Code-based AI IDE allowed me to “talk” with my codebase (using embeddings), which made understanding and navigating the code so much easier. With Cursor, I was able to quickly transform my basic proof of concept into a functional, polished app—something that actually feels like it could belong on the App Store.

Final Touches

Once I was done with the core functionality, I took some time to design something that would look presentable. I never designed for iOS before, but after playing in Figma for a while I got to result I was OK with. If this was a full time product, I’d probably give it some more refinement - but for a pet-project, this was good enough.

This is how the final experience looks like:

I want to share my project with the world, but releasing a free alternative to Brick will be what people in bird culture refer to as a dick move.

Therefor, I won’t be releasing Broke as an app anyone can download, nor will I be letting people buy Broke tags from me - Instead, I’ve open-sourced the project, to make it available as an option for technical folks like me, or for anyone interested in building upon my work.

The code for the app is available on Github, while the design for the tags is available on Printables.

Conclusion

Now that the project is complete, I’m thrilled with the outcome. I have created the product that I wanted to use, and I did so by using my own code, CAD, and 3D printing skills. Here’s how it turned out:

Reflecting upon this project, I must say that It never ceases to amaze me how much power a modern-day hobbyists have on their hands - I was able to create this thing from scratch over a weekend! Amazing. Also, I feel like this experience is my answer to folks saying that programming will be gone in a couple of years - I don’t think that programmers will be replaced by AI. I think that the programmers who will fail to embrace the possibilities unlocked by AI will be left behind, but those of us who will - are about to unlock abilities beyond their wildest imagination.

Exciting times!