Idea
Some project ideas arrive fully formed. This one arrived because repeated AI sessions were starting to feel like leaving notes for an unusually fast intern with selective hearing.
The aim was simple: make project planning easier to break into clean, separate tasks, then give each task its own fresh session. Less context per session usually means fewer invented details, fewer strange detours, and a better chance of getting through larger builds without trying to force the whole thing through one oversized prompt.
The result was a small CLI tool, paired with a skill file, that turns a plan into manageable pieces. Tasks can be created, updated, claimed, and completed one at a time, which keeps the work moving without asking the agent to remember the entire history of the project every few minutes.
It also doubled as an excuse to spend some time with Go, which felt like a sensible choice for a fast little command-line tool that mostly needs to read files, write files, and stay out of the way.
Useful for small teams, solo builders, or developers trying to keep AI-assisted project work organised without turning every task into a memory test.
Status
The tool is working and has already been used across several projects, which is usually the point where something stops being a neat idea and starts becoming part of the furniture.
The CLI handles the expected CRUD work for tasks, plus a claim function that returns the next available task and marks it as in progress. That matters more than it sounds. A repeatable “start the next task” flow removes a surprising amount of friction, especially when work is split across separate sessions.
Tasks are stored as JSON files inside a .wtp directory. That keeps the format plain, inspectable, and easy to version in Git if needed. It also means the agent can manage the files directly even if the wtp command is not available, though that comes with a higher token bill and more context overhead. Convenience is rarely free. It just likes to hide the invoice.
Problems Faced
This was not one of those projects where every step fought back. Most of it went together quickly, and Go turned out to be pleasantly direct for this kind of tool.
That said, “it was simple” is only useful if you explain why. The scope stayed narrow. The task model was file-based from the start. The commands were practical rather than ambitious. There was no database to invent, no service layer to justify, and no need to pretend a handful of JSON files required enterprise ceremony.
The main challenge was restraint: keeping the tool focused on task management instead of slowly turning it into a full project platform with a much worse user experience. Small tools stay helpful when they resist the urge to become a lifestyle.
Techniques That Helped
The build worked well because it was done slightly backwards.
Instead of starting with abstract requirements, the .wtp folder was created first with sample JSON task files. Once that existed, the agent could work from something concrete and build the CLI around a real structure rather than guessing at one.
That gave a few clear benefits:
- The file format was visible from the start, so there was less back and forth about shape and naming.
- The agent had real examples to follow, which cut down on avoidable confusion.
- The scope stayed honest, because the tool only needed to support the workflow already shown in the sample data.
For small utilities, this approach is hard to beat. If the tool is mostly about reading and writing structured files, sample data acts as both spec and test fixture, which is far more useful than a paragraph full of intentions.
Lessons Learned
Go feels approachable for small command-line projects, especially where the job is mostly file handling, simple state changes, and predictable commands. There is still plenty more to learn, but it made a good fit for a tool that needed to be quick, clear, and boring in the right ways.
The bigger lesson was about working with agents. Concrete inputs make a noticeable difference. Handing over sample files gives the model boundaries, reduces needless decision-making, and helps keep a simple format simple. That saves time, tokens, and the sort of accidental complexity that usually arrives wearing the badge of “future flexibility”.
Breaking project work into smaller claimed tasks also made the wider workflow easier to trust. Each session had one job, one slice of context, and a clearer finish line. For larger builds, that matters more than chasing the perfect prompt (and now we can use wtp to manage them).
If you are trying to make AI-assisted project work feel less chaotic and more repeatable, we are always happy to help you sort the process out.
