Project Management for Developers: Context Over Tickets

Which ticket is still open? Which dependency blocks it? Can the next agent answer either question without asking for a chat transcript?

These questions come up when a developer starts two coding agents on different parts of one epic. Both agents read the requirements. Both make notes. Each starts a reasonable implementation. Say one agent finishes the login change while the other keeps building against the old session code, because the only note about it sits in the first agent's chat. Meanwhile, the status is scattered across a chat thread, a code comment, and someone's memory. By the next handoff, neither agent has the full record. The developer has to rebuild it.

Why Doesn't a Project Board Fix This?

A board shows people the work. An agent needs more. A person can scan columns, open cards, and infer connections from labels. An agent needs a query it can call before it acts, one that names the open work, blockers, requirements, and current status without asking someone to repeat yesterday. Project management for developers is a context problem, not a board problem.

A full backlog dump also fails. Closed work, unrelated epics, and long comment threads take up the same context window as the ticket that blocks progress. The answer may exist. It is buried.

Coordination trouble is older than agents. A 2009 Microsoft Research study of a 300-person team, based on 31 interviews and a survey of 775 engineers, found that coordination was most affected by problems of communication, capacity, and cooperation. A second agent adds another handoff path. Each agent can do sound work in one place while missing a constraint that changed elsewhere in the epic.

How Does AuricIDE Keep One Work Record?

AuricIDE puts the tracker behind an MCP server called auric-pm. MCP lets an agent call tools in another program. Agents create and update tickets through those calls, so the latest answer does not stay trapped in one chat. The protocol side is covered in how an MCP server fits AI development workflows.

AuricIDE stores the records in one SQLite file inside the project folder:

<project>/.auric/project.db

The first time AuricIDE sets a project up, it writes a .gitignore into the .auric folder. Git then ignores that whole folder by default. The database stays on the machine.

The developer sees the same records. The Work view in the app has a Tickets tab that shows what agents create through auric-pm. Nobody needs to copy ticket data between an agent prompt and a separate tracker. It also makes disagreement visible: a ticket has one recorded status, even when two chats tell different stories. The tools cover epics, tickets, tasks, dependencies, test cases, requirements, goals, history, blueprints, and context.

Tools that take a ticket or epic ID accept a full UUID or a unique prefix with at least four characters. An agent can reuse the short ID during a tool sequence instead of repeating the full value. A prefix with no match returns an error. An ambiguous prefix also returns an error that names the candidates. The tool never guesses.

What Does the Unfinished Tickets Overview Return?

get_unfinished_tickets_overview returns unfinished tickets grouped by epic. Its narrow result includes the fields needed to choose the next piece of work. Without this call, an agent starting cold has two options: read every ticket, or ask the developer. The tool takes no parameters, which helps a fresh agent that does not yet know enough to choose a filter.

Unfinished tickets are not done, archived, or discarded. Each result includes the ticket's ID, name, status, heat, and the names of its blocking dependencies. Heat counts the other tickets that depend on it. Say "Session refresh" and "Logout" both wait on "Token storage". The overview gives "Token storage" a heat of 2. It also names "Token storage" as a blocking dependency for the other two tickets. Descriptions and history stay out. The tool description promises "minimal details for context efficiency," and the result keeps that promise so an agent can read the full overview before choosing.

The first call gives the agent a map. It shows what remains, which work cannot start, and which tickets have other work waiting behind them. Heat is evidence, not a priority rule. A hot ticket may still be the wrong choice when a requirement is unclear or a blocker remains open.

After choosing, the agent can use the ticket's short prefix. A status change made through update_ticket goes into the ticket's status history. The next agent can ask the tracker before asking the developer. The developer can open the same ticket in the Work view.

The shared record does not replace judgment. An agent can still misread a requirement, choose a poor design, or update the wrong ticket. The record makes those choices easy to inspect and gives each handoff a known starting point.

What Does the Single-Machine Decision Cost?

AuricIDE keeps the record local. That choice rules out automatic sharing between machines and people. It has no cross-device sync. It has no shared multi-seat web view.

Git ignores the folder, so a clone brings the code and not the backlog. A second developer who clones the project gets no tickets, dependencies, status history, or overview of unfinished work. Teams that need one shared browser view should treat this limit as a deciding factor from the start.

Local storage also cuts some setup. Project data does not leave the machine by default, and agents need no hosted tracker credentials to query it. One developer running several agents on one machine gets a short path from a tool call to a visible ticket. That developer may accept the cost. A team working across several machines may not. Both choices have a price.

What Still Matters in Any Fleet Setup?

Any fleet setup needs a cheap query that answers two questions: what remains, and what blocks it. The storage format may change. Every handoff still needs that answer. A fair test for any tracker is whether a new agent can get the open work and its blockers in one call, without reading everything else.

Give each agent a small overview first. Include stable IDs, current status, and dependencies, then leave descriptions and history for a later query. Record status changes where the next agent can find them. Reject ambiguous IDs instead of guessing. Human and agent views should show the same work. If they differ, every correction adds another task, and someone must keep two partial records aligned.

Handoff delays also appear in delivery metrics such as cycle time, lead time, throughput, and work-in-progress. Software engineering analytics guidance defines those measures and gives teams a way to inspect queue buildup without confusing activity with progress.

Nobody has to swap a whole project system for a local database. Agents need a compact project query before they need another long prompt. Agentic IDE workflows cover the wider setup, and agent monitoring guidance covers watching the agents themselves.

AuricIDE is an open-source desktop workspace for coordinating CLI coding agents. Visit AuricIDE to see whether the single-machine trade-off fits the fleet you are building.