The Problem
Task-shaped language shows up constantly in things you're already typing: "I need to fix the login bug," "don't forget to email Sarah," a TODO left in a note. Capturing it as an actual action item means breaking flow: open a task manager, copy the line, retype it, pick a project. Claude's Chrome extension already sits inside the browser as you write. It's positioned to notice this happening and offer to pick it up, instead of waiting for you to go do that manually.
- The moment you'd naturally capture a task is also the moment you're least likely to stop and do it: you're mid-sentence, mid-email, mid-thought
- A feature that reads what you type has to prove it's worth that trust before it's worth anything else
- Nobody had validated whether the interaction itself (noticing, highlighting, suggesting) would feel helpful or feel like being watched
Key Insight
The Solution
A concept Chrome extension, built as a working prototype rather than a mockup:
- Inline detection while typing: task-shaped phrases get underlined in orange as you write, in any text field or contenteditable box on any page
- A suggestion card, not a silent log: click the highlight, see the task Claude would create, assign or create a project, or dismiss it. Nothing happens without that click
- Reading text you didn't type, on your terms: select any text on a page and right-click: the one and only way anything outside a field you're actively typing in ever gets read
- A real connection, once you choose it: with your own Anthropic API key, detection can run through Claude instead of a local pattern matcher, and "Run task in the background" actually sends the task to Claude and stores what comes back
Key Decisions
Prove the Interaction Before Wiring Anything Real
The first build had no API calls at all: an offline pattern matcher, the orange highlight, and the suggestion card, all running against a standalone demo page with a mocked "background project" store. That let the actual interaction get tested and broken before a single token was spent connecting anything real, including a hit-testing bug where a live textarea sitting on top of its own highlight layer swallowed every click meant for the highlight underneath it. Fixing that shaped how the highlighter works to this day: clicks are resolved against the field's own caret position, not the (visually covered) element behind it.
Choosing How Much of the Web to Actually Read
When the feature grew to "read text on the page, not just what's being typed," I stopped before touching code. Three trigger models were on the table: automatic background scanning of every page (matching how the typing detector already works), an on-demand "scan this page" button, or select-then-right-click. Automatic scanning would mean reading inbox previews and other people's messages, silently, on every page load. That's the most convenient option and the least defensible one. I chose the narrowest: select the exact text, right-click, choose the exact menu item. Consent is built into the act itself. Nothing is ever read that wasn't deliberately chosen, and that constraint was decided before any of the code existed to make it easy to walk back.
The Audit That Found a Site-Breaking Bug
Once the Claude connection was real, I asked for a full security and privacy audit rather than calling the prototype done. It came back with ten confirmed issues. The most serious one had nothing to do with the API. The textarea highlighting technique physically moved the live form field into a new wrapper element to layer a highlight behind it. That's exactly the kind of DOM mutation that breaks React- and Vue-controlled inputs, on an extension that runs on every site by design. It got rewritten to never move the field at all. Only two of its own inline style properties change now. The same pass caught a storage race that could silently drop a finished task's result, and forced the data-minimization calls that now define the product: only the last ~600 characters of a field are ever sent for classification, not the whole document. Page URLs are stripped to origin-and-path before they touch storage or the API, since real URLs carry reset tokens and session identifiers in the query string. And a shadow root that let a host page's own scripts read detected task text back out got closed.
Make the Copy Tell the Truth
The smallest request was the easiest to get wrong: add a tooltip promising "we will let you know when the task is complete." That's a sentence that makes a promise, and the product didn't keep it yet. There was no completion notification. Before writing that copy, I built the actual notification. The tooltip now describes real behavior, not intended behavior. It's a small decision, but it's the same one from Step 2 at a much smaller scale: don't let the interface claim something the product doesn't actually do.
The Interaction
A task-shaped phrase gets underlined the moment you pause. Clicking it surfaces exactly what Claude would create: project assignment included, editable before you commit to anything.
Once started, the highlight itself becomes the status: no separate dashboard required to know a task was picked up.
Design System
Built to feel like it belongs inside Claude's own product, not bolted onto whatever site it's running on. The card renders in a closed shadow root specifically so it can never inherit (or leak into) the host page's styles.
Color Palette
#d97757
#fffefb
#262019
#6f9c62
Spacing & Tokens
- Card Radius: 14px
- Button Radius: 8px
- Highlight Opacity: 32% fill, solid border
- Card Shadow: 8px/24px, 14% + 8%
- Tooltip Delay: instant on hover/focus
Design Principles
- The highlight is the only ambient signal: no badge, no counter, nothing competing for attention until you click
- Every state (default, hover, queued) is visible in the text itself, not a separate panel
- Closed shadow root: the card can't inherit host-page styles, and a host page can't read the card back
- Copy never promises what the product doesn't do: the completion-notification tooltip only exists because the notification does
Where This Stands, and Takeaways
This is a working prototype, not a shipped feature. There's no relationship with Anthropic's actual Chrome extension team behind it, and it runs entirely on my own Anthropic API key. It's honest about what it hasn't solved yet: the sensitive-field filter is a heuristic (autocomplete attributes and name/id keywords), not a guarantee. A field inside a shadow root won't be detected at all. And if Chrome terminates the extension's service worker mid-task, that task is stuck at "running" with no retry. None of these are hidden in the product. They're documented in the repo alongside everything the audit fixed.
-
Privacy Decisions Are Cheaper Before Code Exists
Choosing select-then-right-click over automatic scanning took one conversation. Walking that back after building the automatic version would have meant unwinding an architecture, not editing a sentence. The cheapest point to make a trust decision is before anything depends on it.
-
An Audit Isn't a Formality for a "Prototype"
I almost treated the security pass as a checkbox before saying the project was finished. It found a bug that would have broken the extension on most React- and Vue-built sites, a functional failure, not just a theoretical risk, hiding in a feature that already worked in every demo I'd tried it on.
What This Shows
This project demonstrates:
- Driving a technical build with AI tooling: I made the product, interaction, and privacy decisions. Claude Code implemented them, including a security audit I directed and then acted on
- Choosing the least-convenient, most-defensible option (select-then-right-click) over the easiest one, before any code made that decision expensive to change
- Treating a security/privacy audit as core process, not a formality, and finding a real, functional bug because of it
- Small copy decisions held to the same standard as big architecture ones: a tooltip didn't ship until the behavior it described actually existed