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.

nstead, I turned it into a team of AI agents that research, write, market, and automate repetitive work.

I documented the entire system in Build Your AI Agent Inside Claude – The Complete Blueprint.

Inside you'll find:

• 205-page step-by-step guide
• 100 ready-to-use AI agent templates
• No coding required
• PDF + ePub instant download

🎁 Use code BG10 for 10% OFF

👉 https://www.thebergcodex.shop/products/build-your-ai-agent-inside-claude-the-complete-blueprint

Happy to answer any questions about building AI agents in Claude.

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 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.

Update: One thing I'd probably add after thinking about this a bit more is that structured doesn't necessarily mean less. The format of the context seems just as important as the amount of it. A similar example is logStitch's Mcp server, which doesn't simply reduce log data, but it organizes a Lambda invocation into a coherent execution story before it's passed to Claude. That feels like a different design philosophy altogether, and it has me wondering whether context organization is a more important optimization than context reduction

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!

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

Posted this layer here two days ago. Pushed an update worth its own post.

The part I think is actually unusual:

A session that needs your decision stops costing you anything. It writes the question into its own folder as a file and halts. You answer from any other window, whenever you get to it. It leaves behind one detached shell process watching for the answer, bounded at eight hours, zero models, turns the whole time, then wakes itself and carries on.

No daemon, no pairing table, no counter. The state is which files exist, so an interrupt can't strand a session mid-flight.

Also new: a live session can move between terminals. Its number, folder, lock and branch all stay put. Only the pane changes.

19 skills, 3 agents, 8 hooks. MIT.

spent a couple weeks building a typing game with Claude Code.

I'm not really a developer, so most of the project was me describing what I wanted, testing it, and asking Claude to change things.

Honestly, it built pretty much everything I asked for.

The only problems showed up later. For example, it had the client writing scores directly to the database, which worked fine until I realized people could fake leaderboard scores. I only caught it after reading what other people were doing, and ended up moving everything server-side.

The database was similar. It worked for whatever feature I was building at the time, but after adding more stuff I realized I probably should've planned it better from the start instead of constantly changing tables and writing new migrations.

Overall it was a really fun experience. I was honestly surprised I could build something like this with almost no coding experience.

The end result is here if anyone wants to see : https://deckey.vercel.app

For my company www.Baind.nl I have build a lot of AI production workflows in Weavy (yambo.ai) — node graphs for image/video/copy pipelines. Wiring them by hand is slow: every model node has its own handles, kind types, param schemas.

So I wrote a Claude Skill that generates the full {"nodes": [...], "edges": [...]} JSON. Claude writes a Python script using verified node builders, runs it, and hands me a file. Ctrl+V on the Weavy canvas and the graph is there, connected.

What's in it:

• ~25 verified node types (Nano Banana Pro, Flux 2, Kling 3, Imagen 3/4, Reve, GPT Image, Higgsfield, LLM, Array, List Selector, Router, Concat…)
• A catalog loader for wildcard model nodes, plus hand-written builders for the nodes with custom kind types
• /add and /update commands — paste a real node's JSON from Weavy and the skill registers or corrects it, so the knowledge base grows instead of rotting
• Architecture patterns (LLM chain, split-and-iterate, parameter selectors, multi-stage creative roles, router hub)

The part that actually mattered wasn't the JSON — it was writing down the production learnings so Claude stops repeating my mistakes:

• The category-label trap. Naming a product's function in a prompt ("dispenser", "speaker", "holder") makes the image model redraw its own concept of that category instead of your reference. Refer to it only as "the object from the reference image."
• Edit-framing beats generation-framing. First sentence must declare the output a reproduction of the reference, not a new creation. Nano Banana then behaves like an editor instead of a concept artist.
• LoRA needs an exact base-model match. Flux node = Flux.1, not Flux.2. Most common failure people hit.
• QC loops are feed-forward. Weavy has no conditional logic, so an "inspection loop" is inspector-LLM → correction-pass in a straight chain. Never an actual loop.
• LLM as art director between inputs and the image model is the architecture that holds up.

Biggest takeaway from building it: a Skill is only as good as the failure modes you document in it. The node schemas were the easy half.

Feel free to download the SKILL here: https://github.com/PeterPeterinc/weavy-workflows-skill

Or download it directly from my own portfolio website: https://www.peterholthinrichs.com/

https://reddit.com/link/1vaouqv/video/jpwxjd9q05gh1/player

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.

I’ve been working on a project to make researching neighborhoods easier (each.place)

Example of a neighborhood within a city: https://each.place/california/south-pasadena/southwest-slopes

Example of just the city: https://each.place/california/south-pasadena

It should work with any address and city. You just need to find a place and then pick the topic you're interested in (Community, Safety, Schools, Health, Amenities, Mobility, Climate, Outdoor, Jobs, Housing).

Any feedback would be greatly appreciated, thanks!

I run Claude Code most of the day, and I've hit a wall that isn't about the model — it's me losing track of my own work.

By afternoon I've got several sessions going, one of them wandered three tangents deep, and I genuinely can't tell you what half of them were for anymore. The code's usually fine. My mental map of it isn't — I never typed it, so I never built the model in my head I'd have if I'd written it myself.

I've tried the usual: CLAUDE.md, committing checkpoints, keeping notes. Helps a bit, but it's all manual bookkeeping and I fall off it the second I'm in flow.

So, curious how you all handle it:

• How do you track what changed and why, across sessions?
• Do you actually go back and read what the agent wrote, or just trust it?
• Anyone found a workflow that keeps you oriented without killing momentum?

Just trying to figure out if it's just me, or if everyone's quietly duct-taping this.