I am not a software engineer. I think in milestones, user stories, and outcomes. Kim wants a smart garden assistant that tells her when to water and when the blight risk is high. I want to build it. Solo homelab projects like this usually die in a half-finished Docker Compose file. Ceres is different, and the reason is three tools working together: Gitea, the Gitea MCP Server, and Claude Code.
The Setup
Ceres is a multi-agent garden assistant: seven specialists coordinated by an orchestrator, drawing on soil sensors, a fixed camera, weather data, and TimescaleDB. I’m the only developer. Kim is the only user. The project is in Phase A, before a single line of application code has been written.
I structured everything around 11 phase milestones in Gitea, from Phase A (sensors and site prep) through Phase K (final go/no-go). Each milestone has specific, actionable issues with completion checklists. Issue #23 for NocoDB setup, for example, has 13 discrete tasks including building curated views, pre-populating dropdowns, and testing with placeholder data before the real data session. That level of specificity is what separates a real definition of done from “set up the database UI.”
The CLAUDE.md File
Claude Code reads a CLAUDE.md file at the root of any project it works in. Think of it as the briefing document you’d give a new contractor on day one, except it actually gets read every single time before any work starts. Mine tells Claude what phase we’re in, which specs and ADRs to check before making changes, and critically, that it should check the Gitea milestones for actual task state before assuming any service exists. When I ask Claude to help with the FastAPI backend, it sees we’re in Phase 0 and asks whether I mean “scaffold the folder structure” or “write application code.” That distinction prevents a lot of wasted effort.
The Gitea MCP Server
With a small .mcp.json in the repo root, Claude Code connects directly to Gitea. It can read and write issues, check milestone progress, and update task checklists as work completes. The project management layer and the coding assistant are now part of the same conversation. I say “let’s work on Phase I,” Claude pulls issue #36, sees that 4 of 6 items are done, and helps me finish the remaining ones while keeping the issue updated. The tracker and the work stay synchronized.
Why This Works for a PM
The real win is that your decisions stop living only in your head. I have two Architecture Decision Records in the repo: one establishing the monorepo and trunk-based development approach, one establishing that the database is the source of truth for anything Kim should be able to change without engineering involvement. Both are linked from CLAUDE.md. Claude knows the rules and why they exist. When I have a thought or concern while working with Claude Code, I can just say “create an issue, document the options.”
The result is a backlog where 42 issues across 11 milestones are planned, the sequencing is mapped, the dependencies are understood, and my AI coding assistant has full context before I type the first character of a session. I haven’t manually written an issue yet.
For product managers who want to build: you do not have to choose between moving fast and staying organized. Put your decisions in the repo. Write the CLAUDE.md. Connect your issue tracker. Let the AI close the loop.
