Looking for 5 Claude power users to test something I built for long-chat handoffs
I’m looking for 5 Claude power users to help me sanity-check something I built.
This came from my own frustration.
I use Claude for long project chats, and the same thing kept happening: the thread would get valuable because it had all the context, decisions, failed attempts, files/errors, blockers, and next steps… then eventually it would get too long, too messy, or annoying to continue.
Starting fresh always felt painful because the new chat didn’t know the actual state of the work.
So I built AI Know It All.
Right now it starts with Claude.ai exports. The Chrome extension lets you export/backup Claude chats, and the web app turns a long export into a handoff doc + “Continue This Thread” prompt for a fresh AI session.
To be clear:
- It is Claude.ai only today
- It does not import ChatGPT yet
- It does not bypass Claude limits
- It is not magic memory
- It is meant to help with the restart/recap tax when a long thread becomes painful to continue
What I need now is real feedback from people who actually have messy Claude chats.
I’m looking for 5 people willing to test it with one real long Claude conversation and tell me whether the fresh session actually starts useful.
You can try it here:
https://aiknowitall.ai
Chrome extension:
https://chromewebstore.google.com/detail/aboidpipkbpflopfakglopgdmmaidknb?utm_source=item-share-cb
You get 3 free starter outputs, so you can test without paying.
And if it genuinely helps and you want Pro, I have a Founding 25 code: FOUNDER19. It makes Pro $19/mo forever instead of $29/mo for the first 25 people.
But the main ask is feedback, not payment.
I want to know:
- Did it save you recap time?
- Did it preserve the right decisions?
- Did it catch failed attempts / “don’t retry this” context?
- Did the fresh session understand what to do next?
- What felt confusing, wrong, or untrustworthy?
- Would you actually use this again?
I’m looking for blunt feedback, not politeness.
If you try it, reply here with what worked, what broke, or what felt confusing.
The restart tax is real — I hit this weekly. One pattern that helps alongside a handoff tool like yours: encoding the key decisions and ‘don’t retry this’ constraints directly into the CLAUDE.md file as standing rules. That way the fresh session loads them automatically without a recap prompt at all. Works especially well for recurring project sessions where the decisions stay stable across weeks. The two approaches are complementary — your tool for one-off long chats, CLAUDE.md for persistent project context. Curious whether your handoff doc format could map cleanly to CLAUDE.md structure.
This is a really good framing.
I agree that CLAUDE.md and a handoff doc solve two different but related problems.
The way I’m thinking about it:
The interesting bridge is exactly what you called out: taking a messy long chat and turning the durable parts into something CLAUDE.md-shaped, while keeping the temporary working-state stuff in a separate handoff.
That might actually be one of the cleaner future directions: “extract project rules” vs “continue this thread” as two different outputs.
Appreciate the thought. This is the kind of workflow detail I was hoping people would pressure-test.
The handoff problem is real. Once a long chat turns into a pile of decisions, failed attempts and half-finished context, starting over feels a bit like amnesia. What I keep noticing is that the friction starts even before the export, when you’re trying to explain the next step clearly enough so the next chat doesn’t drift off. That’s the same kind of capture problem DictaFlow handles well, because it gets the messy first draft out of your head fast.
This is a really useful point.
I think you’re right that the friction can start before the export. The user may know the chat is messy and valuable, but still not know how to say “this is where I am, this is what matters, and this is what the next session should do.”
That “next step clarity” piece might be more important than I originally gave it credit for.
The handoff should probably do two jobs:
Otherwise it risks becoming a better summary, but not necessarily a better continuation.
Appreciate you calling that out. That’s going into my notes.
This is a real problem. Long AI chats become valuable exactly because they contain the messy project state: decisions, failed attempts, files, blockers, and next steps. Losing that context during a restart is not just annoying, it breaks momentum.
The strongest positioning here is not “AI memory.” It is project handoff infrastructure for AI work. That makes the product feel more serious and easier to trust, especially for Claude power users doing real work inside long threads.
The name is where I’d be careful. AI Know It All is memorable, but it sounds a bit gimmicky for a tool handling serious project context, failed attempts, and handoff accuracy. If the product expands into ChatGPT, team workflows, project continuity, or multi-AI handoffs, the name may start working against the trust layer.
Xevoa .com would fit this better as a clean AI workflow brand. It keeps the product on the user’s side: continuity, control, and smoother handoffs, without making it sound like a novelty AI tool.
I’d pressure-test that before more Chrome extension users, docs, and paid plans lock around the current name.
This is fair feedback, and I appreciate you saying it directly.
The “project handoff infrastructure for AI work” framing is strong. That actually feels much closer to what I’m trying to build than generic “AI memory.”
The backup/export piece is useful, but the real value is whether someone can carry messy project state into the next AI session without losing decisions, failed attempts, blockers, and momentum.
On the name, I hear you. I’m not going to knee-jerk rename it off one comment, but the trust-layer point is valid. A tool handling serious project context needs to feel serious enough that people trust it with real work.
For now I’m going to keep pressure-testing whether the product earns that trust through the workflow, copy, and onboarding. But I’m definitely adding the name/trust concern to the watch list.
That is the right way to think about it.
I would not knee-jerk rename either, but I would separate two questions early:
Does the workflow earn trust once people use it?
And does the name create enough trust before they install it, connect serious project context, or pay for it?
For this kind of product, the second question matters more than usual because users are handing over messy work history, decisions, files, blockers, and project state. “AI Know It All” is memorable, but it may make the product feel lighter than the job it is doing.
That is why Xevoa came to mind. It feels more like an AI workflow/control layer than a novelty assistant name.
If Xevoa is only a naming example, no need to overthink it. But if it feels like a serious candidate, I’d pressure-test it before Chrome users, docs, onboarding, and paid plans bake the current name in too deeply.
Tried setting it up and I think the biggest challenge here may actually be onboarding trust/clarity rather than the export itself.
I hit a “Frame with ID 0 is showing error page” state pretty quickly and immediately had a moment of:
The interesting thing is that products like this depend heavily on confidence because users are trusting the tool with large/context-heavy workflows they already care about.
So even small unclear states during setup can create hesitation very quickly.
I’d probably pay a lot of attention to:
This is super helpful, thank you.
I think I see what happened here, and this is on me more than you.
I didn’t make the starting flow clear enough. The extension is currently built around starting from Claude.ai / an actual Claude chat state. If it gets opened from the wrong browser state, or the Claude tab/frame is not available in the way the extension expects, it can throw that ugly “Frame with ID 0 is showing error page” type of message instead of telling you what to do next.
That’s bad onboarding on my part.
The product should have said something more human like: “Open Claude.ai first, go to the chat you want to export, then run the extension from there.” And if the tab is in a weird state, it should explain how to recover instead of showing a cryptic frame error.
I’m going to tighten that up because for this kind of product, trust matters immediately. If the first failure state is confusing, that’s a real problem.
Really appreciate you calling it out. If you’re willing to try again after I clean up the guidance/error state, I’d genuinely value the second pass. But either way, this was exactly the kind of blunt feedback I needed.
Yeah, I’d be happy to take another look after the onboarding flow gets cleaned up a bit. And honestly, I think this is one of those products where the first 30–60 seconds matter disproportionately more than in a typical SaaS tool.
Because users are already arriving with a pretty fragile mindset:
So the onboarding almost has to feel reassuring immediately:
“your context is safe,”
“here’s what’s happening,”
“here’s what to do next.”
Especially for technical users, cryptic errors can instantly shift the mental model from: “this tool understands my workflow” to “this might break my workflow.”
The core problem itself feels very real though. I immediately understood the pain you’re targeting.
Thanks again for the feedback here. I dug into the issue and made the first-run/error-state improvements based on what you ran into.
The short version: the extension was surfacing a raw Chrome frame error when Claude.ai wasn’t in a fully usable loaded state. That’s exactly the kind of thing that makes the setup feel broken or unclear, so I tightened the guidance around opening/loading/signing into Claude and retrying safely.
The updated build has been QA’d locally and submitted to the Chrome Web Store, but it’s still pending review. I’ll circle back once it’s live and would really appreciate a second pass if you’re still open to it.
Really appreciate you taking the time to test and call this out. This was the kind of first-user friction I needed to catch.
Yeah, this is exactly right. The first 30–60 seconds should make the state obvious, not ask you to debug the extension.
I tightened the ugly frame-error path in the local build so it gives clearer Claude.ai / open-chat / recovery guidance instead of a cryptic frame message, but I still need to finish QA and package it before I ask you to retry.
The bar I’m using from your feedback is simple: you should know what happened, what to do next, and whether your context is safe.
I’ll circle back once that version is actually ready to test. Appreciate you being willing to take a second pass.
This direction already sounds much stronger.
And I think the “is my context safe?” framing is actually the key insight here.
Because this product isn’t just exporting chats — it’s touching accumulated work, thinking, decisions, and project memory people are emotionally attached to.
So users probably evaluate trust before they evaluate features.
One subtle thing I’d pay attention to:
during onboarding/recovery flows, users may not even read long explanations if they’re already anxious.
So small state signals might matter disproportionately:
Those kinds of confirmations can calm people down really quickly without forcing them to parse technical wording.
The fact that you’re tightening this before pushing harder on growth is probably the right move.
Yeah, appreciate you being willing to take another pass. The Chrome Web Store hotfix is live now as v1.6.7.
The main thing I cleaned up was that ugly setup/error path you hit. It should now give clearer Claude.ai / open-chat / recovery guidance instead of leaking a cryptic frame error.
If you still have one messy Claude chat you’re willing to test with, I’d love a blunt second look. The specific thing I care about is whether the first 30–60 seconds now make the state obvious: what happened, what to do next, and whether your context feels safe.
If anything still feels confusing or untrustworthy, that’s the feedback I want most.
Sorry for disappearing for a bit — life got unexpectedly busy on my side and I fell behind on a few things.
Glad to hear the hotfix made it through.
I still think the trust/onboarding layer is the right thing to focus on first for a product like this. The problem you're solving is inherently tied to people's accumulated project context, so users will notice uncertainty much faster than they notice new features.
I'll install the updated version and give it another pass. I'm especially curious whether the first-run experience now makes the system state feel obvious without requiring users to mentally debug what's happening.
Once I've had a chance to go through it properly, I'll send over any notes.