Have you ever tried to manage a complex project through an AI agent conversation? It goes something like this: you ask the agent to build something, it starts working, then you switch contexts, come back, and the agent has no idea what was happening before.
I ran into this problem constantly. So I built Project Overseer — a file-driven project management system that works across OpenClaw, Claude Code, Codex CLI, Cline, and Gemini CLI.
The Core Problem
AI agents have no persistent memory between sessions. They forget context the moment you switch tasks. Traditional project management tools (Jira, Notion, Linear) are designed for humans, not agents.
The Solution: File-Driven Context Isolation
Instead of relying on the agent's conversation memory, Project Overseer stores every piece of project state in plain text files:
projects/my_project/
├── plan.md # Full WBS breakdown
├── status.json # Current state, risks, dependencies
└── tasks/
├── design.md # One file per sub-task
├── backend.md
└── frontend.md
Each sub-task is a separate file. The agent only loads what it needs. When switching tasks, it saves current progress, clears context, and loads the next task file.
5-Phase State Machine
- Requirements Collection — Agent asks clarifying questions before planning
- WBS Breakdown — Each task gets effort estimation, feasibility analysis, and tech requirements
- User Review — You review and approve before execution starts
- Sub-task Execution — Tasks executed one by one with full context switching
- Project Complete — All tasks done, project can be archived
Key Differentiator: Impact Output & Propagation
When a sub-task completes, the agent automatically extracts 6 categories of cross-task impact and propagates them to all dependent tasks as pre-start notes. This prevents naming conflicts and design inconsistencies across your entire project.
Change Management
- Bottom-up: A sub-task discovers conflicts with completed tasks and proactively prompts to unlock them
- Top-down: Say "change requirement" at the master dashboard — the agent runs a full impact assessment across ALL tasks before executing any changes
Zero Setup Required
No API keys. No external services. No database. Just drop the SKILL.md file into your project.
Compatible Platforms
OpenClaw, Claude Code, Codex CLI, Cline / RooCode, Gemini CLI
Quick Start
- Say "project overseer" to start
- Answer requirements questions
- Say "requirements done" for WBS breakdown
- Say "approved" to enter execution
- Say "start " to begin
- Say "back to master" to check dashboard
Links
- GitHub: https://github.com/tigerhu598-dot/project-overseer
- License: MIT
Top comments (2)
The file-driven choice is the quietly correct one, and it's worth saying why it beats the obvious alternatives. Jira/Notion/Linear assume a human reads a UI; agents need state as plain text they can read and write in the same medium they already operate in, the filesystem. Making the project plan a file means it survives the session, it's diffable, it's version-controlled for free, and any of the CLIs (OpenClaw, Claude Code, Codex, Cline, Gemini) can pick it up because they all speak files. That cross-tool portability is the real unlock, your state isn't trapped in one vendor's memory feature. I run almost this exact pattern, durable file-based state plus a hard log of decisions and don't-do-this constraints, and it's the single biggest lever for keeping a long-running agent coherent across context switches. The hard part I'd guess you hit: keeping the file authoritative when the agent's in-context belief and the file drift apart. How do you handle that, force a re-read of the file at each session start, or treat the file as the only source of truth the agent's allowed to act on? This is core to how I think about Moonshift's run state.
Thanks for the reply — you're the only person who's commented on this article. The project has actually gone through two more iterations since this post (v2 and v3), with much stronger capabilities and reliability built in. I just haven't been able to push the updates publicly since there wasn't enough traction.
To your question: we actually do both, and here's why both are necessary.
Force re-read? Yes. Every time the agent switches context (e.g., from master view to a sub-task), it loads the target file from disk and verifies it — exists, readable, format correct. No in-memory cache is trusted across context boundaries.
File as sole source of truth? Also yes. Rule #1 of our Agent Discipline is: "Never rely on conversation memory alone." If it's not on disk, it didn't happen. The agent is explicitly forbidden from acting on what it "remembers" from earlier turns without first reading the file.
These two aren't alternatives — they're two sides of the same lock. Force re-read without file-authority just means you load fresh data you still won't act on. File-authority without re-read means you trust a stale snapshot. You need both.
In practice, these rules are baked into the SKILL.md execution logic, not tucked away in a config file or feature flag — the agent reads them on every session start and follows them as part of the workflow protocol.
Sounds like Moonshift and this project are converging on the same pattern. File-driven state really is the only reliable way to keep agents coherent across context resets — vendor lock-in comes and goes, but files are forever.