MCROC Describe the task. The AI does the rest — once you approve it.
ocTask is lean task management for teams: sprints, board, backlog, issues with comments and attachments. The difference is what happens next — an approved issue can be read, planned, implemented and handed back as a merge request by an AI development tool.
ocTask board with sample data.
Between the ticket and the code there is always someone translating.
Describing and building are separate
The issue says what is needed. The code appears in the editor. In between, a human translates every single time.
AI tools do not know your project
An assistant in the editor sees the open file — not the agreement that landed as a comment on the issue two weeks ago.
And who approved it?
The moment AI writes code, one question matters above all: who decided it was allowed to — and where can that be read afterwards?
From issue to merge request — in five steps.
The link between task management and source code is the issue key. It appears in the branch name, in the merge request and in every comment. That is what makes it traceable later where a change came from.
Describe
You create the issue as you always would: title, description, priority, attachments. Nothing special, nothing AI-specific.
Approve
One label makes the task visible to the AI. Without that label it does not exist for it — however obvious it may look.
Understand
The AI reads the issue and its comments, judges whether the description holds up, and writes its implementation plan in as a comment. If it does not fit, you correct it right there.
Implement
It takes the issue, checks out the source, implements and opens a merge request — with the issue key in the branch and the title.
Review
A human reads the merge request and merges it. The issue moves along the board, with its full history.
Everything task management needs day to day.
Sprints, board and backlog
A board with drag & drop, sprints you can plan, and a backlog that does not turn into a dumping ground.
Issues with substance
Description templates, sub-tasks, links, story points, labels and file attachments.
Comments with @-mentions
Whoever is mentioned gets a notification — and reactions save you the third “sounds good”.
Full-text search across everything
Searches issues and comments by word stems: “report” finds “reports”.
Watch instead of chase
Watch an issue and see what changes — without having to nudge anyone.
Burndown per sprint
Shows whether the sprint still holds — while there is still time to change something.
22 tools that Claude Code and OpenCode operate directly.
The connection runs over MCP — the open standard through which AI tools operate other systems. The server sits inside ocTask itself: nothing to install, no per-machine copy that could fall behind. The tools call the same endpoints as the user interface, so the same permissions apply — and every change is recorded in the issue history with the person behind it.
Read-only tools are marked as such in the protocol. Claude Code asks before every writing tool.
Reading
- search and filter issues
- read an issue with hierarchy and links
- read comments
- fetch board and backlog
- sprints and burndown
- your own notifications
Writing
- create and update an issue
- change status
- assign
- move into a sprint
- comment, with mentions
- watch
Approval stays with the human. Without exception.
This is where it is decided whether you want something like this in your own organisation. Which is why it is here and not in the small print.
- One label releases a task to the AI. Without it, the task does not exist for it.
- An access token grants no rights, it borrows them: what the account may not do, its token may not do either.
- Deactivate an account and its token stops working. Revoked tokens stay visible — including when they were last used.
- Every change is in the history with the person behind it. The AI’s changes too.
- What comes out is a merge request, not a commit on the main branch. A human reads it and merges it.
The starting state is “sees nothing”.
Enforced in the data layer
The project boundary is not checked at each endpoint but centrally in data access. A forgotten filter therefore returns nothing rather than too much — and a new endpoint is protected by default.
Client and development on one board
Your staff see their project and work in it. What sits next to it does not exist for them — not in search, not in notifications.
Proven, not asserted
The separation is backed by dedicated tests that check every entry point from the other side’s point of view.
On your own machine — or on mine.
ocTask ships as one image containing the interface and the API; alongside it run the database and a reverse proxy that obtains its certificate itself. Deployment, backup and restore are documented and automated. Every merge request also brings up a test instance — so the state can be looked at before it goes live.
See ocTask on a project of your own.
In a short demo I walk the path from issue to merge request — on a real task, not on a sample project.
Book a demo →