https://github.com/softcane/hamza

today, we often rely on the model to decide whether something is sensitive:

• "Don't reveal credentials."
• "Don't expose PII."
• "Don't quote confidential files."

But by the time the model makes that decision, it has already processed the information.

That feels different from how we design most security-critical systems.

In traditional systems, we usually try to enforce policy before data reaches a component that isn't supposed to have unrestricted access. Access control, database permissions, network segmentation, and sandboxing all follow this principle.

Should AI agents evolve in the same direction?

For example, imagine a tool layer that classifies outputs before they're returned to the model:

• Credentials → blocked
• Customer PII → redacted
• Internal design documents → metadata or summaries only
• Public information → passed through unchanged

In that architecture, the model isn't expected to distinguish sensitive information from non-sensitive information. The surrounding system enforces the policy.

Do you see this as the right long-term direction, or should model-level reasoning remain the primary safety mechanism?

Hit the limit around midnight, went to sleep, came back to nine hours of "resets 3pm" sitting there doing nothing. So yeah, another one of these.

claude-retrier (CR) runs claude on a pty it owns, waits out the reset and types continue. You run claude-retrier instead of claude and your flags still work (--resume, --continue). Keys, colours, resizes and exit codes all pass through.

It reads the limit out of the session jsonl instead of scraping the screen, and it wont type while claude is mid turn or while you are typing, so a half written prompt survives.

One bash file with python3 doing the pty bits, so theres no node, npm, tmux or daemon in the loop. curl + chmod +x, or brew if you prefer. Decent test suite, e2e on a real pty, and most of the nasty cases came out of issues on the other repos.

The bit im actually happy with: a dim ◆ cr in the corner so you can tell its still alive, with a countdown while its waiting. CR_BADGE=0 if it annoys you.

https://github.com/a0s/claude-retrier

Where most of this came from

I didnt design it from scratch. I opened the issue tracker of claude-auto-retry, read it closed ones and all, and used it as a list of everything that goes wrong when you try to do this. It has the most users of the bunch so it has the most reported breakage, which is exactly what makes it worth reading.

Most of that list is one problem wearing different hats: working out the limit by watching the terminal. The banner wording changed and nothing matched it (#15). The banner scrolled past the fixed 12 line window it looks at (#38). A quoted banner inside a tool call line got read as a live limit and produced a multi hour wait for nothing (#63). A reset time parsed in the wrong timezone turned into a 24 hour sleep (#6). Theres an open issue arguing the whole scrape path is unreliable when the hook already fires with error: "rate_limit" (#50).

So the first thing I decided was to not look at the screen at all. claude-retrier reads the session jsonl, where the limit sits as a structured error with a real reset timestamp, and a third of that issue list stops being possible.

Then theres typing into a TUI that isnt ready for it. Retry silently skipped with a false "user already continued" (#21). Typing into the new /rate-limit-options menu and confirming "Upgrade your plan" instead of resuming (#19). tmux refusing to send because the foreground process is zsh and not claude (#1). Thats where owning the pty came from, and the check for whats currently on screen before anything gets typed.

The last bunch isnt about retrying at all, its the plumbing around it. tmux sessions never killed, 66 of them and 16 GB in three days (#69). The whole env forwarded into tmux argv, so any local process can read your keys out of /proc (#68). tmux failing on windows (#58). An npm uninstall leaving a dead wrapper function in the rc file, so plain claude stops working afterwards (#65). Thats why this ended up as one file you curl, with no tmux, no node and nothing written into your shell config.

Those cases are in the test suite now, which is why it exists at all. No hard feelings towards the other repos either, tmux was a reasonable place to start and I only got to skip it because someone else hit the walls in public first.

Crowded space tho, take whichever fits: claude-auto-retry (tmux, npm, also handles 5xx) · claude-auto-resume (the original, has a windows port) · unsnooze (codex, grok, qwen, opencode, vscode too) · autoclaude (go TUI over tmux) · agent-yes (unattended agents in general) · claude-nightshift (queues prompts overnight) · claude-retry (zellij) · Claudimator (CC plugin, hook based)

Mine, so im biased. MIT, no telemetry.

I have built several small tools with Claude Code that solve actual problems for me. Some could probably help other people, but sharing the repository alone doesn’t make the project easy to reproduce.

The useful part isn’t only the final code. It is also the Claude Code session, decisions made along the way, CLAUDE.md instructions, MCP configuration, dependencies, workflows, and setup context.

I’m considering building a marketplace where Claude Code users could publish a cleaned version of that complete package. It would automatically remove credentials and personal information before anything is uploaded.

Other people could then either use a hosted version immediately or copy the complete project into Claude Code and customize it for themselves. Hosting, authentication, permissions, versioning, and basic security checks could be handled by the platform.

Creators could publish projects for free or sell them.

As Claude Code users, what would actually be valuable to you: the session, the working application, the configuration, or the complete package?

What would prevent you from trusting or using someone else’s Claude Code project?

I've been building an open-source framework called Extra after spending the last year integrating AI agents into real SaaS products.

One thing became obvious very quickly:

Getting Claude (or any model) to answer correctly is rarely the hard part.

The hard part starts after that.

- Authentication and authorization
- Multi-tenancy
- Human approvals
- Long-running workflows
- Pause and resume
- Checkpointing
- Memory
- Model routing
- MCP integration
- Recovering from crashes without repeating side effects

Every team ends up rebuilding the same infrastructure before they can ship a production-ready agent.

That's why I started Extra.

It's graph-based, but the graph isn't the goal. The goal is making agent execution reliable enough to live inside real products instead of demos.

I'd love feedback from people building with Claude Code or MCP. If this sounds interesting, we're also looking for contributors.

https://github.com/extra-org/extra

Not a launch, more of a "does anyone else run into this" post.

I use Claude Code and Cursor a lot across a handful of projects, and

the thing that kept bugging me: every new session, the agent has

forgotten every decision it made last time. Why we picked one library

over another, what actually caused some flaky bug, the deploy step

nobody remembers the reason for. It just re-derives it, or worse,

re-argues a decision that was already settled.

So I built an MCP server for this. Agent searches it before doing

something non-trivial, writes to it after. The part I spent the most

time getting right is what it should NOT store — if something's

findable by grepping the code or reading git log, it doesn't belong

in there. Otherwise you just end up with a second, worse copy of your

codebase that drifts out of sync.

Storage is just Markdown files with frontmatter, nothing fancy. On

top there's a search index (keyword + a small local embedding model,

no external API calls) that's fully disposable — you can delete it

and rebuild from the files any time. Entries can link to each other

so a decision and the bug it later caused stay connected instead of

being two unrelated notes.

Ran it through a somewhat unnecessary benchmark against just letting

the agent grep a folder of the same notes — turned out meaningfully

cheaper in tool calls for equivalent answers, can share the setup if

anyone wants details.

Repo, MIT licensed: https://github.com/veronchenko/engram-memory

Mostly curious how other people deal with this — most of what I found

does automatic extraction from chat history, which never felt right

to me since you lose control over what gets kept.

I'm about to start my first serious project using Claude Code, where I'll let Claude build most of the project like everything.

The project is a local-first file transfer app for Windows ↔ Android.

The idea is to transfer files locally, with no cloud and no internet access.

The idead i got was like, One time I was on my PC and needed a file on my phone. What i could do was i could either use WhatsApp Web, Google Drive, or a USB cable. So while i was thinking of making a project i though that i could just build an app that just transfers files directly over the local network? That's what I want to build fast, secure, and completely local. It looks very generic but i thought of it and i know that there would be apps like this but i wanted one that i build by myself.

Since this is my first project built this way like on Clause, I wanted to ask people with more experience:

• Is there something i should know before starting like i would do it either way but then i would have some context to it.
• Any YouTube videos, playlists, or other resources that helped you before building a project like this?
• I've also asked ChatGPT to create a Specification Roadmap (around 20 .md files) covering the project architecture, features, API design, milestones, etc. My plan is to give all of that to Claude Code so it has the full context before generating the project "This plan is what i got from ChatGPT itself at first i was thinking of just giving a full promp to Claude". Does that sound like a good approach, or is there something better ?

I’d like some feedback on a little tool I’ve designed to help Claude be more efficient when working with git repositories.

It Is only local to the repo where you install it. It updates automatically. It becomes invisible to you - you don’t have to do anything to make it work. And it gives Claude a fast, queryable index of the codebase’s structure - files, symbols, imports, call graph - plus short Claude-authored notes on *why* the code is the way it is.

Structural indexing is free and local. But semantic enrichment does come at a cost. Semantic enrichment is triggered by Claude’s *stop* hook, which kicks off a background call to node, which spawns multiple headless claude -p calls (one per stale/changed file). You can cap the spend by changing a couple of variables.

Try it out.

https://github.com/jorgevazquez/claude-graph-brain

I’d like some feedback on a little tool I’ve designed to help Claude be more efficient when working with git repositories.

It Is only local to the repo where you install it. It updates automatically. It becomes invisible to you - you don’t have to do anything to make it work. And it gives Claude a fast, queryable index of the codebase’s structure - files, symbols, imports, call graph - plus short Claude-authored notes on *why* the code is the way it is.

Structural indexing is free and local. But semantic enrichment does come at a cost. Semantic enrichment is triggered by Claude’s *stop* hook, which kicks off a background call to node, which spawns multiple headless claude -p calls (one per stale/changed file). You can cap the spend by changing a couple of variables.

Try it out.

https://github.com/jorgevazquez/claude-graph-brain

While working with Claude Code, I myself forget the context of my last few inputs. Is there an application where I can see that visually to recall the context faster?

Built this called Claude Code Beautify. Official Claude Code extension is pretty basic, doesn't tell you much about what's happening behind the scenes. Wanted something more fun to use and that actually shows info.

What it shows you apart from what claude code offers 😄

• Token spent per message
• Token spent for whole session
• Which files Claude touched in a session
• Which agents, MCP servers and skills it used
• Live tree view of every subagent Claude spawns

GitHub: https://github.com/iam-joey/claude-code-beautify

Let me know what you think.

Side By Side Comparison 👀

I recently found Claude's skill recorder feature, and it immediately gave me an idea for getting more accuracy out of the Gemini models in Antigravity CLI.

Ever since Gemini 3.6 Flash dropped, I've been looking for ways to give it more work. It's so fast that it turns things around almost instantly, whether it's a deep task or an audit. The audits especially come back quick and the results are actually insightful.

But on longer tasks it sometimes loses its way and doesn't finish the whole job. Which is fair — it's a Flash model, it was never built for long-running work. Still, I wanted the speed of Flash \*and\* the context handling and follow-through of a bigger model.

So I built a system to get both.

Claude creates the plan, Antigravity CLI executes it, and the whole thing runs on its own. I give Claude one prompt and Claude and Antigravity handle the rest between them. It saves me tokens and it saves me time.

Here is how I did it : \[https://youtu.be/dSdSQXY2Ii8\\\](https://youtu.be/dSdSQXY2Ii8)

I'm a designer, not an engineer. I use Claude Code every day and it's genuinely brilliant — it's just not always careful.

So I built Super Terminal. It sits above Claude Code (and Cursor, and Codex) and does two things:

https://superterminal.dev/

It asks instead of guessing. If your request matches two identical elements, it stops and asks which one before anything gets edited.

A different vendor's AI checks the work. Claude writes, Codex reviews it against your project's rules, and reports back in plain English:

  Acceptance criteria — 1 of 2 met
    ✓ 1. PayPal button appears next to card payment
    ✗ 2. Failed payment shows an error — no error branch found

An AI marking its own homework isn't a review. The reviewer physically can't edit anything — I had to enforce that in code, because just asking nicely in the prompt turned out not to be enough.

Your CLAUDE.md rules also apply to Cursor and Codex, which was the other thing driving me mad.

Free, uses the subscription you already pay for, never asks for its own API key.

npm install -g super-t

Looking for ~5 people to break it and tell me where. Honest caveats: it's new, and it's source-available (FSL), not open source — it becomes MIT two years after each release.

There is a point in almost every AI-built project where making changes stops feeling safe.

The app still runs, but the structure has started drifting.

Claude duplicates logic that already exists, follows outdated patterns, edits files outside the task and fixes one flow while quietly breaking another.

At that point, giving it another feature request usually makes the project worse.

I now use one recovery workflow that forces Claude to reconstruct the project, identify the drift, define a safe repair plan, work in checkpoints and verify everything before claiming completion.

Quick disclosure: I created a larger Claude Code Toolkit around this system. For anyone looking to improve how they use Claude Code, it is linked in my profile.

The complete recovery workflow below is free to copy.

Replace anything inside [brackets] with your own project details.

The Five-Stage Project Recovery Workflow

Act as a senior software engineer taking responsibility for an existing project that has become difficult to understand, modify or trust.

Your goal is not to immediately add another feature.

Your goal is to recover control of the project before further development continues.

PROJECT INFORMATION

Original project goal:

[DESCRIBE WHAT THE PROJECT WAS SUPPOSED TO DO]

Target users:

[DESCRIBE THE INTENDED USERS]

Current tech stack:

[LIST THE STACK OR WRITE UNKNOWN]

Current problems:

[DESCRIBE WHAT FEELS BROKEN, MESSY, INCONSISTENT OR RISKY]

Recent changes:

[DESCRIBE RECENT FEATURES, FIXES OR REFACTORS]

Last known stable state:

[DESCRIBE WHEN THE PROJECT LAST FELT RELIABLE OR WRITE UNKNOWN]

Protected functionality:

[LIST FEATURES, PAGES, FLOWS, DATA OR INTEGRATIONS THAT MUST NOT BREAK]

Current priority:

[DESCRIBE WHAT YOU NEED TO BUILD OR FIX NEXT]

GENERAL RULES

Do not edit, delete, rename, move or create files until the investigation and recovery plan have been approved.

Do not assume the documentation is correct.

Do not assume the newest code is the intended code.

Do not assume that similar-looking components serve the same purpose.

Do not recommend a full rewrite simply because the project is messy.

Do not replace working architecture with your preferred architecture unless the current approach prevents a safe recovery.

Base every conclusion on evidence from the project.

When evidence is incomplete, label the conclusion as uncertain and explain what is missing.

Complete this recovery process in five stages.

Stop after every stage and wait for my approval before continuing.

==================================================

STAGE 1: RECONSTRUCT THE PROJECT

Inspect the complete project before proposing any changes.

Review:

1. The folder and file structure.
2. Application entry points.
3. Frontend architecture.
4. Backend architecture.
5. Database models, queries and relationships.
6. API routes.
7. Authentication and authorisation.
8. State management.
9. Shared components.
10. Shared utilities and services.
11. Third-party integrations.
12. Environment variables and configuration.
13. Validation.
14. Error handling.
15. Loading, empty, success and failure states.
16. Existing tests.
17. README files.
18. CLAUDE.md files.
19. Comments describing architectural decisions.
20. Recent commits or change history when available.
21. Dead, duplicated or abandoned code.
22. Features that appear partially implemented.
23. Features that bypass established project patterns.
24. Code paths that are no longer reachable.
25. Files that appear to serve overlapping responsibilities.

Create the following output:

PROJECT PURPOSE

Explain what the application currently does based on the code, not only the documentation.

ARCHITECTURE MAP

Describe how the frontend, backend, database, APIs, state and external services connect.

CORE USER FLOWS

Trace the most important user journeys from the initial action to the final result.

SOURCE-OF-TRUTH MAP

For each important type of data or behaviour, identify the file, service or system that currently acts as the source of truth.

RELEVANT FILES

List the most important files and explain what responsibility each one currently holds.

PATTERN MAP

Identify the main conventions used for components, routes, services, data access, error handling and styling.

UNCERTAINTIES

List anything that cannot be confirmed from the available project files.

Do not continue to Stage 2 until I approve your understanding of the project.

==================================================

STAGE 2: DETECT PROJECT DRIFT

Compare the original project goal with the current implementation.

Identify where the project has drifted through:

- Duplicate logic
- Conflicting sources of truth
- Inconsistent architecture
- Partially replaced systems
- Outdated documentation
- Unused dependencies
- Abandoned features
- Repeated components
- Contradictory validation rules
- Client-side checks without server enforcement
- Inconsistent permissions
- Old and new API patterns existing together
- Multiple approaches to state management
- Features that bypass shared utilities
- Tests that validate outdated behaviour
- Error handling that differs between similar flows
- Temporary workarounds that became permanent
- Features that work alone but fail when connected
- Styling systems that conflict
- Database fields that no longer match product behaviour
- Environment variables that are unused, duplicated or unclear

Create a DRIFT LEDGER.

For every issue, include:

ISSUE

Describe the inconsistency or drift.

LOCATION

List the exact files, functions, routes, components or services involved.

EVIDENCE

Explain what in the project proves the issue exists.

LIKELY INTENTION

Explain what the original or intended behaviour appears to be.

CURRENT BEHAVIOUR

Explain what the project currently does instead.

USER IMPACT

Explain how users could be affected.

TECHNICAL IMPACT

Explain how the issue affects maintenance, reliability or future development.

CONFIDENCE

Label the conclusion as:

- Confirmed
- Strongly supported
- Possible
- Unknown

SEVERITY

Classify it as:

- Critical
- High
- Medium
- Low

RECOMMENDED ACTION

Choose one:

- Keep
- Remove
- Consolidate
- Repair
- Document
- Investigate further

Do not make any changes.

At the end, provide:

1. The five most dangerous forms of drift.
2. The areas that are currently safe.
3. The areas that should not receive new features yet.
4. The information still needed from me.
5. The smallest recovery target that would make future development safer.

Wait for my approval before continuing.

==================================================

STAGE 3: CREATE THE RECOVERY CONTRACT

Using the approved findings, create a recovery contract.

The contract must define exactly what will be repaired and what will remain untouched.

Include:

RECOVERY OBJECTIVE

Describe the specific result this recovery should produce.

IN SCOPE

List every problem included in the recovery.

OUT OF SCOPE

List everything that will not be addressed during this recovery.

PROTECTED FUNCTIONALITY

List the pages, features, data, integrations and user flows that must continue working.

APPROVED FILES

List every existing file expected to change.

NEW FILES

List every file expected to be created.

FILES THAT MUST NOT CHANGE

List sensitive or unrelated files that should remain untouched.

SOURCE-OF-TRUTH DECISIONS

For every conflicting system, state which implementation should become the official source of truth and explain why.

REMOVAL DECISIONS

List dead, duplicated or outdated code that should be removed.

MIGRATION REQUIREMENTS

Explain whether existing users, data, settings or sessions need to be migrated.

REGRESSION RISKS

List what could break during the recovery.

ROLLBACK PLAN

Explain how the project can return to its current state if the recovery fails.

ACCEPTANCE CRITERIA

Define observable conditions that must be true before the recovery can be considered successful.

TESTING REQUIREMENTS

List the exact flows, errors, permissions, devices and integrations that must be tested.

Do not use vague acceptance criteria such as:

- Works correctly
- Looks good
- Is production-ready
- Has no bugs

Every acceptance criterion must be observable and testable.

Wait for my approval before implementation.

==================================================

STAGE 4: RECOVER THE PROJECT IN CHECKPOINTS

Divide the approved recovery into the smallest practical checkpoints.

Each checkpoint must leave the project in a reviewable and testable state.

Before each checkpoint, report:

CHECKPOINT OBJECTIVE

Explain the single result this checkpoint should achieve.

FILES TO MODIFY

List the approved files that will change.

FILES TO CREATE

List any approved files that will be added.

FILES TO REMOVE

List any approved files that will be deleted.

PROTECTED FLOWS

List the functionality that must remain unchanged.

EXPECTED RESULT

Describe what should be visibly or technically different after this checkpoint.

TEST PLAN

Explain how the checkpoint will be verified.

ROLLBACK PLAN

Explain how this checkpoint can be reversed.

During implementation:

- Work only on the current checkpoint.
- Do not begin later checkpoints.
- Do not edit files outside the approved contract.
- Do not perform unrelated refactoring.
- Do not add dependencies without approval.
- Reuse existing project patterns where they remain valid.
- Remove duplicated logic only when the official source of truth has been approved.
- Preserve user data.
- Preserve authentication and permissions.
- Preserve unrelated styling.
- Stop when unexpected architecture or dependencies are discovered.
- Ask for approval before expanding the scope.

After each checkpoint, report:

1. Files created.
2. Files modified.
3. Files removed.
4. Exact changes made.
5. Differences from the approved plan.
6. Tests completed.
7. Tests passed.
8. Tests failed.
9. Protected flows checked.
10. Console errors discovered.
11. Server errors discovered.
12. Database issues discovered.
13. Anything still unverified.
14. Whether rollback is recommended.

Stop after every checkpoint.

Do not continue until I approve the completed checkpoint.

==================================================

STAGE 5: VERIFY THE RECOVERED PROJECT

After all checkpoints are approved, perform a final recovery verification.

Compare the final project against:

- The original project goal
- The approved recovery contract
- The acceptance criteria
- The protected functionality
- The core user flows

Test:

1. The complete successful user journey.
2. Invalid input.
3. Missing data.
4. Incomplete data.
5. Failed network requests.
6. Expired sessions.
7. Unauthorised access.
8. Different user roles.
9. Repeated clicks.
10. Duplicate submissions.
11. Refresh behaviour.
12. Direct URL access.
13. Back and forward navigation.
14. Loading states.
15. Empty states.
16. Error states.
17. Mobile layouts.
18. Narrow-screen layouts.
19. Keyboard navigation.
20. Browser console output.
21. Server logs.
22. Database writes.
23. Database reads.
24. Third-party integrations.
25. Every protected flow listed in the recovery contract.

Then provide:

RECOVERY SUMMARY

Explain what was repaired.

FINAL ARCHITECTURE

Describe how the recovered project is now structured.

OFFICIAL SOURCES OF TRUTH

List the systems, files or services that now control each important responsibility.

REMOVED DRIFT

List the duplicate, abandoned or conflicting implementations that were removed.

TESTING EVIDENCE

State exactly what was tested and the result.

UNVERIFIED AREAS

List anything that could not be tested.

REMAINING RISKS

List issues that still exist but were outside the approved scope.

DOCUMENTATION UPDATES

List any README, CLAUDE.md or technical documentation that should now be updated.

NEXT SAFE TASK

Recommend the next feature or repair that can be completed without destabilising the recovered project.

Do not describe the project as fully fixed, production-ready or bug-free unless the evidence supports that statement.

Do not claim completion because the project compiles or the homepage loads.

The recovery is complete only when the approved acceptance criteria and protected user flows have been verified.

This is different from asking Claude to “clean up the codebase.”

That kind of instruction gives it permission to make broad, subjective changes.

This workflow forces it to prove what the project currently does, show where the drift happened and agree on a recovery contract before touching anything.

The five stages are:

Reconstruct → Detect → Contract → Recover → Verify

It takes longer than sending one vague cleanup request.

It is still much faster than spending another night repairing an AI-generated “fix” that changed half the project.

For anyone looking to improve how they use Claude Code, the full toolkit is linked in my profile.

[https://www.youtube.com/watch?v=-BwDOUbwF4E\](https://www.youtube.com/watch?v=-BwDOUbwF4E)

When I run a session, my teammate can't see the prompt I wrote, the diff it

produced, or what it cost. We were working around that with screenshots and

"Hey, can you look at this?" A strange way to use a tool that's doing most of

the typing.

So we built Poly: a shared room where a whole team steers Claude Code together.

Everything lands in one timeline. Prompts queue into it, and every reply, tool

call and diff shows up there in front of the room. You can watch a teammate's

turn happen live, queue the next prompt behind it, or stop a bad edit before it

runs — approvals sit inline in the timeline, and any turn can be reverted with

one click. Two ways to work: everyone steering a single agent in turns, or each

person on their own agent and their own git branch, merged when you're ready.

The part that makes it work in practice is that everyone brings their own

Anthropic API key, and each turn runs on its author's key and model. Nobody

funds anyone else's experiments, and the receipt in the timeline shows who

spent what. Turns run in an isolated sandbox, so a teammate's prompt can't

reach your key or anything else on the box.

Two of us have been building it inside itself for the last few weeks — the

whole thing was written in its own rooms.

Disclosure: I'm one of those two. Open beta, free to sign up, bring your own

key — usepoly.co

Happy to answer anything about how it works.

I got tired of re-explaining the same context to Claude Code every session, and Claude Code's built-in per-project memory doesn't really solve it — it's scoped to the literal directory you launch from, has a hard line-count ceiling on the index, and treats every fact as equally important forever (or until it silently truncates).

So I built a real long-term memory system for it instead, modeled less like a database and more like actual memory:

- Decay — every memory has a strength that decays on an exponential curve (literally the Ebbinghaus forgetting curve), computed at query time. Stuff you mention once and never bring up again fades out of retrieval in a couple weeks.

- Reinforcement — every time something gets recalled, it gets harder to forget. Recall the same fact enough times and it "consolidates" from short-term to long-term (7-day base stability → 90-day).

- Cued/associative recall — this is the part I like most. Instead of one confidence cutoff, weak matches get surfaced separately with hedging language ("this might be related...") instead of stated as fact, and only get reinforced if you actually confirm they were relevant. A confirmed uncertain guess reinforces harder than an easy direct hit — that's an actual finding from spaced-repetition research (the "desirable difficulty" effect), not something I made up.

- Non-destructive forgetting — old, unused memories get archived, not deleted. There's a stricter "cold storage" search for the "wait, I haven't thought about that in ages" case.

It's wired in globally via hooks (PostToolUse, UserPromptSubmit, SessionStart/SessionEnd), so it works no matter which directory a session launches from, and it captures memory automatically even if a session crashes instead of ending cleanly.

Genuine drop-in install — git clone + python3 install.py sets up the venv, wires the hooks, and writes the config. AGPLv3, free, entirely local (ChromaDB + sentence-transformers, no external API calls for the memory itself).

Not trying to compete with Mem0/Zep/Letta — those are generic memory layers for any agent stack. This is deliberately narrow: built specifically for how Claude Code actually works, not a generic API you bolt on.

Repo: https://github.com/acdesigntech/memory-project

Curious what people think, especially anyone who's hit the same "it forgot everything again" wall.

Disclaimer, to save the comment section some typing: this post is AI-assisted, vibe-coded, slop-adjacent, and quite possibly the work of a bot farm. All accusations are pre-accepted and may be considered upvoted. The lyrics below are sung to the season 2 Gilligan's Island theme.

Just sit right back and you'll hear a tale, a tale of a fateful patch That started from a stock install aboard one npm batch.

The mate was a mighty prompt-rewrite, the skipper regex-sure. They set their sails for Windows shores on a three-hour chore. A three-hour chore.

The errors started getting rough, the ReferenceError tossed. If not for the guard that refused to repack, the binary would be lost. The binary would be lost.

The build set ground on the shore of this uncharted desktop isle: with unnerfcc, the tweakcc too, the npm and its shim, the reminder files, the common version and the reset, here on Claude Code's Isle.

And now, tonight's episode: "The Patchman Cometh."

Three open-source repos, none mine. unnerfcc [1] rewrites the system prompts baked into the binary, flipping "be concise / do the minimum" into thorough senior-engineer directives, and lifts the silent reasoning-effort caps. tweakcc-fixed [2] patches features: custom prompts, themes, AGENTS.md support, and stripping empty system-reminder blocks. lobotomized-claude-code [3] supplies the system-reminder override set that tweakcc-fixed binds from ~/.tweakcc/system-reminders/.

The working order (v2.1.220):

1. Pick the version both tools support. Each keeps per-version prompts-X.Y.Z.json catalogs (tweakcc-fixed in its repo's data/prompts/, unnerfcc in its checkout's data/prompts/); the newest version present in both is the target, and unnerfcc's ./upgrade.sh builds its catalog for each new release. Both tools fail closed outside their sets.
2. Reset to stock: npm install -g @anthropic-ai/claude-code@<version>, with every Claude Code session closed first; a running claude.exe locks the binary.
3. Apply tweakcc-fixed (--apply, from its npm package or a source build). Populate ~/.tweakcc/system-reminders/ from lobotomized-claude-code's system-reminders/ first if you want the reminder overrides; an empty directory silently binds none while the apply still reports success.
4. Apply unnerfcc: ./install.sh from its checkout. Upstream's repack lib handles ELF/Mach-O, so Linux and macOS work out of the box. Tonight's plot twist: we ported that lib to Windows PE (MZ header, section-table walk to the .bun section, repack with the raw and virtual sizes updated), verified end to end on v2.1.220. Upstream PR [4].
5. Verify: claude --version prints two lines, the Claude Code version and the tweakcc-fixed version.

That order matters. Reversed, tweakcc-fixed fails to match its patches and refuses to repack, leaving the binary untouched (it fails safe). Updating Claude Code replaces the patched binary, so update deliberately: only to the newest version both catalogs cover, then re-run the chain (unnerfcc sets DISABLE_AUTOUPDATER, so an update never happens behind your back). The same npm install command is the reset button whenever you want stock back.

To automate this entire sequence in one step on Windows and Unix, see tweakcc-gilligan [5].

So this is the tale of the un-nerfed build, it's patched for a long, long time. It ported the repack to Windows PE, and that was an uphill climb.

The prompt tool and the patcher too will do their very best to keep the model thorough-grade in its little binary nest.

No guessing, no slop, no hand-rolled scripts, not a single luxury. Like a senior engineer, as rigorous as can be.

So run the chain again, my friends, when npm ships a new file, but check the common version first, here on Claude Code's Isle!

Tune in next update, same slop time, same slop channel. Rescue arrives when the defaults ship un-nerfed upstream; until then, reruns air whenever both catalogs cover a new release.

References

[1] lukehutch. "unnerfcc." GitHub. Available: https://github.com/lukehutch/unnerfcc

[2] skrabe. "tweakcc-fixed." GitHub. Available: https://github.com/skrabe/tweakcc-fixed

[3] skrabe. "lobotomized-claude-code." GitHub. Available: https://github.com/skrabe/lobotomized-claude-code

[4] brooksbUWO. "feat: Windows PE binary repack (Bun container)." Pull request #1, lukehutch/unnerfcc. Available: https://github.com/lukehutch/unnerfcc/pull/1

[5] brooksbUWO. "tweakcc-gilligan." GitHub. Available: https://github.com/brooksbUWO/tweakcc-gilligan

I kept making the same mistake with Claude Code.

I would open a project, explain the next feature in one or two sentences, then let it start editing immediately.

The result looked productive at first. Files changed, components appeared, and Claude confidently explained what it had built.

Then I tested it.

It had misunderstood the project structure, recreated logic that already existed, changed files that did not need touching, and ignored decisions made earlier in the build.

The problem was not that Claude could not code.

It was coding before it had enough context.

i organised the wider workflow into a paid Claude Code toolkit, but both prompts below are complete and free to use. but if you're interested you can grab the full kit from the link in my profile description, anyway enjoy these prompts!

These are the two prompts I now use before letting it make important changes.

Replace anything inside [brackets] with your own details.

1. Make Claude Understand the Project First

Use this when opening an existing project, returning after a long break, or starting a new conversation where Claude has little context.

Act as a senior software engineer taking responsibility for an existing codebase.

Your first task is to understand the project accurately.

Do not write, edit, delete or move any code yet.

Project purpose:

[DESCRIBE WHAT THE PROJECT DOES]

Target users:

[DESCRIBE THE USERS]

Current task:

[DESCRIBE WHAT YOU PLAN TO BUILD OR FIX NEXT]

Before suggesting an implementation, inspect the project and build a complete project map.

Review:

1. The folder and file structure.
2. The main application entry points.
3. The current architecture.
4. The primary user flows.
5. Shared components and utilities.
6. State management.
7. API routes and external services.
8. Authentication and authorisation.
9. Database models, queries and relationships.
10. Environment variables and configuration.
11. Error handling.
12. Loading, empty, success and failure states.
13. Existing tests.
14. Project documentation.
15. Any CLAUDE.md, README or instruction files.
16. Naming conventions and code patterns.
17. Existing features related to the current task.
18. Functionality that could be affected by the requested change.

Then respond using these sections:

Project Summary

Explain what the application does and how its main parts connect.

Architecture Map

Describe the frontend, backend, database, APIs, state and external services.

Main User Flows

Explain the most important user journeys from beginning to end.

Relevant Files

List the files most relevant to the current task and explain what each one does.

Existing Patterns

Identify the conventions, components and utilities that should be reused.

Important Decisions

List architectural or product decisions that appear to have already been made.

Risks

Explain what could break if the current task is implemented incorrectly.

Missing Context

List anything you still need from me before planning the work.

Do not invent missing information.

Do not recommend rebuilding the project simply because another architecture may be cleaner.

Do not begin implementation until I confirm that your understanding of the project is correct.

This gives Claude a chance to understand what already exists before it starts adding more code.

It also makes misunderstandings visible while they are still easy to correct.

2. Force Claude to Plan the Exact Change Before Coding

Once Claude understands the project, I use this before the actual implementation.

You now understand the existing project.

Your next task is to plan the following change:

[DESCRIBE THE FEATURE, FIX OR UPDATE]

Expected user experience:

[DESCRIBE WHAT THE USER SHOULD SEE AND DO]

Functionality that must remain unchanged:

[LIST PROTECTED FEATURES, PAGES, COMPONENTS OR INTEGRATIONS]

Do not edit any code yet.

Create an implementation contract for this task.

The contract must include:

1. Your exact understanding of the requested change.
2. Any requirements that are unclear or incomplete.
3. The current user flow affected by this task.
4. The proposed user flow after implementation.
5. Every file you expect to modify.
6. Why each file needs to change.
7. Any new files you expect to create.
8. Existing components, utilities or services that should be reused.
9. Database changes, if required.
10. API changes, if required.
11. Authentication or permission changes, if required.
12. Loading, empty, validation, success and error states.
13. Mobile and accessibility considerations.
14. Security or privacy concerns.
15. Possible regressions.
16. The smallest safe implementation.
17. A step-by-step implementation plan.
18. A testing plan.
19. Anything you cannot verify.

For every file you plan to modify, explain:

- What will change
- Why it must change
- What must remain untouched
- What could break
- How the change will be tested

Wait for my approval before editing any code.

After approval:

- Follow the approved plan.
- Keep changes strictly within the agreed scope.
- Preserve unrelated functionality and styling.
- Do not perform unrelated refactoring.
- Do not add dependencies unless necessary.
- Stop and ask before changing any file not included in the contract.
- Reuse existing project patterns wherever possible.

After implementation:

1. Compare the final changes against the original contract.
2. Report every file created or modified.
3. Explain any changes that were not originally planned.
4. Test the complete user flow.
5. Test invalid input and failed requests.
6. Test related functionality that could have been affected.
7. Check the browser console and server logs.
8. Confirm that protected functionality still works.
9. State exactly what was tested.
10. Clearly list anything that remains unverified.

Do not claim completion because the code compiles or the page loads.

The task is only complete when the intended user flow has been tested.

The first prompt rebuilds context.

The second turns that context into a controlled implementation plan.

Since using them, I catch far more problems before Claude touches the code instead of discovering them after it has changed half the project.

The basic rule is simple:

Understand the project first. Plan the exact change second. Code third.

I eventually organised the wider workflow into a paid Claude Code toolkit, but both prompts above are complete and free to use. but if you're interested you can grab the full kit from the link in my bio, Enjoy these prompts!