I was setting up a side project, agents hard at work for me. In those early moments, changes often cover more ground than expected, codebase is new and standards are not as defined. I got into the habit of asking a different agent to review the ongoing work. Like most things, it’s not perfect but it captures good signals.
The issue: I’d often end up with a stream of 10 or more issues to fix. While a lot of it deserved attention, like any review, they can be loaded: quick fixes, things needing iteration, items better left for later or tied to a bigger refactor. That’s where a single Claude or Gemini prompt started to fall short.
The initial POC: an stdio MCP server backed by a table of tasks in SQLite. I reloaded the session that gave me my last review with 10+ comments, and asked the agent to create tasks from the feedback. Now I had a filterable list, editable descriptions, easy to reorganize and hand off to different agents across different sessions.
This could all go into regular issues, but it never felt worth it. Most of it needs to be addressed within the same PR… suddenly you’ve got 10 issues linked to a single PR. I enjoy the local iteration. It serves me well as short/medium TODO tracking.
After dogfooding this across a couple of projects, including whackAmole itself, my workflow matured alongside the features I added. Below are the ones that stood out for my day to day.
CLI vs MCP vs UI
Maybe obvious, MCP for agents, CLI/UI for myself, cli was good to create projects, add tasks. Viewing started to feel limited, especially when agents started feeding tasks with 30 lines of description. That’s where the UI started to shine for me.
Overall, they play well with each other. CLI enables me to quickly add tasks or update status when I am heads down. That’s how everything started.
MCP was always a goal. Yes, the agent could use the CLI, however, it means that I need to document in each project how to use it. The agent does a better at picking up from the tool name and description what to do with it. Sadly, that’s also what removed some of the whimsicality of the project where Project were Yards full of Moles to whack. Conventional naming makes it easier to understand, what is true for humans is also true for agents.
The UI became my command center. Whenever I see an Agent producing a big review or plan, I will likely ask it to create tasks. I find it more comfortable to read, and also, for better or worse, easier to multitask between projects. I find myself writing the task in the UI rather than directly prompting the Agent more and more.
Projects
Project enables an easy breakdown, agents publish, view and edit tasks from a single project. The trick is the scoping. I found it awkward to always have to add the project to the CLI, so I added a whack config set-local project <projectKey>. This has been a life saver for me, each project root has a config file with the project key. I no longer have to add the project key to any commands.
Agent setup, the project key being a very local thing, it didn’t feel right to add it to the AGENTS.md or any global agent spec. I started leveraging CLAUDE.local.md and GEMINI.local.md. Those files contain a quick guide, typically:
You have access to the whackAmole MCP server for task management.
whackAmole project key is whack
MCP.instructions
Claude picked up pretty naturally on the tasks, updating status. Gemini… not as well.
Since the tasks could sometimes be more complex, adding a supports Markdown to the description was enough to get the agents to use markdown. Now I get formatted tasks with headers, bullet points and even code snippets.
For the flow, I initially started adding instructions to the .local.md files which quickly turned out to be a pain to manage. Eventually, I started leveraging the instructions block of the MCP server. In the UI, there’s a config, top right that enables editing the instructions that are attached to each instance. An example will best illustrate how I use it:
# MCP Protocol: Project Task Lifecycle
## 1. Task State Management
The agent must strictly follow the semantic state machine for the current Project.
* **Pre-Execution**: Before performing any code changes or terminal actions, the agent **MUST** update the task status to `INPROGRESS`.
* **Pre-Validation**: Before requesting user feedback or validation, the agent **MUST** update the task status to `REVIEW`.
* **Closure**: Only the user may move a task to `COMPLETED` or `CLOSED` terminal states. The agent is prohibited from performing these transitions.
## 2. Quality Gates (Non-Negotiable)
Before a task can be transitioned to `REVIEW`, the agent must ensure the code is production-ready across all relevant languages.
* **Linting**: All changed files must pass the project's configured linter (e.g., `golangci-lint` for Go, `eslint` for Preact/TS).
* **Testing**: All relevant unit and integration tests must pass.
* **Protocol**: If linting or tests fail, the agent must remain in `INPROGRESS` and resolve the issues before attempting to move to `REVIEW`.
## 3. Interaction Constraints
* **Permissions**: Always request user approval before refactoring existing code or changing established coding patterns.
* **Project Context**: Ensure all actions are performed within the scope of the active Project Key.
Overall it works well, even Gemini does a better job at tracking of its task. It’s not as strong as a prompt, but it’s also easier to maintain. A decent enough trade off.
UI
I found myself using the UI more and more:
- Pretty printing Markdown
- Quick toggle groups for Type and Status
- A bit of color coding to quickly catch what’s happening
Refreshing was getting more and more tedious, so I wired a quick event log that the UI uses to refresh task statuses, or when tasks are being added, show which projects are getting updates.
That’s my latest workflow improvement in the wild west of agents. Curious how others are pulling through these days.