What developer problem do you wish there was a great open-source tool for?

[ismailhalawa-ctrl]

I've been thinking about this after running into a problem in my own workflow.

I often use different AI coding tools, and when I switch from one tool to another in the middle of a project, it can be surprisingly difficult to keep everything in sync — what has already been done, which files changed, decisions that were made, errors or failed tests, and what still needs to be completed.

That made me curious about something broader:

What's one problem in your daily development workflow that you wish there was a really good open-source tool for?

It could be anything — AI tools, Git/GitHub, testing, debugging, APIs, databases, CI/CD, local development, automation, or something completely different.

What still feels unnecessarily difficult, repetitive, or frustrating?

And if you could have one tool built tomorrow to solve a problem you regularly face, what would you want it to do?

I'd really like to hear what other developers are struggling with.

[chris-crts]

One problem I'd love to see a great open-source tool solve is maintaining reliable project context when switching between AI coding agents.

The problem isn't really the AI model itself. It's the loss of engineering context between sessions/tools: what was changed, why it was changed, which files were touched, what tests were run, what failed, what was intentionally left unresolved, and what still needs to be done.

I'd imagine a tool that acts like a portable engineering session journal rather than another AI coding agent. It could automatically capture:

Git diffs and commits
files modified by an agent
commands/tests executed and their results
decisions and reasoning explicitly recorded by the developer
failed approaches and why they were abandoned
current TODOs/blockers
links to relevant issues/PRs

Then another AI tool could consume that context when you switch from, say, Claude Code to Codex or another agent.

The important part would be keeping the data tool-agnostic and local/open-source, so the developer owns the project history instead of locking it into one AI provider.

In other words: Git tracks what changed in the code; I'd like an open-source equivalent that tracks the engineering context around why and how it changed.

[ismailhalawa-ctrl]

I really like the way you framed this. The distinction between preserving engineering context and simply preserving the AI conversation is especially important.

The points about tracking what changed, why it changed, failed approaches, and unfinished work make a lot of sense. Those are exactly the kinds of details that can easily get lost when moving between tools.

I also like the idea of keeping it local and tool-agnostic, so the developer owns the context rather than being locked into one provider.

Out of curiosity, how do you currently handle this in your own workflow when switching between agents?

[chris-crts]

Sorry for the late reply! 😅

Honestly, I mostly handle it manually right now. Before switching agents, I usually leave a quick note with what I'm working on, what I've already changed, what I tested, what failed, and what's still left.

I also use Git to figure out what changed, but the annoying part is that Git doesn't really tell you why something was changed or what approaches were already tried and ruled out.

For bigger tasks, I'll sometimes keep a Markdown file as a little investigation/handoff log. It works, but of course it's another thing I have to remember to maintain.

That's basically why I thought this would be useful. 😅 It'd be nice if the context could be captured automatically from Git, tests, terminal activity, etc., so when I switch agents I can just hand it over and say, "here's what happened so far... bla, bla, bla...."

Kind of like a case file for the project instead of having to start from zero with every new agent.

[ismailhalawa-ctrl]

That makes a lot of sense Especially the part about having to maintain a separate Markdown log ,it works, but it’s easy to forget.

Really appreciate you sharing your actual workflow. It’s helpful to see that this is a real problem for others too!

[chris-crts]

Yeah, exactly 😅 The Markdown log is useful when I remember to keep it updated, but during a busy debugging session it's usually the first thing I forget.

Even a simple tool that automatically captured the important context in the background would make switching between agents much easier. I think there's definitely something interesting to explore there.

[chris-crts]

I'm glad my experience was useful! I think we've covered the main point from my side. If you feel my response sufficiently answered the discussion, feel free to mark it as the answer or close the discussion whenever you think it's appropriate. 👍

[Dani-8]

An Open-Source Context Protocol & Session Journal for AI Coding Agents

To solve the loss of engineering context when switching between AI coding agents (like Claude Code, Codex, or local LLMs), the ideal open-source tool would function as a Local AI Session State & Context Protocol.

Core Architecture & Features:

1. Standardized Context Schema (.ai-context/):

   • Operates similarly to .git/, storing local, human-readable JSON/YAML session manifests that track:
     • Diff & Execution Logs: Captured Git diffs, modified file paths, and terminal outputs (including test failures and errors).
     • Reasoning & Decisions: Architectural decisions, explicitly abandoned approaches, and key constraints.
     • Active State: Remaining TODOs, open questions, and active blockers.

2. Tool-Agnostic CLI Engine:

   • A lightweight CLI (e.g., aictx) that hooks into Git triggers and local terminal sessions to automatically log actions without manual entry.
   • Exports session snapshots into compact, prompt-ready markdown or JSON payloads tailored for any major AI model input window.

3. MCP (Model Context Protocol) Integration:

   • Implements an open-source MCP server allowing any compliant AI agent to directly query past session states, test failures, and decision histories on demand.

4. Privacy & Local Control:

   • Fully offline and open-source, keeping project decision logs strictly within the developer's repository rather than locked inside proprietary AI platform silos.

[ismailhalawa-ctrl]

This is a really interesting approach I especially like the idea of treating project context as a local, tool-agnostic layer rather than tying it to a specific AI coding tool.

The combination of a standardized context format, session history, and MCP integration could make the context much more portable between agents I also think keeping it focused on things like changes, decisions, failures, and remaining work is more useful than simply storing entire conversations.

The ai-context/ idea is interesting too. It feels a bit like having a shared project memory layer that different agents can understand.

I'm curious — how do you currently handle this in your own workflow when switching between agents?

And one other question: how would you prevent the context from becoming too large or noisy as a project grows over time?

[Dani-8]

@ismailhalawa-ctrl Great questions! Here is how to handle both current manual workarounds and long-term context noise reduction:

1. Current Manual Workflow

Until an automated tool exists, the most reliable workaround relies on a lightweight .ai-context.md file checked into the root of the repository:

• Session Hand-off Template: Before switching agents, write a 5-line summary at the top of .ai-context.md:
  • Current Goal: What is being built right now.
  • Modified Files: List of files touched in the last session.
  • Failed Approaches: What didn't work (so the next agent doesn't retry it).
  • Next Step: The exact immediate action required.
• System Prompt Injection: Paste the contents of .ai-context.md along with git diff output directly into the prompt window of the new agent.

---

2. Preventing Context Noise & Blowup (The Sliding Window Problem)

As a project grows over weeks, sending full historical session logs will blow past token context limits and introduce "hallucination noise."

To keep the .ai-context/ protocol lean and efficient, use three core design strategies:

1. Hierarchical Memory Layers (Short-Term vs. Long-Term):

   • Active Session (Short-Term): Raw terminal outputs, recent test errors, and exact line-by-line diffs. Auto-cleared or archived upon a successful git commit.
   • Decision Log (Long-Term): High-level Architecture Decision Records (ADRs) summarized in concise markdown format (e.g., "Switched from Redis to In-Memory Map due to memory constraints on low-tier instances").

2. Commit-Triggered Auto-Compaction:

   • Whenever a Git commit occurs, run a background compaction step that compresses the detailed session log into a 3-bullet summary appended to an architectural ledger, discarding raw terminal output and intermediary diffs.

3. Vector/Semantic Search via MCP (RAG on Demand):

   • Instead of dumping the entire history into the agent's initial prompt window, expose the decision log through a local Model Context Protocol (MCP) server. The agent queries past decisions on demand (e.g., search_context("database schema decisions")) only when relevant.

[ismailhalawa-ctrl]

Thanks for taking the time to explain all of this ,I probably kept you busy with my questions
I'm genuinely interested in this problem though, so one last question: what do you think would be the hardest part of making this work reliably across different AI coding agents?

[kit1211]

Hi @ismailhalawa-ctrl

The problem you describe, context loss when switching between AI coding tools mid project, is real and underserved.

What gets lost when switching tools:
Decisions already made and why
Files touched vs planned
Failed approaches that should not be retried
Test status and known bugs
Environment and dependency state

Open source approaches that help today:

1. AGENTS.md or AI.md in repo root: machine readable project context, conventions, current sprint goals. Tools increasingly read this file.

2. Structured task tracking in repo: GitHub Issues with checklists, or docs/STATUS.md updated at end of each session.

3. Conventional commits and small PRs so git log tells the story across tools.

4. MCP servers exposing repo context to any compatible client.

5. A simple session log in docs/sessions/YYYY-MM-DD.md: what was tried, result, next step.

A dedicated open source tool could standardize a Project Context Package: git state, issue snapshot, test results, architecture decisions, exported as JSON plus markdown that any AI client imports on session start.

If you build this, focus on format interoperability over tying to one vendor. The gap is a portable context file, not another chat UI.

[ismailhalawa-ctrl]

Thanks for the detailed feedback this is really helpful.
I especially like the idea of treating it as a portable Project Context Package rather than building another AI interface.

The fact that developers are already using things like AGENTS.md, status files, session logs, GitHub Issues, and MCP separately makes me think there’s a real opportunity to bring these pieces together in a simple, tool-agnostic way.

Your point about interoperability over vendor-specific integration is especially useful, and I’ll definitely keep that in mind as I explore this further.
Really appreciate you taking the time to share this!

[kit1211]

Hi @ismailhalawa-ctrl

Hardest part of cross agent Project Context Package: schema stability, not storage.

1. Every agent reads AGENTS.md differently. Without a minimal spec (required fields, file names, version header) context silently drops
2. Session logs have no standard format. Agent A writes markdown, Agent B expects JSON. Parsing breaks
3. MCP tool lists differ per agent. Same package works in Cursor, partial in Copilot, unknown in Claude Code unless you define lowest common denominator exports
4. GitHub Issues as state store race when two agents write concurrently without locking or issue comment protocol
5. Token budget: dumping whole context package into every session burns window. Need summary layer plus drill down links

Lazy path that works today:

1. One repo, one CONTEXT.md with fixed sections: Goal, Stack, Open tasks, Last session, Do not touch
2. Agents.md points to CONTEXT.md only
3. Human updates Last session after each run until agents agree on write format

Full automation across agents is where it gets expensive. Start with readable files humans curate.

[v-ember]

Thanks for posting in the GitHub Community, @ismailhalawa-ctrl!

You are more likely to get a useful response if you are posting your question in the applicable category, the Discussions category is solely related to conversations around the GitHub product Discussions. This question should be in the Programming Help category. I've gone ahead and moved it for you. Good luck!

[ismailhalawa-ctrl]

Thanks for pointing me in the right direction and for moving the discussion! I really appreciate the guidance. I’ll make sure to use the appropriate category next time.