Engineering
Cycles, backlog and dependencies between tasks, with the pull request and the technical decision tied to the same issue.
- focus
- projects
- docs
Natural collaboration for teams in flow: tasks, projects, docs and boards in one place, with an agent that reaches over MCP whatever your team already uses — and everything keeps working with no connection.
the suite
connects to
muriki doesn't ask you to drop what you already use. The agent connects over MCP to your team's tools and brings the work inside, instead of you copying links back and forth.
An open PR becomes a task with owner and due date, and closes itself on merge.
A long thread becomes a written decision, along with the tasks it produced.
A meeting lands on the calendar already tied to the right cycle.
A new screen shows up on the board with the frame link and current status.
An old document is found by subject, not by file name.
Any MCP server your team already runs comes in the same way.
Task, cycle, doc and canvas are nodes in the same network, next to the people and the tools your team already uses. Pull one thread and the whole context comes with it.
They arrive in waves, and each one shows up knowing what the others already know. None of them starts from scratch, because the data has been the same since day one.
Muriki Focus
Your day
Tasks, subtasks, due dates and focus blocks on the calendar. It's the module already standing, and the one in the screens below.
Muriki Projects
The team's work
Backlog, cycles, roadmap and analytics. Tasks that already live in focus join the board without becoming copies.
Muriki Docs
What was decided
Wiki and documents where the decision lives, with tasks cited inside and always current.
Muriki Canvas
How it's drawn
Visual boards for flow and architecture, with the same tasks and documents as nodes on the map.
muriki was born for engineering teams, where work spreads across the most tools. What solves it there solves it for any team that plans, writes and ships.
Cycles, backlog and dependencies between tasks, with the pull request and the technical decision tied to the same issue.
Editorial calendar, campaigns and creative pieces on the board, with the brief written right next to the delivery.
Pipeline, follow-ups and tickets with response times, without losing the customer history between the conversation and the task.
On your own, focus is enough: the day tasks, the blocks on your calendar and the notes that turn into action, with no team process to set up.
Not screenshots: these screens are actually running here, on the same components as the product, at 390px — the width each one is designed at.
The whole cycle, with dependencies between tasks.
The day as a list, with subtasks, status and due dates.
Focus blocks next to the day's meetings.
They came before the first screen and hold for every module. When a feature runs into one of them, the feature is what changes.
Your data lives on your device and syncs later, in the background. Working with no connection is the product's default behaviour, not an emergency mode with half the features switched off.
Every screen is designed at 390px first and grows from there. What you handle on your phone is the same product you open at your desk, with the same actions — not a stripped-down version for reading.
The same task shows up on the board, inside the document and on the calendar without becoming a copy. Change it in one place and it changes everywhere, because it's the same record read from different angles.
Access opens in waves, as the modules become ready. People on the list go first.