At Canvs, we work with large banking clients, which means the material moving through the studio cannot leave it. The problem is that small file jobs (merging a PDF, resizing an image, stripping metadata, checking a block of JSON, CSS → Tailwind) keep sending us to browser tools all the time. Every third-party site that does those things begins by asking for an upload. What happens to the file after that is not something I can verify from the outside, whether it is retained, whether it feeds somebody's training data, whether it is deleted at all, so there is a standing privacy concern attached to a task that looks routine.
I wanted the same convenience without the upload. So I built LocalKit, a browser-based collection of more than 50 utilities that needs no account and no install. Every operation runs on the machine through WebAssembly, FFmpeg, PDF.js or the browser's own APIs. Once the site has loaded, the tools keep working offline, because nothing leaves the machine and there is nowhere for it to go.
How I build with agents now
His tool has 50+ file utilities that he uses regularly, all done local on his machine.
Issue tracking before anything else:
The first thing I run in a new repo is a setup command from a set of reusable Claude skills built by Matt Pocock, which wires up issue tracking. At Canvs that means Jira. On personal projects, it creates GitHub issues, or a local issues folder if the repo has no remote. Nothing else in this process works without a fixed place for the work to be written down.
A grill session before any code:
I use a grill-me skill that makes the model interrogate me instead of assuming things. For LocalKit, the questions that mattered were the boring structural ones. Which operations can the browser handle natively and which need WebAssembly, what happens when a file is too large to hold in memory, how a user gets told an operation failed. Those get settled here, before anything is written. This makes sure that your thinking also aligns with the agent.
Tickets from the agreed intent:
The model takes the settled intent and breaks it into small units of work. A tool like this is a good fit for that shape, because a single utility is a single ticket. PDF page reordering is one ticket. Metadata stripping is another. Each one is small enough that I can tell from the outside whether it is done.
One ticket at a time, with permission to continue:
Execution picks up a single ticket, solves it, verifies the output, and asks before moving on. Verification here means running the utility on a real file and checking the file that comes out, not reading the code and assuming. I stay in the loop at every handover rather than at the end.
Using a task list instead of one-shotting the whole feature
Describing a whole feature in one prompt gave me something broken roughly 99 times out of 100. The problem was where it broke. Not at the surface, where I would notice, but somewhere in the middle, so I would spend longer finding the fault than I would have spent writing the thing myself. Tickets fail smaller. A wrong assumption shows up inside one ticket, I catch it there, and it does not get carried into the ten after it.
LocalKit is a small internal tool, built for the team and for myself, so what I have described is the short version of the process. The same sequence holds when the work gets larger, and it is how I approach the projects at Canvs. We will be sharing more on the agentic tooling we are putting together internally. Until then, keep tinkering.
