I kept correcting Claude Code the same way across sessions:
"Don't catch that error here—let it bubble up so the global handler logs it with the request context."
"We don't use feature flags for this repo. The deploy pipeline handles rollouts."
"Stop creating new API endpoints. Extend the base resource controller—that's why it exists."
"Auth tokens go in httpOnly cookies, not localStorage. We had this discussion."
"Don't mock the database in tests. We use a real Postgres container—it's already in the docker-compose."
These corrections contain useful context—why I want something done a certain way. But they disappear when the session ends.
Superwiser watches your prompts (not Claude's responses, not tool calls, not file operations—just your prompts) and extracts preferences and corrections. Stores them locally. Claude can search them in future sessions.
How it's different from memory plugins: those capture everything Claude does and compress it into summaries. Works, but burns tokens and duplicates what Claude already handles. Superwiser only tracks human steering. Uses Sonnet in the background to extract rules, so it's cheap and fast.
Also has conflict detection. If you said "use Redux" three months ago but now say "just useState," it asks which one applies.
Simple rules still belong in CLAUDE.md. "Use TypeScript" doesn't need a plugin. Superwiser is for the contextual stuff that emerges during sessions—harder to anticipate upfront.
We are not running on top of Twilio. We use multiple tier-1 aggregators for redundancy and Twilio is not one of them. In-fact Twilio also uses some of them.
On Twilio: It took me a staggering three weeks just to get my business profile reviewed and approved, followed by another 2-3 weeks of back-and-forth communication to get my campaign off the ground. It was a real test of patience.
Absolutely, I get the concern about the docs looking like a placeholder. We're putting a lot of effort into crafting the best SDKs for major languages, so for now, the most comprehensive guide is at https://docs.postack.dev/api-reference/introduction.
Regarding A2P messaging, it's pretty standard: create your brand and campaigns, typically with a 72-hour turnaround. We're streamlining compliance by auto-generating legal documents, webform screenshots using templates, and leveraging ChatGPT to preemptively fix any issues before they reach upstream carriers. It's all about making the process as smooth as possible for you.
I'm gonna give it a try with your video. If I may ask how many speakers are there in this video. (I have to go through all of it otherwise). From what I can see, we have a teacher who is speaking most of the times and then few laughs from students in the background.
Well there are definitely some advantages of serverless i.e.
- you don't have to create docker images and complex CI/CD pipelines.
- You don't need to worry about deployments (using Heroku, AWS ECS or Kubernetes) and scaling.
- you don't need to write a lot of unnecessary boilerplate code which you do in the case of micro-services.
- You pay per invocation and resources used for that invocation.
But then serverless comes with all the issues which I have described in original post. I think serverless is good for quick prototyping but for production use, we should still be using micro-services. It'd be idea if we can create a new layer of abstraction which has good things of both micro-services and serverless architectures.
I usually read other's code a lot. I personally believe, reading other's code (at your workplace, open-source, etc.) is better than practicing. I am not sure if it's true but it worked for me.
"Don't catch that error here—let it bubble up so the global handler logs it with the request context." "We don't use feature flags for this repo. The deploy pipeline handles rollouts." "Stop creating new API endpoints. Extend the base resource controller—that's why it exists." "Auth tokens go in httpOnly cookies, not localStorage. We had this discussion." "Don't mock the database in tests. We use a real Postgres container—it's already in the docker-compose."
These corrections contain useful context—why I want something done a certain way. But they disappear when the session ends.
Superwiser watches your prompts (not Claude's responses, not tool calls, not file operations—just your prompts) and extracts preferences and corrections. Stores them locally. Claude can search them in future sessions.
How it's different from memory plugins: those capture everything Claude does and compress it into summaries. Works, but burns tokens and duplicates what Claude already handles. Superwiser only tracks human steering. Uses Sonnet in the background to extract rules, so it's cheap and fast.
Also has conflict detection. If you said "use Redux" three months ago but now say "just useState," it asks which one applies.
Simple rules still belong in CLAUDE.md. "Use TypeScript" doesn't need a plugin. Superwiser is for the contextual stuff that emerges during sessions—harder to anticipate upfront.
Install: /plugin marketplace add mu4farooqi/superwiser /plugin install superwiser
Just mention "use Superwiser" in your prompt to load relevant context. We don't pre-load silently in the background.
Experimental. I'm using it daily but expect rough edges. Contributions welcome.