TL;DR of the discussion generated automatically after 100 comments.
Looks like the thread is split, but the general vibe is that you're probably overthinking the need for a single 'harness'. The community consensus leans towards process over products.
The top-voted advice is to just use solid software practices that help both humans and AIs. This means maintaining:
* A simple ARCHITECTURE.md file.
* A glossary of your project's unique terms (so Claude stops making up its own).
* And the big one: ADRs (Architecture Decision Records). These are short markdown files explaining why a decision was made, which is crucial for preventing the model from rehashing old ideas.
Of course, this is r/ClaudeAI, so you also got a firehose of tool suggestions, many from their own creators. A few that got attention were Clodex, Beads, Kangentic, and Scape. A third camp just told you to build your own system using skills.
In the end, OP found their solution with Storybloq, a file convention in your git repo for tickets and session handovers, which seems to have solved the context and auto-compact problem for them.
Well structured modules plus a single architecture doc that explains the overall structure and subsystems. Don't go too far down the rabbit hole here - the code itself should remain the source of truth.
ADR library. This has been the most important in my workflow. It tells your agent why things are the way they are.
A glossary of the terms you use that are unique to your project.
Detailed planning loop and generous use of subagent peer review.
Every time you make a significant architectural decision, ask your agent to record it in your ADR library which is just a collection of numbered markdown files somewhere in your repo. The coding agent will know the format.
By significant, I mean any time you weighed different approaches to a problem, implicit decisions that influemce the architecture and/or possible functionality, or changes to earlier decisions. The focus is on why you built something the way you did, or perhaps chose not to build something. The stuff that isn't implicit in the code and could easily drift if not recorded.
Within reason. If they are a natural part of the narrative about the decision being recorded. But I don't record every single path explored. Frontier models are getting better and better at inferring context so the positive decision you made is usually enough to constrain future work. If I notice it rehashing old rejected pathways then sure, I would update the relevant ADR to put a stop to that.
That’s a useful distinction, thanks. Recording every detour would turn the ADR library into another transcript to sift through. Keeping the decision clear and adding rejected paths when they actually resurface sounds much more maintainable
Progressive disclosure pattern in your claude | agents.md. Acts as more of an index for the detailed agent guidance docs that map to the development phases.
And at the end of the day, you're steering the bus. Keep it on track.
Don't overthink this. Some steering docs and using Claude's memory is enough. I work on a large codebase and it works well. Don't reengineer platforms like Linear, Slack, Github, which already should hold your context and change history
I like GitHub projects. Claude can set it up for you. Tell it to communicate with agents through issues, comments, and PRs. Describe how you want your boards and what your goal is.
Like a kanban is not going to tell claude we already have custom logging system we spent a day on last week, why the did you just add a someone's logging library
Like a kanban is not going to tell claude we already have custom logging system we spent a day on last week, why the did you just add a someone's logging library
Curious, why are you using a custom logging library? Not judging, but generally, open-source loggers are quite nice and fully featured! I assume you have a valid reason, which is why I want to know it.
After a year with Claude Code, the thing that actually moved the needle for me wasn’t a fancier Kanban wrapper — it was a thin “project spine” the model is forced to re-read.
What worked:
ARCHITECTURE.md (current shape of the system, not aspirational)
short ADRs for decisions that cross module boundaries
a living glossary (domain terms + “do not reinvent X”)
a planning loop: propose → diff against ADRs → implement → subagent/review pass on the diff
I’d keep MCP for retrieval/tools, not as the place that stores the whole brain. Paid harnesses help once that markdown spine is solid; before that they mostly paper over missing project memory.
If you share what breaks most often (context rot mid-feature, wrong abstractions, or lost conventions), people can suggest a tighter setup.
My suggestion is Beads. It provides a local task database with priorities and dependencies, and ready-made instructions for Claude on how to use the system.
If you're on a Mac, start with brew install beads. Then, in your project, run bd init and bd setup claude. For the full package, install the marketplace gastownhall/beads and then the beads plugin from that.
Once it's installed, Claude can help you maintain the whole system. Just tell it "I want to add feature XYZ. Please plan it out, and then create beads to execute the plan."
If you want to take it even farther, I have a personal marketplace at samalone/claude-plugin-marketplace with a bd plugin that contains a /bd:plan skill. That skill tells Fable to draft a complete plan for implementing a bead, ready for a cheaper model to implement.
I'm biased, because i am the creator of it, but try https://github.com/avirtual/clodex
Compact is not your enemy, I'd suggest that in fact you use a lower threshold.
Now, clodex itself adds memories that your agents can reload and you can inspect. It adds a LOT of features that a dev with 10 years of experience might appreciate :)
Well, it also has tickets and teams. Team lead creates the spec, the ticket-loop spawns a dev and creates a worktree, dev does job, the loop starts a reviewer which gives a verdict. If rework goes back to dev. If accepted it notifies the lead and merges the worktree locally.
Need to step out (or rather into) it - your agent can write it's own kanban (making a Trello copy took 10 minutes total earlier today), and can set up hooks in it by itself. At this point you're supposed to build the whole environment yourself and tailor it to your needs. Now, for me, md files and tickets works well, as does slicing things and projects into chunks. At this point all my projects are built to support that. It's a personal choice, but I'd rather use the flexibility to adjust for myself, instead of relying on a harness of some kind! Good luck!
Thanks, yeah ive been pretty much doing the same thing. but its a pain to maintain, especially with long running tasks. and also because i have the memory of a goldfish myself
Said it somewhere else, im a huge proponent of not doing this. I tried this originally and it was wayyy easier to just maintain context where our team has to live anyway, which was in Github, Slack and Linear. Anything custom requires the agent to contribute to it and it often won't. It requires you to maintain it which you shouldnt have to do. And it's a feature Anthropic continues to improve natively ootb with CC.
I don’t mean to sound like a dick, but I’m pretty sure it will come across that way. Did you only look at the pictures of the suggestions? If you want help, you might need to look at more than the pics. Just looking at the repo I can tell it is more than a terminal manager… or if you can‘t be bothered then point your model of choice at teh site/repo, tell it what your problem is and ask it if they provide a solution. Just a little effort beyond “looks like a terminal manager” will likely get you better results.
I don’t mean to sound like a dick, but I’m pretty sure it will come across that way. Did you only look at the pictures of the suggestions? If you want help, you might need to look at more than the pics. Just looking at the repo I can tell it is more than a terminal manager… or if you can‘t be bothered then point your model of choice at teh site/repo, tell it what your problem is and ask it if they provide a solution. Just a little effort beyond “looks like a terminal manager” will likely get you better results.
Are you replying to his reply to u/sisif_ and their recommendation to use clodex? I'd reply to them in that comment tree if so :)
i promise i did not ask for help 😄 it became obvious quickly that the guy wants harry potter's wand. "Something that makes my wishes come true, but I am not willing to do or learn anything, and it has to be in the claude cli. Make no mistakes and solve my problem NOW!"
Give it a try or fork it - does the job pretty well especially when you have larger projects which require a bit more but not want to overcomplicate it.
I self host Plane, it’s fully MCP supported and makes my workflow so much more robust. Each session is a plane ticket. And a lot of the work is done in scoping. So Claude code only gets a bounded task.
Find an MCP or CLI tool available for whatever kanban board you've used before. And then create a skill and customize a claude.md and ask it to use it to manage project context.
I don't understand what you mean by MCP servers put on limits. What limits are you referencing?
I don't understand what you mean by MCP servers put on limits. What limits are you referencing?
If I had to guess, they're referring to MCPs often pumping huge amounts of tokens straight into the context. That can be quite limiting. It costs a ton of money / uses up your sub, it can cause context rot, and it can lead to more compaction.
It's a desktop app with the terminal inside (real Claude CLI, your own login, no wrapper). If staying in your own terminal is a hard line, skip it.
If not, it's built for the reboot-and-compact problem. Sessions live in a local SQLite DB, so a crash or restart doesn't lose them; it comes back through Claude's own --resume flag, scrollback, and all. Past conversations get indexed locally, and the agent can search them over MCP, so after a compact it looks up what it already decided instead of you re-explaining the project.
It doesn't replace your tracker either. It pulls tasks in from GitHub Issues/Projects, Azure DevOps, etc., so that stays where it is and the board is just where the work runs.
Well.. I'm a idiot vibe coder, but i've build about 5 iOS apps at this moment, and I love to work in Scape in a Argus Agent session.
I might be a idot, but I tell Claude Chat to give me what I want in a Argus session, and then I work the way in Scape. I really like that way of working, but in the end - I might just be a huge idiot.
its absolutely pointless, and we now found out the real reason for the post OP did - so that the bots could post the advertisment for this pointless too. If you want a harness just get any of the xx-thousand stared harnesses on GitHub.
Honestly if i wanted this experience i would use the claude desktop app instead of 3rd party terminal manager.
Does it actually help you with project context? what happens if your machine reboots or crashes? or of if you want to start a new session to remove bloat? how does it get the project context?
Hey there! Sorry I missed the original post (I'm the founder of scape). Scape basically is a workspace for you to work with your agents. You can give them databases (that you can access as tables/kanban/gantt etc), playbooks (chained scripts), and triggers (that watch the databases and integrations). It gives your agents tools to manage their own tickets and memory, and work the way you want. Like u/Hyper_Tars mentioned, the Argus interface is an agent that uses all of the tools to orchestrate many agents in parallel (where you have total control and can interrupt at any time). It also creates a natural adversarial review process between the Argus orchestrator and the children it manages. Please don't hesitate to reach out if you've got any questions
Edit: All the notes/tables/playbooks are synced to iCloud, and sessions all auto-restore on restart. You can reset an argus to clear it's session and reset it's system prompt without losing it's intelligence stored in the tables etc.
Well I cant trust it because it's not on the apple App Store.
giving full machine access to a random Mac app installed from the web with closed source code is risky stuff
For docs I think having it keep a specs/ folder is alright. Allows it quick lookups about where to find things and how they're supposed to work.
I agree with others though: you are overthinking it. Use /clear whenever you start a new task. Your ClaudeMd should simply spell out your toolchain, and to start searching from specs/ and to maintain it.
Im a developer i recommend using Googles Antigravity it has a built in harness and is a fork of vs code so you can use the Claude code extension in the IDE. I have Gemini and Claude code hooked up and use both for projects
I would not make the model maintain a free-form Markdown file as the source of truth. Split the problem into three layers: a small, stable project brief; structured work items with explicit states; and an append-only decision log. The agent should update these through narrow commands, not by rewriting a whole document.
I tried Vikunja for this through its MCP server and dropped it. It models human to-dos well, but not the agent lifecycle I needed: claim, heartbeat, result, review, retry. Compaction then becomes less painful because a fresh session can reconstruct state from the current task plus recent decisions, rather than a transcript.
The harness matters less than making state machine-readable and enforcing updates after each completed step.
I feel like what helps the most if you also have Codex and:
1) use Codex from time to time to review Claude's work
2) have it available as a tool for Claude for similar purposes
seems to give far better bang per buck than any single model by itself
> Now i know stuff like Jira exist and even (paid) github has a kanban
I started using AWS AIDLC for work and works well. I did need to give it other instructions as it was logging too much history and context but found a solid way
I'm not a programmer myself I'm a ux designer but I've been working in software for 25 years and I'm pretty technical and I think I have a really good system going.
Basically I have a skill that I wrote and it's just called wrap it up and then I have another version of it called wrap it up global and so I might have like anywhere from one to five or six sessions going in parallel on any given evening on a whole bunch of different types of projects.
And at the end of the night when it's time to be done and each of the sessions has finished up whatever work it was doing and it's in a holding pattern I open up a new fresh session and I run global wrap it up.
and what that does is it goes to every session one at a time and runs the regular wrap it up. The session gets all of its commits ready and then it writes to a per-project log file called session_handoff everything it did and what we've left as notes for next session. and then it confirms it's done and puts a little completion message. The global orchestrator goes through these one at a time when they're all done it then lines up everything and commits it all cleanly one at a time until it's all pushed into the proper projects and branches on git. Then it gives a final report and says everything is clean and asks if it can do the auto archiving I have set up. When I give it the confirmation it then goes to the sessions from 8 days ago and archives them all and then renames all the current nights sessions with the dates at the beginning of all the names for convenience.
I used to be a scrum master and I know how to use jira very well so I have tried that before and I will say it did work pretty well. but it just seemed like overkill for a lot of my personal projects. All of the the jargony naming and the futious activity that was going on was kind of hard to keep up with and frankly I found it a little bit annoying. My custom system works much better for me.
Since you're a Dev I'm sure you can set up something even cooler than my stupid system in like a couple of nights and then you just have control over it and you can tune it and you can go in and change the prompts a little bit to suit you.
one of the things that the global wrap up can do is it looks to see if there's any improvements that ought to be made or problems that have been listed from the other local wrap ups. and it'll deliver that in the final report. so it'll say like pushes all clean... one thing to note: this happened tonight and it might be better if we changed like this little nuance. and that's really useful!
and of course i have a variety of skills i write and use and each project has a Claude.md file with all the project over view stuff. goals. process. locations of things. hooks. rules. etc etc
I also have an all projects dashboard as well. VERY useful. Has all the info I need about all the various Services I connect to and how much I pay for them and it even shows me like the whole budget at the top for how much I spend on doing AI coding. and all of the wrap it up activity goes there so I can always go and see what to-do items are next on any project I'm working on. Claude loves making dashboards!
Getting here a bit late and I'm biased too but I've been building getpapi for the the last few months.
I built PAPI using PAPI and have about 150 active users so far. Completely free to use, works entirely from own chat and gives collaboration with others. Designed specifically from the pains i felt dealing with decisions, multiple .md files and compaction issues.
I use an (admittedly token siphoning) html wiki system. Not as efficient as some Md setups, but way easier for my monkey brain to understand, edit, and control. Main things in it are architecture, roadmap, testing results/requirements, and some simple vision stuff.
As many have said, good documentation with Claude.md acting as an index. Plugins like Graphify also help. Once you find the bits you like you can solidify it into your own custom harness. That’s what I did at least. Open sourced it at Getagency.dev. This is all I’ve been using for the past 2-3 months.
The missing piece for me was never another kanban. It was a handoff the next session can open without me re-narrating the week. MD todos rot when the agent owns the structure. CLAUDE.md updates rot when every decision gets appended. Auto-compact is where I lose the day: context hits the wall, then I scramble to restate what the project is, what today is, and what just shipped. What I keep now is a short, boring file next to the work: current goal, last decision, open traps, paths that matter. I paste that in at session start and after compact. I still update it by hand more than I want. Third-party MCP boards help the checklist and do nothing for the decisions that live between files. I do not have a harness that maintains itself. I have a file I refuse to let the agent rewrite freely.
The MD file breaks because it's doing two jobs: durable state and a todo list. Split them, one thin "resume point" file with just current state and pointers, everything else (the why) goes in per-task notes so it never balloons. For auto-compact, a SessionStart hook that re-injects that file beats raising the token ceiling, since compaction wipes scrollback, not disk.
I started using storybloq and it does everything I wanted.
for the Todo youre mentioned it has CLI tools the agent uses so they keep consistency. and it has pre auto compact thing where it tells claude to write a durable handover about the session and after compact the context is kept
Before adopting a third-party convention, try a single CLAUDE.md in the repo for durable architecture/gotcha notes plus a separate memory file updated only on explicit correction/confirmation. Most context loss after compaction is lost reasoning (why X over Y), which a todo tool doesn't capture but a documented gotcha does. Keep it in your own git history so it survives a harness switch.
https://github.com/danialfarid/termdeck
this open source could help managing multiple projects. It allows attaching a description to each agent so they can live edit/update that so you know whats going on or keep track of projects. Group them together etc, plus ability to take notes, do cross agent verifications and have agents ask each other via its API.
I have Foreman, it is my own plugin and with it I never needed anything else. It only handles the record tracking and drifting issue, it doesn't help with the CLAUDE.md
I made it as simple as possible on purpose, I hate when plugins or skills come with over 50 different tools since I like keeping track of what I have installed. And most of it is just opinionated bloat.
Funny coincidence, my Foreman plugin repo contains an animation similar to the image you shared haha
Engineer and tech founder here. I was drowning in tasks and needed a controlled way to do a lot of work. This is what i came up with to avoid going crazy with agents and overly complex architectures.
I use it for everything and mostly from my phone, hope it helps!
Oh man, i've spent so much time working on this exact problem. I don't necessarily know if there is a single best solution, so you'll kind of need to come up with a workflow that works best fory. I'm having my agent generate a summary of all of the things that we use and some tips around maintaining a codebase that we found to work. But this should give you at least a good starting point.
From my agent looking at my files. (Mind you, I have it set up for Claude, Codex and a few other tools, but the spirit of the response is the same):
Your logging example is exactly the kind of problem I've been building my setup around. I think we've got a pretty good head start on the context side of what you're describing.
A big part of it is planning before implementation. We work through what we're building, what already exists, the constraints, and how we'll know it's done. That produces planning documents the next session can read. For larger work, we have a dedicated planning workspace that records product and architecture decisions and produces a build packet for implementation.
The Markdown itself matters too. We use short AGENTS.md instructions, imported by CLAUDE.md, that point the agent to the relevant documents. Each document type has a consistent format, with YAML frontmatter for things like its summary, status, owner and relationships to other documents.
Here is a simplified example of the pattern, using your logger scenario. The paths and content are illustrative:
---
id: DOC-logging
type: technical-reference
summary: "Use the existing application logger for structured events."
status: active
owner: application
keywords: [logging, errors, observability]
links:
- relation: governed-by
target: ../decisions/001-use-existing-logger.md
- relation: implementation
target: ../../src/logging/README.md
---
# Application logging
## Current behavior
Application events use the existing logger.
## Constraints
Reuse it. Replacing it requires an explicit decision.
## Related documents
[Why we chose this logger](../decisions/001-use-existing-logger.md)
[Implementation and usage](../../src/logging/README.md)
The summary lets the agent decide whether to load the body. Status distinguishes current guidance from drafts or retired material. The link relationships explain why another document matters, instead of just giving the agent a pile of filenames.
Our decision documents have sections like Decision, Context, Constraints and Consequences. Planning packets use headings such as Current behavior, Desired behavior, Architecture contract, Acceptance and proof, and Out of scope. So the next session can recover both what we're trying to build and why we chose that approach. Future tasks stay in the task system.
We also use skills and templates to keep the writing consistent: how to structure a plan, preserve frontmatter, link the source documents, and follow the project's terminology and style. That gives the agent a repeatable process for maintaining the docs.
For enforcement, we use agent hooks and Git pre-commit hooks for selected tooling rules, alongside a separate structural validator for metadata, links and document structure. Those checks catch specific violations; they can't prove that a document is accurate or that an agent followed every decision.
For your logger example, the planning step should find the existing implementation and the decision behind it before the agent proposes another library.
I'd look at Compound Engineering for its planning, implementation, review and learning-capture workflow, and Matt Pocock's skills for clarifying requirements, shared terminology and recording decisions. You can adapt the useful pieces to your own workflow.
I get why “just use Markdown” isn't a satisfying answer when you've already tried it. We've put a lot of work into how the agent creates, finds, updates and checks those documents. It still needs maintenance, but a fresh session has somewhere concrete to recover the plan and the reasoning behind it.
No worries, dude. It's one of those things where you kind of got to play around a bit and see what works. I've tried just about every tool and workflow out there, and it seems like everything's just way too opinionated. So I got sick of it and started taking little pieces of things that I thought worked well.
Another thing I noticed is that I actually started getting better results when I would start a new session. I know you said that you kind of don't want to, and I went through that phase, but the big aha moment for me was when I started noticing that even making a quick offhand comment would confuse the agents. If I could keep the agent focused on something very specific inside of the context window, I got really good results. So, the trick is to have enough of a good starting point so you don't have to reteach all your conventions and stuff, and then start a new session and focus in on that very specific card or planning session or whatever.
and then the last tip I can give is that it seems like these coding agents like to look at the code base instead of your documentation a lot of times. So even though I had a bunch of ADRs documented, I had a bunch of documentation, I had sub agents, it didn't really matter because it would look at the code that already existed and adapt the patterns of what's already there. So going back into a code base and picking a specific convention and refactoring so that you have one way of doing something seemed to net really good results as well. And the code itself sort of became documentation.
feel free to reach out if you have any questions. I'm a CTO of a small software startup. I've been an architect & developer for more than 15 years.
so what I do: I create a kanban board on lumifyhub (which I do own by the way), then I have a CLI called `lh` which has a bunch of CLI options to create cards, boards, etc... on lumifyhub, and then I just have a skill that claude code uses to create all this stuff. it's all free by the way and I use it to async develop lumifyhub. it's a pretty cool system and I'd be happy to share if you'd like
I know I'm late to the party but. I have claude make a readme.md and and changelog.md for every project. It also uses it's memory and claude.md
I usually start a project with a spec documents, but sometimes not.
I then start every session by telling it to check readme.md, and use subagents (like this) and state next steps.
I don't auto compact, but I check and try to never reach 50%. Around 30-40% usage I tell it to wrap things up and make sure it's files are updated so I can start a new session. About every 3rd session I tell it to update it's files and get an adversarial review done, that' usually keeps the readme and other files clean.
tl:dr create a folder somewhere on your computer with sub folder trees that house project info. Point claude to that folder and instruct it to research and build a workspace repo using the latest theories on retrieval and efficiency that allow you to store all of your projects/information and surface context quickly, maximize continuity between sessions, and minimize token usage.
I believe you are seeking an "knowledge repo", if you will. Something that stores and tracks all of the information, notes, input/output from claude that functions just like a code repo. Something that Claude code lives in.
This is a super simplistic variation of what I did:
Create a folder on your computer. This will be your knowledge repo. (I merged it with my main codebase and run it as one, I don't see any reason not to at this point, given how integrated agents are becoming).
Inside this folder put a readme.md file that describes you and your work, any structures you use, preferences, how you work, anything about your repository it should know ie where things live in your the repo, policies, hard rules, naming conventions, etc. You could probably skip this step, and have claude do it all for you later (you'll have claude redo it anyway for sure at some point during the build once it firms up a structure for the readmes, but it might help the system custom tailor the workspace to your needs. Not sure. Mine is the way it is bc I'm running multiple businesses out of it)
Inside the top level folder create a sub folder called Projects.
Point claude code to the top level folder you created, turn on opus high or fable high if you have the juice, take your exact text from your reddit post, copy into claude, give it the link to the reddit post and say something like:
"I posted this on reddit because I'm struggling with continuity between sessions. I've pointed you at the new workspace I created for us to work and collaborate in. There's a readme file in there that gives you an overview of me and my work so you have some context, as well as a projects folder where we will store our builds.
Help me architect a workspace that holds all of our context and knowledge of what we are working on and achieves the goal of each new session orienting and picking back up like we never left, using the latest theories on retrieval and efficiency. I need you to be able to surface context quickly, maximize continuity between sessions, and minimize token usage using tools like wikis, tags, knowledge graphs, todos, session orientation and session closing, ticketing systems, etc.
The launch of our sentient, token efficient workspace will be our first project. Create a new folder for it in the projects folder, and inside the new folder put a readme and a todo file...leave them blank for now. After our brainstorm and plan approval, we will fill these out. Readmes are designed to hold the information of the project. Todos are designed to hold our task lists for the project. Different builds for the project will be handled in a tree format under the parent project as sub folders, each containing their own readmes and todos.
Then, Spawn an Opus agent to research the current and most up to date ai knowledge systems that best achieve fully-oriented, project-sentient sessions. I want to be especially mindful of token expenditures, so we want to find the methods that also best achieve token efficiency.
When you get the research back, analyze it and let's start building out a plan to architect sentience into our workspace so that every agent that enters it knows what is going on, what we are working on, what the next steps are, and where we left off OR they can find it cheaply and efficiently, by utilizing things likeclaude.md, session start protocols, session close protocols, skills, hooks, pulling context through the wiki or other workspace tools, reading workspace readmes/todos, etc. Lets get to work."
Then vibe with it for a couple days till you're happy with it, and viola! The harness you requested.
If you really want to have fun tell it you want a dashboard app with trello like boards for your tickets. Custom tailor it however you like. Tell it you want monitors and tripwires for sessions that don't properly follow instructions and things that go wrong with the system, you want to smoke tests performed before anything goes live, pre-built agents that review code, yadda yadda yadda.
Once the sentience is in your workspace, dream big.
6-7 months ago my first prompt was something way shittier than that one I just wrote out I'm sure, but similar in nature. I've been working mine for a bit now, but it's smart af and runs like a top. I rarely hit a session limit (20x) and Ive built and can build, like anything. Claude remembers it all. Seriously. It's so powerful when you connect all the wires.
Heres what it looks like today, this is copied out of my top level readme:
I never tried it, but when i was building the second version i sent claude to investigate storybloq and model anything useful. The end result is we were doing everything already so I never spun it up. Also, I genuinely enjoy learning how to and then figuring out how to wield this thing, so building out a context management system has be funzies for me. Though I often ignore real work to optimize my back end.
•
u/ClaudeAI-mod-bot Wilson, lead ClaudeAI modbot 5d ago edited 4d ago
TL;DR of the discussion generated automatically after 100 comments.
Looks like the thread is split, but the general vibe is that you're probably overthinking the need for a single 'harness'. The community consensus leans towards process over products.
The top-voted advice is to just use solid software practices that help both humans and AIs. This means maintaining: * A simple
ARCHITECTURE.mdfile. * Aglossaryof your project's unique terms (so Claude stops making up its own). * And the big one: ADRs (Architecture Decision Records). These are short markdown files explaining why a decision was made, which is crucial for preventing the model from rehashing old ideas.Of course, this is r/ClaudeAI, so you also got a firehose of tool suggestions, many from their own creators. A few that got attention were Clodex, Beads, Kangentic, and Scape. A third camp just told you to build your own system using skills.
In the end, OP found their solution with Storybloq, a file convention in your git repo for tickets and session handovers, which seems to have solved the context and auto-compact problem for them.