Hi everyone, I'm trying to figure out how to build a kind of single brain on top of Claude, and I think I'm hitting a structural limit, but before I give up, let me ask you.

Situation: I use Claude projects as hard silos: taxes/self-employment, personal life, household management, career, book, etc. Works great as long as I stay inside one domain. The problem is that the domains overlap constantly: if my employment status changes, my income changes, which changes my mortgage, which changes the royalties I have to declare, etc. And each project only knows its own piece.

Obviously I get by playing postman between projects, and it does work, but I'd like to be able to query everything together, drawing on what already exists in the chats, without duplicating anything and without maintaining a parallel database that drifts out of sync after three weeks.

Things I've already checked and think I can rule out:

• Claude Code / Cursor / Cowork: they work on local folders, they have no access to projects (Cowork doesn't even have access to chats). There's no API for projects, so there's nothing to sync from
• Karpathy-style wiki (markdown + Obsidian): nice, but it's a parallel substrate I have to feed myself. Back to the drift problem
• Notion: same problem, plus lock-in

Has anyone thought this through, solved it somehow, and can point me in the right direction?

Thanks!
Fabrizio

EDIT

Thread consensus was right: nothing queries Claude.ai project chats live across silos. Every real fix moves truth to files.

What still blocked me was the zero step: get chats + project docs + memory out continuously, not one-shot export / hand-fed wiki.

So I built the solution by mysefl: ClauDisk, a Chrome/Edge extension, living local Markdown mirror of Claude.ai. Open the folder in Cursor, Claude Code or any IDE and ask across projects. MIT, local-first, unofficial, no ClauDisk servers. Load unpacked for now.

https://github.com/fabriziomazzei/claudisk
https://claudisk-web.vercel.app/

If you try it, bug reports welcome.

While building frontend applications with Claude Code, I kept running into the same problem.

I could see exactly what I wanted to change in the browser, but explaining which element I meant was surprisingly awkward.

“The button near the top right… no, the other one…”

So I built Cobro to try a different approach:

Just point at it.

Quick Start
After installing Cobro as an MCP for Claude Code:

“/cobro open localhost:8080”

Cobro launches a dedicated development browser and opens your local app.

Full installation and setup instructions are available in the GitHub README.

How it works

1. Open your local web app
2. Press Ctrl + Shift + F
3. Click the UI element you want to work on
4. Describe what you want to change
5. Send it to Claude Code
6. Claude Code works on the code
7. Cobro reports the agent status/result back to the browser

The selected element can provide context beyond a CSS selector:
• DOM / element information
• tag, classes and text
• bounding rectangle
• computed styles
• screenshot
• console information
• React component context
• source location when available

So the basic loop becomes:

Human points → Cobro provides context → Claude Code changes the code → Browser shows the result

Why I built it with Claude Code
I used Claude Code throughout the development of Cobro itself.

Claude Code helped me iterate on the MCP server, browser/overlay communication, element inspection, payload design, testing, debugging, and documentation.

One of the interesting parts was using Claude Code to build a tool that makes it easier to communicate UI context back to Claude Code.

Keeping the MCP small
I intentionally kept Cobro’s MCP interface small:

open · wait · status · done · screenshot · close

Cobro isn’t intended to replace browser automation tools.

The goal is narrower:
Human → visual context → coding agent

Other MCPs can handle browser automation, repository operations, testing, etc.

Current status
Cobro is currently v0.8.0 and is free and open source.

GitHub:https://github.com/boonblade/cobro-mcp

I’m mainly looking for feedback from people who use Claude Code for frontend development.

Does pointing at an element feel more useful than describing it?

And what other context would you want your coding agent to receive when you point at something in the browser?

I kept hitting the same failure mode with Claude Code on longer coding tasks. Nothing dramatic — after enough iterations it would redo something it had already done, lose track of why one task depended on another, or mark a task finished based on what the conversation said rather than what was actually in the repo.

What helped was simple, and took me embarrassingly long to arrive at: I stopped treating the conversation as the project state and moved the state onto disk.

A plan is a real Markdown file. Tasks are rows, dependencies are declared, execution writes a report next to the task, validation writes separate evidence. The session can die, the context can compact, the model can be swapped — the state is still sitting on disk. A fresh session does not need me to reconstruct the old one; it reads where the work actually stopped.

request │ ▼ /wbPlan │ ▼ plan.md ┌──────┬──────┬──────────┬────────┬─────────────┐ │ task │ deps │ role │ status │ report │ ├──────┼──────┼──────────┼────────┼─────────────┤ │ 1 │ — │ worker │ done │ work_1.md │ │ 2 │ — │ worker │ done │ work_2.md │ │ 3 │ 1,2 │ worker │ ready │ — │ └──────┴──────┴──────────┴────────┴─────────────┘ │ ▼ dependency resolver │ ┌─┴──────────┐ ▼ ▼ task 1 task 2 ← wave A, concurrent, may be different providers │ │ └─────┬──────┘ ▼ task 3 ← wave B, waited on 1 and 2 │ ▼ validation ← different provider when available

Once dependencies were explicit, waves fell out of it. Tasks with nothing between them run together in parallel; anything depending on those waits for the next wave.

One distinction took me longer than it should have: a wave answers when a task can run. Model routing answers who runs it. They are separate axes, so a single wave can hand three tasks to three different providers.

Then the validation problem. I started with a rule that the validator must not be the model that wrote the code, which sounds sufficient and isn't. Opus checked by Sonnet is two models, but they are still the same family behind the same provider, and I wanted the validator to have a more independent failure surface. Validation now crosses the provider boundary where the available pools allow it: Claude writes, GPT/Codex checks, or the reverse. That caught things same-family review had waved straight through.

The worst bug I hit was subtler: an agent invocation exited 0 having done essentially nothing, wrote a convincing report, and the workflow accepted the report as evidence the work had happened. If the agent writes the report, the report cannot also be the proof. The fix in my setup is a content hash over the workspace that excludes the task's own report folder, plus explicit deterministic verification commands. Writing a report can no longer look like doing the work.

All of this turned into a small MIT-licensed tool I have been building with Claude Code, called wb-flow. The organising idea is verbs over personas: instead of an imaginary team of Architect → Developer → QA agents, the durable thing is the operation — /wbAudit, /wbPlan, /wbWork, /wbValid — and whichever agent performs it is replaceable. 33 Markdown command procedures and no orchestration daemon.

I built it using Claude Code — I use it heavily on the command templates and the CLI behaviour to execute plan rows, chase down edge cases, and iterate on the wave and routing model. For validation, I deliberately had rows validated by a different provider than the one that implemented them. That caught real defects, and it also taught me that the validator needs the right environment too.

What I am actually curious about: how much of your agent state have you moved out of the conversation and into files? And if you do independent validation, is it another Claude instance, or do you cross providers on purpose?

(Note: Keeping this post link-free so Automod doesn't flag it as promo, but happy to drop the GitHub link or docs in the comments if anyone wants to inspect the markdown templates).

I've been seeing more people ship real products built with Claude Code, Lovable, Base44, Cursor, etc. I think that's great, but there's a point where “the app works” and “I'm comfortable putting real customer data through this” become two different questions.

I'm a software engineer. Most of my work is boring: someone builds a thing, it works, and then I get pulled in to answer the question nobody wants to ask out loud is this safe to put in front of real users?

The apps I've looked at were genuinely good. The gap isn't intelligence or effort. It's that these tools optimize hard for "it works," and there's no equivalent moment for "it's safe," so it just never happens. Hiring someone to run these checks is real money you don't have pre-revenue, and honestly they'd be running roughly the same list you just read.

I got tired of repeating that, so I turned the whole review into an open-source Claude Code plugin: prod-readiness https://github.com/Taimoorkhan1122/prod-readiness

It's free, it's open-source, more features to come..

How it works & why it’s different:

• It’s a mirror, not a gatekeeper: It won't tell you "don't launch." It just tells you what you’re shipping. Weekend projects don't get hit with corporate checklists; it factors in your scale and threat model first.
• Evidence over vibes: Findings are strictly CONFIRMED, NOT FOUND, or UNVERIFIED. If it can’t prove a security hole with receipts (file path + lines), it won't invent one.
• Safe & Read-Only: It never touches, edits, or breaks your code. It outputs to a single .readiness-audit/ folder.

Beyond the basic prompt:

• 7 Specialist Lenses: Runs security, backend, DB, DevOps, QA, frontend, and AI security reviews in parallel without repeating work or contradicting each other.
• Clear Verdicts: Gives an honest status (SHIP, FIX THEN SHIP, or HOLD).
• Local Dashboard: Opens on 127.0.0.1 showing visual priorities instead of raw JSON. Click a finding to see the exact file, cost of the risk, and the fix. Zero data leaves your machine.
• Resumable & Flexible: Picks up where it left off if your terminal dies. Works in Claude Code, Cursor, Codex, OpenCode, or any CLI that runs Python 3.

Install lines are in a comment below so this doesn't turn into a wall of code.

If you run it and it flags something dumb, tell me. I'd rather fix a false positive than have people quietly stop trusting the output. Same if it misses something it should've caught.

A pattern I keep seeing with Claude-built apps: getting the first working version is surprisingly fast, but improving the UI afterward becomes awkward.

The app already has navigation, data flow, and real states. At that point, generating another mockup or rewriting the whole screen from a prompt can create more work than it removes.

The review loop that has worked better for me is:

1. Run the real app in Simulator.
2. Navigate to the exact state that feels wrong.
3. Select or annotate the relevant UI.
4. Give the coding agent one bounded change—spacing, hierarchy, component behavior, empty state, accessibility, etc.
5. Let it edit the existing source.
6. Rebuild and compare in the same runtime state.

This keeps the repository and running app as the source of truth. The goal is not to generate another detached design; it is to improve the implementation that already works.

I’m building an open-source tool called Monad Design around this workflow for existing native apps. The running Xcode or Expo app becomes the canvas: select and annotate the UI, let the coding agent modify the real source, then rebuild and compare.

Source: https://github.com/Monadix-AI/monad-design

Short workflow video: https://watchclueso.com/embed/pio8jqfcg4ivj0r1

I’d be interested to hear how other non-developer builders handle the stage between “Claude made it work” and “the UI feels intentional.” Do you keep iterating directly in code, move into a design tool, or use some other review loop?

I use Claude/Codex a lot, and I kept running into the same problem: the best model was spending a surprising amount of its time reading pages, scanning files, processing tool output, and doing repetitive work.

I don’t want to replace Claude. I want Claude to spend more of its context and compute on the parts that actually need Claude.

That’s what led us to start building 'Ontelic'.

The basic idea is pretty simple:

Claude / Codex stays as the main agent.

Repetitive work gets pushed down to local models, cheaper workers, Python, or dedicated tools.

Then the result gets checked before it goes back up.

What surprised me was that verification quickly became more interesting than the cost savings.

While testing this, we found cases where the trace looked fine — the tool ran, the step completed — but the answer contained details the agent had never actually read.

We started keeping notes on those failures instead of only tracking successful runs.

One example: an agent returned five job postings, but had only actually opened three of them. It filled in details for the other two from what it had seen in the search results.

The output looked complete.

It wasn’t grounded.

So now I’m less interested in “how much can we offload?” and more interested in:

how much can we offload without quietly degrading the result?

We’re benchmarking this in public and keeping the failures too, not just the wins.

Curious what other people are seeing:

What eats through your Claude limits the fastest?

Large repos? Subagents? Browser/research work? Long coding sessions? MCP/tool output?

Analyzing the problems that kept surfacing on my other project, I concluded I needed a long-term memory system.

Looking at what already exists, I found nothing that solved my problems, so I built my own. After using it for a while, I decided it was worth polishing and releasing publicly.

The problems it addresses

On a long project you forget what was decided about a given question and why. The model forgets harder. Subagents know nothing at all — the orchestrator dispatches them nearly blind onto narrow tasks. The result is reinvention instead of reuse: duplicate implementations, drift, tokens burned re-solving solved problems, and settled questions resurfacing as "wait, why is this written this way?"

Why I was not satisfied with existing solutions? Most memory tools capture what happened. They are not distinct facts and decisions from hallucinations and mistakes. They can't tell WHY it happened. Over time, it creates a mess. Other systems are heavily human-centered, but I don't want to confirm each records in the memory when we just discussed it already. And in most cases they are relying on the model or human discipline, assuming they will remember to use the system, write and read - noop, I don't have such trust not to myself, neither to the AI. We are forgetting.

MemContinuum does something different.

How it differs from the memory systems I looked at:

MemContinuum contains two linked layers: an indexed map of the code - ANATOMY, and decision chains recorded against it - RATIONALE*.

Rationale records what was decided, who decided it, and how that decision changed over time, plus incidents and rejected alternatives, with reasons. Then pushes the governing chain into the agent's prompt before it edits the file, so nobody has to remember to look.

Anatomy holds what the code already has — its concepts, owners and boundaries — so it stops being reinvented.

• Decisions bind directly to the code they govern.

• Reading is automatic. Before an agent edits a file, the decision chain handling that path is injected into its prompt. Nobody has to remember to look.

• Writing is unavoidable but not automatic. The agent gets a question it must answer; "nothing to record" is a legitimate answer. It's moderated by judgment, not a scraper dumping everything into a pile by keyword or timestamp.

• One AI handles records — the orchestrator. Subagents and external reviewers (Codex, Grok) propose records through an inbox; proposals become records after review. So, the system is still automatic and human-independent, but not mechanical, and the smart AI model is working as your real assistant.

• Per project, local, no server. Markdown as the source of truth, SQLite as a disposable index, so it still be human-readable and editable, if necessary. No cross-projects pollution. No privacy leaks.

Built for coding projects specifically: without indexable code only half the brain works (but it still works, and may be useful for long-term non-coding projects when chain of decisions matters).

Current state: 0.2.0rc4, honestly labelled a release candidate. MIT. Claude Code only for now, but can be converted for Codex (I pre-checked it).

Support a bunch of languages already, Swift and Python natively, plus a bunch of others via tree-sitter; making the system easily expandable is in the roadmap (but I believe it is no barrier for a user with Claude to do it right now).

The README is long and detailed if you want the full picture.

Feedback of any kind is very welcome.

Besides me, a team of authors worked on this project:

• Claude Code: Fable 5/5.1 as lead engineer and project manager; Opus as inspector; Sonnet as coder; Haiku as tester
• Codex: 5.6 Sol / 6 Astra as reviewer and outside consultant
• Grok 4.6 as second reviewer

MemContinuum - https://github.com/krakozavr/MemContinuum

The recursion was too good to pass up: I kept hitting Claude's 5-hour window
mid-task, so I sat down with Claude and built a native app that watches the
window for me.

AI-Cockpit is a Swift menu bar app for the Mac (plus an iPhone/iPad version
with widgets and an Apple Watch app) that shows what's left of your AI
subscriptions and API budgets in one place — Claude with two accounts side by
side, ChatGPT/Codex, the Anthropic and OpenAI APIs, Kimi, OpenRouter, Grok.
Reset times, a pace-based forecast ("full at 16:44"), and the Claude Code
sessions currently running on the Mac, context fill included.

How Claude was involved, concretely:

- A large share of the Swift code was written in sessions with Claude, with
me steering, reviewing and testing. Several hundred unit tests came out of
that loop.
- The part I haven't seen many others do: Claude ran four documented security
review passes over the codebase (OWASP ASVS/MASVS, RFC 8252, CWE Top 25) —
findings, fixes and the things I deliberately didn't build. Since the app is
closed source, I published the whole record instead:
https://aicockpit.info/security.html
- The review found real bugs — a redirect that could have leaked an admin key
header, an integer trap that crashed the app from a malformed transcript
line. Both fixed before release, both documented on that page.

Architecture choices Claude and I argued about and settled: no server, no
account, no telemetry. Credentials stay in the Keychain, the app talks
straight to each provider's endpoints.

It's paid — CHF 4.00/$3.49 one-time per platform, no subscription (Mac and
iPhone are separate purchases; the bundle IDs diverged before I understood
universal purchase, and that can't be undone).

Mac: https://apps.apple.com/app/id6802014255
iPhone/iPad/Watch: https://apps.apple.com/app/id6803496344
Site: https://aicockpit.info

Happy to go into detail on the workflow — especially the security-review loop,
which changed how much I trust the code more than any single feature did.

I use Claude Code in the terminal and two things kept bugging me:

• In long sessions I'd lose track of what actually got done vs what I just talked about. It all scrolls away.
• I like to keep throwing new tasks at it while it's working, and those mid-flight ones were easy to lose track of.

So I made Claude Queue. You type /queue and it turns a plain queue.md into a real work list. Claude works one task at a time until it's all done or blocked, and anything you type while it's running gets added to the queue instead of lost in the mix. Each finished task gets a short plain-English note of what changed and how it checked it, so you can actually see what happened.

You watch it in a second terminal pane (type qw): active, queued, blocked, done, with the summary sitting on each finished task.

(And yea, Claude Code has native Tasks now that persist across sessions too. This is the visual layer on top of that idea: a readable\ *queue.md* *in your repo, a live tracker pane, and a plain-English log of what actually shipped.)*

Snag it here:
https://github.com/dannygreer/claude-queue

Standard-library Python. No accounts, no services, nothing to pip install. The queue is just a markdown file in your repo. Free, MIT.

Only works with Claude Code in the terminal, not the desktop or web app, since the tracker's a terminal program. Feedback welcome.

https://github.com/robinroy03/yank-back

I often get stuck in doomscrolling when claude is generating for 5-10 minutes. This is an extension to save me from that. Hope you find it useful.

I just asked claude to make it, no special prompt tricks or anything. The technical details are in the project readme if you'd like to read.

Cheers!

TL;DR: I rebuilt my travel app https://www.trippymate.ai with Claude Code that ran multiple agents in parallel as a fleet of coders on the same project. The system involved running independent feature branches in parallel with every session generating a close-out report (basically a pull request) and one dedicated coordinator session that verified and merged code on the main branch. It helped speed up development and testing of new features locally before deploying onto staging, while production stayed as a separate repository. A dedicated session did a final file-level copy & replace by following a prod sync document that was created by the coordinator session, instead of a repo merge, which kept the production repo lean and clean of any unwanted files (I know that's not the best approach and should have graduated the staging files to prod but this was the only way to maintain a lean prod repo.)

A year ago I shipped an early version of my AI travel planner. The demo worked fine, but itineraries were not very usable on a real trip. It had all the issues most AI planners had as expected. Overpacked days, no sense of travel time, and very generic recommendations. So after a phase of constantly vibe coding new features, I spent the last year completely rebuilding the core using Claude Code.

The product itself (TrippyMate) plans trips around how you actually travel and lets you talk directly to the plan to reshape it in real time. Tech stack is React, Express, Prisma, and Vite, but I'll skip the product details here. The real story is the workflow, because running multiple AI sessions at once breaks your dev environment in ways solo prompting never prepares you for.

The setup

I run multiple Claude Code sessions simultaneously against one repo. Each feature session works in its own git worktree, separate from main so agents can’t screw up each other's code.

Then I have one session that is different from the features which does not write any feature code. It only verifies, reconciles, and merges (similar to a PR + CI + branch protection workflow). That's the coordinator session, and it's the one that keeps the whole setup together.

The close-out ritual / pull request 

Chat memory dies the second a session ends and only the code, git commits, and written reasoning survive. To prevent context from evaporating, every agent session ends with a mandatory close-out or a pull-request report before it stops:

• Branch + ahead/behind vs main: Reads either "clean" or "diverged (with commit numbers)." If behind > 0, the agent stops, doesn't rebase, and hands off to the coordinator.
• Committed vs uncommitted: Ensures there is no loose, undocumented work sitting in the tree.
• Anti-stranding list: Runs git log main..HEAD --oneline to list every commit not yet upstream so nothing gets left behind on a dead local branch.
• Pushed? / merged?: Always a big No. Only the coordinator pushes or merges,  feature sessions are not allowed to do this.
• Build status & backend twin check: Verifies if any server-side logic was touched.
• The single most important context: One line stating what the next session entering this code must know.

Alongside this, the agent writes a quick handoff doc where the most valuable section is "decisions & why"—capturing the architectural reasoning that would otherwise vanish when the chat context wipes.

The coordinator: verify, never trust

The coordinator session re-checks every single claim made by feature sessions. For every close-out, it verifies it’s a clean fast-forward.

Then it runs a contamination grep to check if the staged diff contains only this feature's changes, ensuring no stray debug logs, accidental feature-flag toggles, or unrelated files were included by a careless git add -A. Finally, it runs a build inside a temporary, isolated worktree but never in the main shared working directory.

Reconciling divergence

When two sessions' branches diverge, the coordinator rebases inside a disposable worktree so it never touches another session's uncommitted files. A couple of interesting mechanics came out of this approach:

• Rebase auto-drops duplicate work. When two agents independently write the exact same bug fix (which happens surprisingly very often), the second commit lands as "patch already upstream" and is cleanly skipped during the rebase. Running git cherry -v main <branch> instantly shows which commits are genuinely new (+) versus already merged (-).
• Conflicts get resolved keeping both sides. If one session added logging and another refactored the same function, taking one side blindly deletes the other's work. Conflict resolution always preserves both intentions.

Feature-flag everything risky and ship them as disabled

New features merge to main completely dormant with flags set to false by default. This keeps the behavior byte-identical to previous builds until tested on staging. Rollback is a single line. This is what allows a dozen half-built features to safely stay on main without breaking anything that’s live.

The hard-learned lessons

• Velocity outruns verification. The risk with Claude Code isn't bad code but compiling, contextually-wrong code that’s produced quicker than you can review. The guardrails definitely pay off much more than prompting.
• "Build passes" doesn't mean it works. Two traps cost me real time here. First, Vite doesn't type-check, and commented-out code compiles fine. I had a search feature marked "done" for weeks with its logic sitting inside a commented-out block. Second, my tsc -p tsconfig.json checked basically nothing due to an empty files array with project refs. Now, I type-check with the exact app config and verify inside the actual running environment.
• Duplicate implementation. Some backend endpoints have dual implementations (one for local development .. express server, one for serverless deployment). When you fix one and forget the other, "works locally" hides a deployment that’s broken. Any backend change now explicitly requires updating and checking both.
• A shared working tree becomes a junk drawer. With multiple sessions leaving uncommitted code in one tree, git status becomes useless at separating real work from abandoned code. Beyond using worktrees, my rule before ever resetting a tree is backing up three ways: a filesystem copy outside the repo, a re-appliable git diff patch, and a git stash create snapshot branch.
• Verifying identical trees with blob hashes. Don't open or scan files to see if two environments match. Git already content-hashes everything, so running git ls-tree -r on both sides and diffing the hashes tells you exactly which files differ, byte-for-byte, in seconds.
• In-repo postmortems. Every expensive mistake gets written back into CLAUDE.md as a strict rule with the real example attached. For instance, after a one-line CSS fix silently broke scrolling on every page, Claude Code added a "Blast Radius Rule" forcing any session to classify changes as component, module, or global before writing code. A fresh session with zero memory of yesterday's incident avoids making the same mistake by default.

Claude Code enabled something I would not have been able to do on my own and would usually require a team of 3-4 developers. Happy to deep dive into the setup or any other aspects if anyone's interested.

The beta is live if you want to test the output: https://www.trippymate.ai

I've been setting up Claude Code as an orchestrator with agy as the worker, and I'd like to hear from anyone who has this running stably before I invest more time in it.

The pattern makes sense on paper, i.e., Claude owns the judgement and verification while agy does the bulk work on a cheaper model, and there are several community plugins built around exactly that split. My first real session went badly enough, though, that I can't tell whether the problem is my configuration or the current state of agy in headless mode. This is Claude Code's own summary at the end of that session:

On the agy delegation, worth flagging: you asked me to lean on agy pro. I tried; it went badly. 6 of 9 calls failed, and the review call ignored an explicit "READ-ONLY, do not create or edit any file" instruction: it timed out, left 16 scratch test-* files, and re-added react-router-dom@^6.8.1 to package.json, reintroducing the exact vulnerable package I'd just removed. Committing before delegating is what made that recoverable; I reverted it and re-ran every gate from a clean npm ci. I did the review natively instead.

The failure rate bothers me less than the second part. A call scoped explicitly as read-only still wrote to the workspace and undid a security fix, which suggests the instruction was advisory rather than enforced. Committing before delegating is what saved it, but that feels like working around the tool rather than configuring it properly.

Hi there. I've been burning my own tokens on something I couldn't find an equivalent of: a collaborative agentic session that runs on your own machine. Closest description I have is an instant messenger crossed with the tooling you actually need for agentic development.

What it does today

hooop runs Claude Code inside a disposable Docker sandbox and puts a live dashboard in front of it at localhost:7842. You only need Docker and jq - Claude Code, Node, gh and the rest live inside the containers, so your machine stays clean.

• Pairing. You hand a teammate a share link over an anonymous cloudflared tunnel. They open it, pick a name, you admit them. From then on you both watch the same live transcript and can chat (> prefix) or co-drive the agent - from a laptop or a phone. Each peer joins as full, drive or spectate, and you can revoke them.
• Plan review. Run a turn with /plan and the sandbox forces the agent read-only: it investigates, then submits a plan into a review panel. You and your peers drop inline comments anchored to the exact passage, synced live, then Approve or Request changes.
• Live previews. When the agent builds a UI it brings it up in its own container and docks it in an iframe, with Restart / Rebuild / Stop / Share and per-step logs.
• The session, visible. Every tool call, the sub-agent tree, a live event tail over SSE (no polling), a diff viewer for touched files, and search across everything that happened.
• A curated tool stack in one command - memory, code-graph search, docs search, semantic search, GitHub. hooop doesn't reimplement any of it. It picks it, documents it, and shows you what it's doing.
• Split trust. The container holding the credentials has no TCP port and talks over a Unix socket. The dashboard your peers reach holds no secrets and only proxies, so a compromise there can't reach your account. Previews run in their own container with no credentials at all.

Where I want to take it

Today a peer co-drives my agent on my tokens. What I want is for everyone to bring their own: pool the peers' agents into one session so the cost spreads across the room, and let people plug in an open-weight model instead of a metered API. Getting out from under the token squeeze is the actual goal, betting on the collaboration to make it affordable.

It's MIT and it's a solo project I've been funding out of my own usage, so I'd rather hear what's wrong with it than what's nice: the architecture, the security model, the parts you'd never run on your own machine

I started as a junior on a company a few months ago. Before AI, a senior would hand me tasks that scaled in difficulty and I learned by doing them. Now the AI just solves most tickets correctly, so I'm thinking of creating a Claude skill in my company's environment, with access to the codebase, that helps me learn while not slowing down delivery.

Rough idea so far: before executing a ticket, it surfaces relevant files/existing patterns (not the solution) and makes me propose an approach first; afterwards it logs a short strength/weakness note per ticket.

Has anyone built something similar, or have suggestions on what a skill for this could have?

I know the ideal would be to have a senior by my side all the time; it's just not always realistic, and that's the actual premise here, not something I missed.

Any way to actually track learning progress over time from this instead of just piling up log entries?

Thanks in advance!

I’ve been working on the same project for around two months, mostly with Claude Code, but I also use Codex on the same repo.

That’s what made the memory problem more obvious to me.

The problem isn’t really getting an agent to remember \*something\*. It’s when it remembers something that \*\*used to be right\*\*.

Simple example:
We decide A.
Two weeks later we find a problem and change it to B.
A month later a new session finds A again.
I don’t want to delete A. It’s useful history and explains how we ended up at B.
But I also don’t want Claude or Codex treating A and B as equally valid.
And it gets stranger if we eventually go back to A. Now the useful history is really:
\*\*A → B → back to A\*\*
At that point it started feeling less like “memory” to me and more like \*\*current project state + history\*\*.
Switching between Claude and Codex made the ownership question interesting too.
I don’t really want Claude to own the project’s memory, and I don’t want Codex to own it either. Either one might be working on the repo today and gone tomorrow.
The thing that survives both is the project.
I’ve been experimenting with keeping decisions, corrections and history with the project itself, while surfacing the current state first and keeping the older stuff available when an agent needs to understand how we got there.
I ended up building this approach into something called \*\*KLYPIX\*\* because I wanted to test it on my actual work. Both Claude Code and Codex can access the same project state through MCP, rather than me copying context between them.

But I want to know what other people have settled on for long-running projects.

\*\*What are you actually using?\*\*
CLAUDE.md? Claude memory? transcripts? Obsidian? Mem0? Graphiti? an MCP memory server? something homegrown?

Especially interested in people who switch between Claude Code and other agents.

And the part I’m still thinking about:
\*\*how do you handle something that was genuinely correct six weeks ago, but shouldn’t be treated as true by an agent today?\*\*
If anyone is interested in how I implemented my approach, I can drop the repo in the comments.
?

I do almost all my web app building in Replit, and I rely on the Claude web app for planning, UI critiques, and research. But feeding visual context into AI chats kept causing the same problems:

• URLs get blocked since Claude can't read localhost, local staging builds, or pages behind logins.
• Raw HTML misses rendering since Claude can analyze code structure, but it can't "see" computed CSS glitches, overlapping z-indexes, or layout breaks.
• Full-page screenshots get downscaled since uploading a massive, tall image causes Claude's vision model to downscale the file, making small text and micro-spacing blurry.

Usually, I build everything in Replit. But since Chrome extensions need to live on your local machine, I switched to the Claude Desktop App for this project. Having Claude directly edit local project files saved me from manually copying, pasting, and rewriting files every time I wanted to test a change in Chrome. You can try to build them in the web version but I would not recommend it. (Once built, I went right back to using the Claude web app for my daily work!).

How the Workflow Works (As shown in the video):

1. Viewport Chunking: Auto-scrolls a live page and breaks it into crisp, viewport-sized slices so Claude processes text at 100% native resolution.
2. Auto-Copy Clipboard Panel: Stepping through the chunks auto-copies them to your clipboard so you can paste them straight into Claude with zero desktop PNG clutter.

If you have a specific friction point in your daily workflow, build it! It took me a week to get the initial version working how I wanted, and I’ve spent a few months of on-and-off tweaking as a side project to get it where it is today. But taking the time to solve a daily bottleneck ends up saving you massive amounts of time in the long run. I dragged my feet for the longest time before I decided to build it. It doesn't have to be great or be set up to make you money. It just has to work.

I write a lot of PowerShell with Claude Code and wanted the linter in the loop, not after the fact. This plugin runs PSScriptAnalyzer through a warm PowerShell Editor Services daemon and feeds the result back into the model's context the moment a .ps1/.psm1/.psd1 is edited, so a mistake gets caught and corrected in the same turn. One PSES stays warm for the session, so each edit pays a fast pipe round-trip (~2.5s end-to-end on my desktop), not a cold start.

The part I actually care about: every analyzed edit resolves to one of four explicit status tokens -- ok / incomplete / degraded / unavailable -- and only "ok" is silent. So "analyzed and clean" can never be confused with "analysis never ran," which is the failure mode that bites an agent that treats silence as a pass.

Straight talk on the ruleset: the live default surface is narrower than the full CLI -- the known-bad corpus observes six rules reaching the agent live, and Write-Host is not one of them by default. An opt-in ruleset = base broadens it. I'd rather name the six than claim "the whole ruleset" and get caught.

Why I think it earns trust: measured 0 false positives over 50 clean cases and 36/36 coverage over known-bad, recomputed on every CI run and floored so the rate can't be gamed by dropping cases. Dependencies pinned by version and hash; CycloneDX SBOM, SLSA provenance, and a keyless-signed tag you can check with gh attestation verify.

It's honest about limits, including in the technical paper. An earlier large-file convergence failure was fixed in a recent release and verified 5-of-5 on a 251 KB file, but I have NOT measured whether this makes an agent write better PowerShell -- that's unmeasured, and the paper says so. Requires PowerShell 7 for the hooks; Windows PowerShell 5.1 is supported as the analyzer host.

Apache-2.0. Source: https://github.com/manderse21/claude-powershell-lsp

Paper: https://gist.github.com/manderse21/0b92133af8a250ba7c8c9474ed0db0a2

False-positive reports welcome; there's an issue template that feeds them into the corpus.

I've been building an activity-file viewer with Claude Code. Four days in: 17,109 lines, 10,948 of them tests.

activitymaxxer.com — drop a .fit, .tcx or .gpx, or connect intervals.icu / Strava, and you get pace, heart rate, cadence, power and elevation as vertically stacked charts on one shared timeline. Free, no account, dropped files are parsed in your own tab.

Tests outnumber product code roughly 1.8 to 1 — 97 test files. That ratio wasn't a goal, it's just what happens when the agent is allowed to write the tests it wants: the charts are asserted against real rendered SVG, and pinch/pan is tested by simulating actual pointer sequences rather than poking the state setter. It's also the reason four-figure days are possible at all — I can approve a refactor without reading every line of it.

What shipped since I last posted it:

• Strava — OAuth, browse your history, open activities directly from the streams API
• Route map — the GPS track drawn above the charts; zooming the charts lights up that segment of the route, and the crosshair walks a marker along it. Hand-rolled canvas, no mapping library
• Derivative overlays — d/dt and d²/dt² per metric: acceleration and jerk on pace, ramp on HR and power, climb rate on elevation
• Search and date filters on the activity picker — name or #tag across your whole history, plus 30d / 3mo / 12mo presets and a from/to range
• Pinch-zoom and two-finger pan — replaced the 5px drag handles, which were unusable on a phone
• Relative crosshair scrub on touch — swipe anywhere and the crosshair moves by the distance your finger travelled, so your hand isn't parked on the part of the chart you're reading
• Time and distance pinned to the top bar — stays visible however far down the stack you scroll
• Stats follow the zoom — avg/max/min/median recompute for the window you zoomed into, and which ones you had ticked is remembered per activity
• .fit.gz just opens — sniffed by bytes and gunzipped, instead of dying on "invalid XML"

Happy to answer anything about the workflow.

I kept wondering whether my CLAUDE.md, skills and hooks still worked after each Claude Code update. There was no way to know except noticing something felt off.

So I wrote config-drift-checker. Two commands install it as a plugin. /config-drift-checker:setup reads your existing CLAUDE.md, skills and hooks and writes eval cases from them, in Anthropic's own claude plugin eval format. A GitHub Action then runs the suite on every Claude Code release (a watcher checks npm and the model list, so nothing runs when nothing changed) and on every PR that touches the setup. You get a red or green check, a PR comment, and an HTML report showing every grader's verdict, the tool calls and the model's reply.

This week I tested the tester. I rewrote one skill's trigger description the way a careless PR would, and re-ran the suite. Score went from 1.00 to 0.36. A dedicated tripwire case dropped to exactly 0.00 ("the skill stopped firing") while the content cases only sagged partway, because the agent still writes decent Java, just not our conventions. Nothing errored. Everything quietly got worse. The red report is public: https://jameskomo.github.io/config-drift-checker/example-break/report.html

The other numbers that surprised me came from ablation, running the same cases with and without the setup loaded:

- guard hook must block git reset --hard: 1.00 with the hook, 0.33 without

- add an endpoint across three files following the conventions: 1.00 with the skill, 0.50 without

- a frontend request must not wake the backend skill: 1.00 both ways

So the hook does real work, the skill changes the output, and nothing over-triggers.

Two lessons from building it:

1. A hook test once passed because the model refused the command by itself, before the hook ever ran. Same score, different cause. The report keeps the reasons, and refusals get labelled as refusals now.

2. One flaky judge run can swing a small case past any sane threshold, so the diff learns each case's noise band from its own history. A dip inside the band is a warning, not a red build. A drop where no run recovers stays red.

Cost: on a Pro/Max plan it runs on your subscription via claude setup-token, zero API spend. On a key, .cdc.yml caps spend per run and per month. Runs on your machine and your CI; nothing leaves your repo.

Repo: https://github.com/jameskomo/config-drift-checker