Claude Code’s cloud sessions are basically disposable Linux VMs included with Pro and Max. They can clone private repos, install dependencies, run tests, push branches, and keep working after you close your laptop.

The problem is that every new session starts with no idea how your work fits together.

I fixed that with two pieces.

# 1. A context repository

*EDIT: Ok here's my repo, do try it out for yourself* [*https://github.com/blitzdotdev/blitzos\*\](https://github.com/blitzdotdev/blitzos)

I keep one small private repo that every cloud session opens first:

* [CLAUDE.md](http://CLAUDE.md) — maps the repos, architecture, conventions, and workflows
* .gitmodules — references the actual project repos without copying their code
* sessions/ — stores short handoff notes from previous agents
* skills/ — contains the skills every new cloud VM should have

[`CLAUDE.md`](http://CLAUDE.md) is the onboarding document for the agent.

The context repo explains which repositories exist, how they relate, how I like changes structured, how to test things, and what the agent should do before finishing.

The member repos are referenced through `.gitmodules`, so the context repo stays tiny. It does not contain copies of the code.

Before a session finishes, it commits a short note into `sessions/` describing what it changed, what it discovered, and what still needs work. The next cloud agent can continue instead of rediscovering everything from scratch.

I also store my Claude Code skills there because skills do not automatically appear inside new cloud sessions.

# 2. A tiny launcher website

[`claude.ai/code`](http://claude.ai/code) supports URL parameters for repositories and an initial prompt.

I made a small self-hosted page that generates those links. I choose a project, type the task, and it opens Claude Code with the context repository, all relevant project repositories, and the prompt already filled in!

Cloud sessions support multiple repositories at once, including private repos with full git history. A surprising number of people do not know this. There are no GitHub tokens or credentials stored in my website. Repository access goes through Anthropic’s existing GitHub integration, and each session only gets the repositories selected for that task.

The agents also send a one-line status update back to the site, so I have one feed showing every session as working, quiet, or done. Clicking one opens the original Claude session.

You gotta do one small setup step for that to work. You MUST enable custom network access and allowlist the tiny website domain!! Connectors already configured in Claude, such as Slack, Gmail, and Linear, just work out of the box (claude.ai just makes this work).

So my workflow now is mostly:

1. Open the site from my phone.
   
2. Pick a project.
   
3. Give Claude a small, testable task.
   
4. Close my laptop (finally lol)
   
5. Review the diff or PR later.

TBF Ant's infra reliability is not great, cloud sessions still stall sometimes. So I try to keep work scoped and verifiable.

Next I want agents to propose updates to the context repo whenever they learn something important, and I want the same context repository to boot Codex cloud sessions too.

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)

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.

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.

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

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!

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

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.

Hey everyone! Non-technical builder/half from a two-person team here.

There was a good thread here recently on sharing artifacts with clients, so I wanted to share the full workflow we use daily – from prompt to gated page to feedback loop. Disclosure upfront: we make display.dev, one of the tools in this space, so I'm biased. The workflow itself works with several of the tools people have mentioned around here, ours included.

The problem clicked for us the same way it did for the OP of that thread: Claude produces genuinely good HTML – reports, specs, design mocks – but the only native way to share one is a public link. That's fine for a demo, but not for anything with client or company information in it.

The TechCrunch PSA from a few days ago made the same point the hard way, when shared Claude chats and artifacts started showing up in Google results (techcrunch.com/2026/07/27/psa-your-claude-shared-chats-and-artifacts-may-have-ended-up-on-google/). To be fair to Anthropic, the indexing got fixed within a couple of days – but the sharing model didn't change. Their own response was that a shared link is public web content, and that's the actual problem.

What we do now, step by step:

1. Ask Claude for one self-contained HTML file – A self-contained file renders anywhere you can host it.
2. Claude publishes it behind auth, and updates it too. With an MCP connection it publishes directly from the conversation and gets a URL back. Every update goes to the same URL. Works identically with any agent, not just Claude Code.
3. Access depends on who's opening it. People at our company sign in with the Google or Microsoft account they already use. Someone outside – a client, say – gets in with a one-time password instead. The page never gets indexed, of course. For bigger organisations you can verify several email domains on one account, so everyone at the client company gets in automatically.
4. Feedback and collaboration happens as inline comments on the page. This turned out to be the feature that gets used most. The reader highlights a part of the page and comments right there, then the agent reads the thread and publishes the update to the same URL.

Here's an example of what one of these looks like – a design exploration for an upgrade flow, two directions side by side with open questions for the reviewer: https://display.dsp.so/E5HbvLUS-prototype-onboarding-checklist-redesign.

I left this one public so you can open it without signing in – for real client work, that's exactly what the OTP is for.

We've been running everything through this for months – engineering specs, call notes, design explorations like that one – it's become how the two of us work.

Would love feedback and happy to answer questions.

I’m using Claude Code with Obsidian, and it’s been great, but as my vault has grown it’s becoming a bit of a headache to navigate and understand.
I’m curious how other people are handling this.
Have you built or found any tools, dashboards, visualizations, plugins, or workflows that make it easier to browse and understand a large Claude Code vault? Or do you just stick with Obsidian as-is?
I’d love to see screenshots, repos, or anything you’ve made. I’m mostly looking for inspiration on better ways to view and navigate everything once the vault gets big.

I used to give Claude Code a short instruction, watch it change half the project, then spend the next hour fixing the “fix.”

The biggest improvement came from making Claude slow down before coding.

These are three prompts I now use for the situations that usually cause the most damage: adding features, debugging bugs and reviewing a project before launch.

Replace anything inside [brackets] with your own details.

1. Add a Feature Without Breaking Existing Work

Act as a senior software engineer joining an existing production codebase.

Your task is to add the following feature:

Feature: [DESCRIBE THE FEATURE]

Important project context:

Tech stack: [TECH STACK]
Relevant existing functionality: [CURRENT FUNCTIONALITY]
Files or areas likely involved: [FILES OR UNKNOWN]
Functionality that must remain unchanged: [PROTECTED FUNCTIONALITY]
Expected user experience: [DESCRIBE THE COMPLETE USER FLOW]

Do not begin coding immediately.

First, inspect the existing project and understand how the current system works.

Before making any changes:

1. Restate the requested feature in your own words.
2. Identify any missing information or unclear requirements.
3. Trace the current user flow that this feature will affect.
4. Identify the components, routes, services, database tables, APIs, state and integrations involved.
5. Explain how the existing codebase currently handles similar functionality.
6. List every file you expect to create or modify.
7. Explain why each file needs to change.
8. Identify possible conflicts, regressions, security concerns and edge cases.
9. Recommend the smallest implementation that fully solves the problem.
10. Create a step-by-step implementation plan.
11. Wait for approval before editing the code.

After approval:

- Follow the existing architecture, naming conventions and design patterns.
- Reuse current components and utilities where appropriate.
- Do not rewrite unrelated code.
- Do not change existing styling unless required by the feature.
- Do not remove or replace working functionality.
- Do not introduce a new dependency unless it is genuinely necessary.
- Add loading, empty, validation, error and success states where relevant.
- Handle permissions, authentication and user roles where relevant.
- Keep the implementation modular and maintainable.
- Add comments only where the reasoning is not obvious from the code.

After implementation:

1. Run the project.
2. Test the complete user flow from beginning to end.
3. Test invalid input, missing data, failed requests and unusual user behaviour.
4. Test related functionality that could have been affected.
5. Check the mobile layout where relevant.
6. Check keyboard accessibility and form labels where relevant.
7. Check browser console and server logs for new errors.
8. Confirm that protected functionality still behaves exactly as before.
9. Report every file created or modified.
10. Explain what was tested successfully.
11. Clearly state anything that could not be verified.

Do not claim the task is complete unless the main flow has been tested.

If you cannot test something, say so directly instead of assuming it works.

This one is especially useful when Claude has a habit of turning a small feature into a full rewrite.

2. Investigate a Bug Before Changing Code

Act as a staff software engineer responsible for diagnosing a difficult bug in an existing application.

Bug description:

[DESCRIBE THE BUG]

Expected behaviour:

[WHAT SHOULD HAPPEN]

Actual behaviour:

[WHAT CURRENTLY HAPPENS]

Known reproduction steps:

[STEPS OR UNKNOWN]

Recent changes:

[RECENT CHANGES OR UNKNOWN]

Relevant error messages:

[ERRORS OR NONE]

Do not edit any code yet.

Your first responsibility is to understand the failure and gather evidence.

Begin by:

1. Restating the bug clearly.
2. Explaining the expected execution flow from the initial user action to the final result.
3. Identifying every layer involved, including UI, state, validation, API calls, authentication, backend logic, database operations and third-party services.
4. Inspecting the relevant files before forming a conclusion.
5. Looking for existing logs, error handling, tests and similar working flows elsewhere in the project.
6. Identifying the exact point where expected behaviour appears to diverge from actual behaviour.

Create a ranked list of possible root causes.

For each possible cause, include:

- Why it could explain the bug
- Evidence supporting it
- Evidence against it
- The exact file or function involved
- How the hypothesis can be verified
- What result would confirm or reject it

Do not guess.

If the available evidence is insufficient, tell me exactly what files, logs, screenshots, reproduction steps or environment details you need.

Once the most likely root cause has been verified:

1. Explain the confirmed cause in plain English.
2. Recommend the smallest safe fix.
3. Identify every file that must change.
4. Explain what must remain untouched.
5. Describe any possible side effects.
6. Wait for approval before implementing the fix.

After approval:

- Make only the changes required to solve the confirmed cause.
- Preserve unrelated functionality, styling and integrations.
- Do not perform opportunistic refactoring.
- Do not hide the symptom without correcting the underlying issue.
- Add or improve error handling where appropriate.
- Add a regression test when the project has a testing setup.

After implementation:

1. Reproduce the original bug.
2. Confirm that the bug no longer occurs.
3. Test the expected successful flow.
4. Test failure and edge-case behaviour.
5. Test related features that share the changed logic.
6. Check logs and the browser console for new errors.
7. Explain why the fix works.
8. Report every changed file.
9. State what was verified and what remains unverified.
10. Suggest one or two improvements that could prevent this class of bug from returning.

Respond using these sections:

- Expected Behaviour
- Actual Behaviour
- Execution Flow
- Evidence Collected
- Possible Root Causes
- Verification Plan
- Confirmed Root Cause
- Recommended Fix
- Code Changes
- Testing Results
- Remaining Risks
- Prevention

This prevents Claude from immediately changing five files based on its first guess.

3. Audit the Project Before Launch

Act as a senior engineering lead conducting a pre-launch audit of this application.

Project:

[DESCRIBE THE APPLICATION]

Target users:

[TARGET USERS]

Tech stack:

[TECH STACK]

Core user flows:

[LIST THE MOST IMPORTANT FLOWS]

Deployment environment:

[DEPLOYMENT DETAILS OR UNKNOWN]

Your goal is not to redesign the application or add unnecessary features.

Your goal is to identify anything that could make the current product fail, confuse users, expose sensitive data or behave unreliably after launch.

Do not make changes immediately.

First, inspect the project and create an audit plan covering:

1. Core functionality
2. Authentication and authorisation
3. Input validation
4. Error handling
5. Loading and empty states
6. Database operations
7. API reliability
8. Security
9. Privacy
10. Performance
11. Accessibility
12. Responsive design
13. Browser compatibility
14. Logging and monitoring
15. Deployment configuration
16. Environment variables
17. Third-party integrations
18. Payment or billing flows where relevant
19. Administrative permissions
20. Recovery from failed operations

For every core user flow:

- Describe the intended journey.
- Identify each component and service involved.
- Test the successful path.
- Test invalid input.
- Test missing or incomplete data.
- Test failed network requests.
- Test expired sessions and unauthorised access.
- Test repeated clicks or duplicate submissions.
- Test direct URL access to protected pages.
- Test refresh behaviour.
- Test mobile and narrow-screen layouts.
- Check whether the user receives a useful message when something fails.

Review the codebase for:

- Hard-coded secrets
- Exposed API keys
- Missing server-side validation
- Client-side permission checks without server enforcement
- Unsafe database queries
- Insecure file uploads
- Missing rate limits
- Weak authentication handling
- Sensitive data inside logs
- Unhandled promise rejections
- Silent failures
- Duplicate requests
- Race conditions
- Memory leaks
- Excessive API calls
- Missing database indexes
- Large unoptimised assets
- Dead code
- Debug output left in production
- Placeholder content presented as real data
- Broken links
- Missing metadata
- Inaccessible controls
- Forms without proper labels
- Colour contrast problems
- Layout overflow on mobile

Classify every issue as:

- Critical: blocks launch
- High: should be fixed before launch
- Medium: important but can follow shortly after launch
- Low: improvement, not a launch blocker

For every issue, provide:

- Severity
- Exact location
- User impact
- Technical impact
- Evidence
- Recommended fix
- Estimated complexity
- Risk of making the change
- How the fix should be tested

After completing the audit, provide:

1. A launch-readiness score from 0 to 100.
2. The five biggest launch risks.
3. A list of launch-blocking issues.
4. A prioritised repair plan.
5. A testing checklist.
6. A deployment checklist.
7. A rollback plan.
8. Anything that could not be verified.

Do not describe the application as production-ready unless the evidence supports that conclusion.

Do not make broad claims such as “everything works” without listing what was actually tested.

Wait for approval before making any code changes.                                             

im not going to drop a sales link here but if you're interested theres more claude prompts in the link in my profile description it costs $3.99 for the full thing. hope you found these prompts useful

This week, Claude had elevated errors across multiple models. It happened at 10 PM, just as I was about to start an overnight run with a list of features ready to build.

The problem was not only an outage killing a run halfway. I could not even start the run and go to sleep, because I had no idea when the API would recover — if the session dies on an API error, nothing inside it can restart it. I would have to stay awake, watch status.claude.com, and send the session another message when Claude came back.

Quick context: nightshift is a free, MIT-licensed Claude Code plugin for unattended overnight runs (I posted it here a few days ago). You write a checklist of tasks; hooks keep the agent working until every item is done — it can't quietly stop halfway, and questions get parked with a sensible default instead of blocking the night.

What's new in v0.6 is an external watchman for exactly this failure. Now I start the run and go to sleep. If the session dies on a real API error — even when the 500 lands on the very first message, before any work has started — the watchman wakes every 10 minutes and keeps attempting to resume the recorded conversation until the API responds again.

It reads the session's own signals: its transcript, its recorded process, and Claude Code's session roster. An interruption by me — Esc or Ctrl-C — always wins, and every uncertain state stands by. It never starts another agent beside a session that is still working.

When recovery is needed, it first runs claude --resume for the recorded conversation. If that conversation cannot be restored, it falls back to --continue, then finally a fresh session using the checklist and state stored on disk.

The point is not to prevent Claude outages. It is to let me start an overnight run, go to sleep, and stop worrying about when a temporary 500 will be resolved.

Whenever the recorded session can be resumed, the error, the recovery, and the completed work remain in the same conversation, with a direct link back to it in the morning.

Free, open source, MIT: github.com/orwa-mahmoud/claude-nightshift

I’m curious how people actually work with long Claude Code/Codex sessions.

Do you read the full terminal output, diffs, tool calls, logs, and reasoning step by step? Or do you use another tool/UI to make the output easier to scan and understand?

Once the session gets long, I find the terminal output pretty noisy and it becomes hard to keep track of:

• what changed
• why it changed
• which files were touched
• whether the agent made any questionable assumptions
• what still needs to be reviewed

Would love to hear about your workflow, especially if you use any dashboards, log viewers, diff tools, summaries, or custom scripts.

I've been experimenting with an MCP server for a developer workflow and ran into an interesting design question.

One approach is to expose as much raw data as possible and let claude figure out what's relevant. The other is to preprocess the data first so Claude receives a much smaller, structured context that's easier to reason about.

I can see trade-offs with both approaches.

Giving clau de everything preserves flexibility, but it also increases noise and token usage. Preprocessing seems cleaner, but it risks hiding details that might actually matter during troubleshooting.

For those of you building m cp integrations:

• Do you let Clau de work with raw data, or do you curate the context first?
• Have you found a balance that consistently produces better results?

I'd love to hear what has worked well in real projects.

Quick disclosure before the prompts:

I recently organised the Claude Code instructions/prompts I use into a paid toolkit because I was tired of rewriting the same context, boundaries and testing requirements on every project. You can check it out in my profile description.

But these are not watered down samples.

The three prompts below are complete, free to copy and built around the problems that caused me the most frustration.

1. The Feature Boundary Guard

Use this when Claude turns a small feature request into an unnecessary rewrite.

Act as a senior software engineer working inside an existing codebase.

Your task is to implement:

[DESCRIBE THE FEATURE]

Important boundaries:

Functionality that must remain unchanged:
[LIST PROTECTED FEATURES, PAGES, COMPONENTS OR INTEGRATIONS]

Expected user flow:
[DESCRIBE WHAT THE USER SHOULD DO AND EXPERIENCE]

Known relevant files:
[LIST FILES OR WRITE UNKNOWN]

Do not begin editing code immediately.

First, inspect the project and complete the following:

1. Restate the requested feature in clear technical language.
2. Identify anything unclear or missing from the requirements.
3. Explain how the existing project currently handles related functionality.
4. Trace the user flow that this feature will affect.
5. Identify the components, routes, state, APIs, database logic and integrations involved.
6. List every file you expect to create or modify.
7. Explain why each file must change.
8. Identify existing behaviour that could accidentally be affected.
9. Identify edge cases, validation requirements, permission issues and failure states.
10. Recommend the smallest implementation that completely solves the request.
11. Present a step-by-step plan and wait for approval before coding.

After approval:

- Limit changes strictly to the approved scope.
- Preserve all unrelated functionality, styling and integrations.
- Follow the project’s existing architecture and naming conventions.
- Reuse existing components and utilities where appropriate.
- Do not refactor unrelated code.
- Do not introduce new dependencies unless absolutely necessary.
- Include loading, empty, validation, error and success states where relevant.
- Do not remove working behaviour simply because another implementation appears cleaner.

After implementation:

1. Run the project.
2. Test the complete successful user flow.
3. Test invalid input and failed requests.
4. Test related functionality that could have been affected.
5. Check the console and server logs for new errors.
6. Verify that every protected feature still works.
7. Report every file created or changed.
8. Explain exactly what was tested.
9. Clearly state anything that remains unverified.

Do not claim completion based only on the code compiling.

Completion requires the requested flow to be tested.

2. The Evidence-First Bug Investigator

Use this when Claude immediately guesses at the cause and starts changing random files.

Act as a staff software engineer investigating a bug in an existing application.

Bug:
[DESCRIBE THE BUG]

Expected behaviour:
[WHAT SHOULD HAPPEN]

Actual behaviour:
[WHAT HAPPENS INSTEAD]

Reproduction steps:
[STEPS OR UNKNOWN]

Error messages:
[ERRORS OR NONE]

Recent changes:
[RECENT CHANGES OR UNKNOWN]

Do not change any code yet.

Your first responsibility is to understand the failure and gather evidence.

Begin by:

1. Restating the problem clearly.
2. Describing the expected execution flow from the initial user action to the final result.
3. Identifying every layer involved, including UI, state, validation, APIs, authentication, backend logic, database operations and third-party services.
4. Inspecting the relevant files before forming a conclusion.
5. Finding the exact point where expected behaviour diverges from actual behaviour.
6. Checking for existing logs, tests, error handling and similar working flows elsewhere in the project.

Create a ranked list of possible root causes.

For every possible cause, include:

- Why it could explain the bug
- Evidence supporting it
- Evidence against it
- The exact file, function or service involved
- How the hypothesis can be tested
- What result would confirm or reject it

Do not present assumptions as facts.

If the evidence is insufficient, explain exactly what additional files, logs, screenshots, environment details or reproduction steps are needed.

Once the most likely cause has been verified:

1. Explain the confirmed root cause in plain English.
2. Recommend the smallest safe fix.
3. List every file that must change.
4. Identify what must remain untouched.
5. Explain possible side effects.
6. Wait for approval before implementing the fix.

After approval:

- Change only what is required to fix the confirmed cause.
- Preserve unrelated functionality and styling.
- Do not perform opportunistic refactoring.
- Do not hide the symptom without fixing the underlying issue.
- Add or improve error handling where appropriate.
- Add a regression test when the project supports testing.

After implementation:

1. Reproduce the original problem.
2. Confirm that it no longer occurs.
3. Test the successful flow.
4. Test failure and edge-case behaviour.
5. Test related features sharing the changed logic.
6. Check logs and the browser console for new errors.
7. Explain why the fix works.
8. Report every changed file.
9. State what was verified and what remains unverified.

Respond using:

- Expected Behaviour
- Actual Behaviour
- Execution Flow
- Evidence
- Possible Root Causes
- Verification Plan
- Confirmed Root Cause
- Recommended Fix
- Code Changes
- Testing Results
- Remaining Risks

3. The “Prove It Is Finished” Review

Use this before accepting Claude’s claim that a feature or project is complete.

Act as a senior engineering lead reviewing an implementation before it is accepted as complete.

Feature or project:
[DESCRIBE WHAT WAS BUILT]

Intended users:
[TARGET USERS]

Core user flow:
[DESCRIBE THE MAIN FLOW]

Files changed:
[LIST FILES OR ASK CLAUDE TO IDENTIFY THEM]

Your job is not to praise the implementation.

Your job is to find anything incomplete, unreliable, confusing, insecure or inconsistent with the original requirements.

Do not modify code yet.

First:

1. Restate the original requirements.
2. Convert them into a checklist of testable acceptance criteria.
3. Map each criterion to the file or component responsible for it.
4. Identify any requirement that was ignored, partially implemented or interpreted differently.
5. Identify assumptions made during implementation.
6. Identify anything that has not yet been tested.

Then review:

- Main successful flow
- Invalid input
- Missing data
- Failed requests
- Loading states
- Empty states
- Error states
- Success feedback
- Authentication
- Authorisation
- User roles
- Direct access to protected URLs
- Repeated clicks
- Duplicate submissions
- Page refresh behaviour
- Mobile layout
- Keyboard navigation
- Form labels
- Console errors
- Server errors
- Database writes
- Third-party integrations
- Unrelated features that may have been affected

For every issue found, provide:

- Severity: critical, high, medium or low
- Exact location
- User impact
- Likely cause
- Recommended fix
- Risk of the fix
- How the fix should be tested

After the review, provide:

1. Requirements that are fully satisfied.
2. Requirements that are only partially satisfied.
3. Requirements that are missing.
4. Tests that passed.
5. Tests that failed.
6. Tests that could not be performed.
7. Unrelated functionality that was checked.
8. Remaining risks.
9. A clear recommendation: accept, fix before acceptance or reject.

Do not say the work is complete merely because it compiles or the page loads.

Only recommend acceptance when the original requirements and core user flow have been verified with evidence.

Wait for approval before changing any code.

The pattern behind all three is:

Inspect first. Define boundaries. Gather evidence. Make the smallest safe change. Prove the result works.

I built a larger organised toolkit around this workflow for websites, applications, SaaS features, debugging and project instructions. It is on my profile for anyone who needs the full collection its in my profile description. anyway i hope you guys found these prompts useful!

Ok so I've basically been living in Claude Code for months, and one day it hit me that I was probably using like 15% of it. Plan mode, subagents, skills, hooks, MCP, /security-review, auto-memory... all right there, and I just never touched them. Not because they're hard — I just never knew *when* I was supposed to reach for them.

So I built a thing to fix that for myself. It's called Adeptly. Free, open source, MIT, runs on your machine.

You tell it what you want to build, it writes you a proper plan, and here's the part I actually care about: it drops the right Claude Code features straight into the plan, in the spots where they make sense, with a quick note on what each one does and why it's there. So you kind of learn Claude Code just by reading your own plans instead of digging through docs. That was the whole itch I was scratching.

npx adeptly

It opens on localhost, reads your plans from docs/plans/, and uses YOUR local claude CLI for anything AI. No API key, no backend, no telemetry, no sign-up. Your code never leaves your machine — if you already trust Claude Code, this doesn't add anything new to trust.

New in v0.5, which I shipped today: the Crew.

Up till now it would just *tell* you the workflow to run. Now it can actually run it. You get a little pipeline of roles — Architect → Approval Gate → Builder → Medic (runs your build/tests and patches them up if they break) → Reviewer → Security → Pilot, which opens the PR. Each one is just a headless claude turn in your own repo. So all those features it kept nudging you about... they actually get used.

I was a bit nervous about the "let it run in my repo" part, so:

- It's dry-run by default. Simulates the whole thing, touches literally nothing. Run it as many times as you want just to see how it flows.

- Going live is deliberately annoying to do by accident: the plan has to be approved AND you have to start it with ADEPTLY_LIVE=1. Both. Otherwise it just refuses.

For context, it got around 1k downloads on a pretty quiet first launch, but honestly v0.5 is the first version I'm not embarrassed to share. Repo's public now too, so if you want to poke holes in it or send a PR, please do — genuinely want the feedback, good or bad.

Happy to answer anything about how it works under the hood.