Project Management Built for an AI-First Workflow
We needed project management an agent in my terminal could drive. So the MCP server came first, and the app got built around it.
As the work at LMS started to grow, communication, task management and bug reporting got cumbersome between me and the project manager, who is also the head of LMS Technology. We obviously needed a project management tool.
I looked at the popular ones. Linear, Jira, and I considered just using GitHub Issues. With Linear I went further than looking: I built and published a CLI that bridged it into git and Claude Code, and it still wasn't the workflow I wanted. None of them really fit what the modern development space needs, which is an AI-first workflow.
So I decided to build an internal tool that fit the way developers actually work today, in the terminal, with AI.
The parts every tool has
The essential ingredients aren't complicated. You divide work by project. Each project divides into tasks with statuses. Each task holds the context of its acceptance criteria, where it's at, and where it sits in the process, from the conceptual stage all the way through deployment. That's essentially what every project management tool does.
The part they don't
What none of them deal with is where the context actually lives now.
Modern AI workflows are local first, in the terminal. The AI is writing markdown files and keeping context on your machine. That's great for local development, but it doesn't spread to anybody else unless you commit the files. And once you commit them, they typically go stale and unorganized.
The other half is speed. AI development is rapid, so the tool has to move at that pace rather than be something you go update afterward.
So the MCP server was the front and foremost thought in its development, not something added on later.
Context at two levels
Two things I built that most tools don't give you. Project grouping, which a lot of tools don't even allow. And project-level context: each project holds a summary and an about, and you can attach documents to it, specifically markdown files, describing the project at a high level.
Context lives at both levels. The project stores it, and each task stores it, and attaching markdown is easy at either one.
Here's a feature I think is really cool. Each project holds GitHub URLs and links to its repository. The local agent can take that URL out of the project context and use it to find the repository on my computer.
The resulting workflow
From my local terminal, Claude Code already knows about the MCP server. I say: make a plan for this project, and here's the criteria.
It looks up the project in the tool and pulls all the context. It searches tickets and gets recent history. It uses the GitHub URL to identify the repository on the computer and does its discovery there. Then it creates the tasks and the plan, tags them per feature, writes the plans out as markdown files, and attaches those files to each task.
Then I can point another agent at it. Implement this feature, or review it. It does a search on the MCP tool, it already knows how, finds all the relevant tasks, and starts reviewing or begins implementation.
So I'm taking the local, context-first flow and giving it visibility across the organization, which in ours is one other person, plus a historical record that doesn't live on my machine.
Rolling reports
I added some AI on the dashboard too. Opening it sends a task off to Sonnet to review the work since the last summary and write up what's been done, throttled so it runs at most once every thirty seconds. You click back and forward through those to read the reports and get a clear picture of what was accomplished.
This tool has been really great for our productivity, and it solves a lot of problems that tools like Linear don't.
Built at LMS Technology, solving software in the new generation.