There's a sentence I type at least five times a day now: "commit, comment and move the task to done." That's it. That's the instruction. Claude reads the task from our board, implements the change, commits the code with a sensible message, leaves a comment on the task explaining what it did, and moves the card to the Done column.
Six months ago I would have described that workflow as aspirational. Now it's so routine that I catch myself getting impatient when Claude asks a clarifying question instead of just getting on with it.
How It Started
The setup is straightforward in principle. Task Board has an MCP server. Claude Code connects to it. Claude can read boards, read tasks, create tasks, update tasks, add comments, and move tasks between columns. Each of these is a discrete MCP tool.
The original idea was simple: save myself the context-switching of reading a task description in the browser, copying relevant details into Claude, and then going back to update the task when the work was done. I wanted Claude to be able to read its own brief and file its own paperwork.
What I didn't anticipate was how much this would change the actual development workflow. It's not just about saving clicks. When the AI has direct access to the task management system, the entire rhythm of development changes.
A Typical Session
Here's what a development session looks like now. I open Claude Code, connect to the Task Board MCP server, and say something like: "Check the Sprint board. What's the top priority task?"
Claude reads the board. It comes back with something like: "The top priority task is TB-247: Fix date picker not closing on outside click. It's assigned to you and has a description with reproduction steps."
I say: "Read the full task and implement the fix."
Claude reads the task description, looks at the reproduction steps, finds the relevant component in the codebase, identifies the issue, and implements the fix. Sometimes it asks a clarifying question. Most of the time it just gets on with it.
When it's done, I review the changes. If they look right, I say the magic words: "Commit, comment and move the task to done."
Claude commits the code with a descriptive message, adds a comment to the Task Board ticket explaining what was changed and why, and moves the card from In Progress to Done. The task board updates in real time. The git log has a clean commit. The ticket has documentation of what was done.
Total time for a typical bug fix: five to fifteen minutes. Total time I spent in the Task Board UI: zero.
The Comment Game
The comments Claude leaves on tasks deserve their own section, because they turned out to be unexpectedly valuable.
When Claude comments on a completed task, it writes a brief summary of what it changed, which files were modified, and the reasoning behind the approach. This wasn't something I explicitly designed - I just told it to "comment on the task" and it figured out that a useful comment would include these details.
The result is that our Task Board is now full of detailed implementation notes that I never would have written myself. Let's be honest - when I close a task manually, the comment is usually something like "done" or "fixed" or nothing at all. Claude writes actual documentation. Every time. Without being asked twice.
This has been surprisingly useful for reviewing what happened during a sprint. Instead of looking at commit diffs to understand what changed, I can read the task comments and get a plain-English summary. Future me, debugging something at midnight, will appreciate this more than current me can express.
Investigating Bugs From the Board
The workflow gets particularly interesting when Claude investigates bugs. A task on the board might say something like: "Users reporting that the export function generates an empty CSV when filtering by date range. Happens intermittently."
In the old workflow, I'd read this, form a hypothesis, search the codebase for the export function, trace the logic, check the date handling, and eventually find the issue. With MCP, the conversation goes differently.
Claude reads the task. It reads the full description, including any notes or comments from whoever reported the bug. Then it goes into the codebase - checking the export controller, the filtering logic, the CSV generation code. It's reading the brief and doing the investigation in one fluid sequence.
What I find remarkable is how closely this mirrors what a good developer would do. Read the bug report. Understand the reproduction steps. Form a hypothesis. Check the code. Verify the hypothesis. Implement the fix. It's the same process, just faster and with access to both the task management context and the codebase simultaneously.
Application Insights to Task Board to Claude
This is the part where the automation started feeling genuinely powerful rather than just convenient.
I started feeding exceptions and errors from Application Insights into Task Board. Not all of them - I'm not that ambitious. But recurring errors, unhandled exceptions, performance anomalies. They show up as tasks on a dedicated board.
Claude picks them up just like any other task. It reads the error details, the stack trace, the frequency, the affected users. Then it goes into the codebase to investigate. More often than not, it identifies the root cause and proposes a fix.
So the pipeline is: production error gets logged in Application Insights, gets created as a task in Task Board, Claude reads the task via MCP, investigates the codebase, implements a fix, commits the code, comments on the task with an explanation, and moves it to done.
The human in this loop (me) reviews the fix before it hits production. I'm not quite at the point where I'd let AI-generated bug fixes auto-deploy. But the investigation, the diagnosis, and the implementation? Claude handles all of that. I'm reviewing finished work rather than doing the initial detective work myself.
The Recurring Command
"Commit, comment and move the task to done" has become such a fixture of my workflow that I've started thinking about automating it. Not making it happen without my involvement - I still want to review every change before it's committed. But reducing it to a single command or even a keyboard shortcut.
There's something satisfying about the cadence of it. Pick up task. Implement. Review. "Commit, comment and move the task to done." Next task. It's a rhythm, and the MCP integration makes it seamless. There's no friction between the development environment and the project management environment because, from Claude's perspective, they're the same environment.
On a productive day, I'll move through eight or ten tasks like this. Bug fixes, small features, refactoring work. Each one taking five to twenty minutes. Each one properly documented with a commit message, a task comment, and a clean state on the board.
Compare this to how fast I moved before AI: maybe two or three tasks a day, if I was focused and uninterrupted. The speed increase isn't because the coding is faster (though it is). It's because the overhead is gone. The context-switching, the copy-pasting, the manual task updates, the "I'll write the commit message properly later" that never happens. All of it, gone.
What Could Go Wrong (And Has)
I should be honest about the failure modes, because this isn't a flawless system.
Claude occasionally misinterprets a task. A ticket that says "improve the search performance" could mean "optimise the database query" or "add client-side caching" or "implement debouncing on the input". Without enough context in the task description, Claude guesses. And sometimes it guesses wrong. I've had to reject implementations that were technically fine but solved the wrong problem.
The fix is better task descriptions. Which, ironically, is the same fix you'd apply for human developers. Garbage in, garbage out, whether the developer is carbon-based or silicon-based.
There's also the risk of getting too comfortable. When the workflow is this smooth, the temptation to rubber-stamp Claude's changes without properly reviewing them is real. I've caught myself doing it. A quick glance at the diff, "looks fine", commit. That's vibe coding by another name, and it's just as dangerous when the AI is moving your task cards as when it's writing your functions.
The Bigger Picture
What I've essentially built is an AI development workflow where the project management and the development happen in the same conversation. The board isn't a separate system that I check between coding sessions. It's an integrated part of the development environment, accessed through the same interface I use to write code.
I don't think this is the future for every team. Large teams with complex workflows, multiple approval stages, and compliance requirements need more structure than "tell Claude to move the card." But for a small team - especially a solo developer or a pair - it's hard to overstate how much friction it removes.
The AI isn't just a coding assistant anymore. It's a coding assistant that knows what it's supposed to be working on, can check its own task list, can document its own work, and can file its own paperwork when it's done.
All I have to say is the magic words.
