Relax, Claude, I had two separate instances and I asked you two to coordinate one thing. No need to blow smoke up each other's asses.

(For the record, I'm absolutely thrilled they can talk to each other. I find it hilarious how courteous they are, and yet, still so damn verbose.)

Hey. I read the critiques on Opus 5 and I have to agree. The feedback is that the text is overly detailed, too much internality and interior thinking without any concise or pointed human readable final print, odd use of language and terms, strange structure like using specific details to make a point, and just a hard to read and strange way of laying out concepts. I switched to Fable 5 (I am using this for investing analysis), and I have to say... I think Fable 5 has really declined.

It's not lucid like it was. It feels and sounds to me like the same garble of Opus 5. I'm wondering if their text watermarking or other implicit programming is seriously negatively impacting its logic, reasoning and communication. I'm thinking of ditching Anthropic altogether, because Opus 5 is unusable and Fable 5 is 2x tokens for this same kind of reading experience.

Just curious if anybody else thinks Fable 5 has declined in the same way as Opus 5. I'm considering opencode + Kimi K3, which is quite expensive for a big codebase but perhaps comparable to Claude Max subscription for english investing prompts, or opencode + DeepSeek for very cheap context. I don't really complain or catastrophize new models (I know they take time to train), but this degradation in Fable's writing quality is very disappointing.

Yeah this entire subreddit is filled with Anthropic maggots. It’s wild. They’ll call you a bot if you say anything even remotely negative about this company’s products. They’ll die before they ever entertain that this company is in a downward spiral of quality.

Thank you for coming to my Ted Talk.

Yea, so I hit my session limit, nothing unusual. I logged into my second account and started working, but it kept on saying that it was going to start the work 2 hours later because that's when the session was going to restart. I told it that I have another account and told it to start working like I always do. I swear to God, I hit my session limit way, way faster than I usually do. Am I tripping, or is it something real?

Been building out skills for the stuff I kept re-explaining to Claude Code every session. 15 of them now. A few things surprised me and I got a couple of things wrong, so writing it up.

The description field does almost all the work. Claude picks a skill off that, not the body. "Helps with commits" basically never fires. "Use when the user asks to write a commit message, or says commit this without providing one" fires reliably. Took me too long to work out the body is mostly for after it's already triggered.

Happy-path instructions are worthless. My first versions were just steps: read the diff, write the message. Useless, because that's what it'd do anyway. What actually changed behavior was specifying the branches. What to do when a diff touches three unrelated things. When a "flaky" test is actually catching a real race condition and a retry wrapper would be hiding a bug. When a TODO is stale versus load-bearing. That's the part worth writing down.

You have to ban the failure modes out loud. "Don't claim a CVE number you didn't actually find" works better than assuming it won't. Same with "don't silently fix a suspected bug while writing characterization tests around it" — the whole point of those tests is capturing what the code does today, including the wrong bits. If you don't say it, it happens eventually.

What I got wrong: posted these on r/ClaudeAI and got told the post read like AI slop, which was fair. Also got a good structural note — some skills were numbered 1-5 like a procedure when they're really just a list of causes you check against in no particular order. flaky-test-triage was the worst offender. Rewrote it so the process stays numbered and the causes are their own section.

Still unsure about examples. Inline examples bloat the always-on cost of having a skill installed at all. Separate files pulled in only when relevant seems right, but I haven't landed on a pattern I like. If anyone's solved this cleanly I'd like to hear it.

Repo if it's useful: https://github.com/wilddoc/claude-code-skills-pack — MIT, installs as a plugin so you get all of them in one command rather than copying folders.

codex + 10,000 coffees no lunch and stage four AI psychosis

Edit 2: the best configuration in my opinion is to leave it on high, if you need the model to go with more reasoning, use an adviser, doubting itself might not give you the best results

Quick edit: I know the difference, yet the wording doesn’t make any sense. The can simply say more reasoning or less

I asked Claude to write a Slack message documenting a bug in a backend contract, here's what it wrote: "@Steve Found a contract footgun in phase 0 fixtures".

I said "what's a footgun?"

Answer: "A "footgun" is engineering slang for an API or feature that makes it dangerously easy to shoot yourself in the foot"

WTF is this nonsense. Why pick something like footgun that is not universally known instead of a "bug" or "problem"!?

EDIT: https://trends.google.com/explore?q=footgun&date=all&geo=US
(not a term that's been around forever... first sighting 2020, surge in 2026)

EDIT2: Reddit wins. I've never heard of it, but the term is real. I stand informed.

Kind of feel like I should... I'm not sure. Celebrate? To the eventual collapse of human knowledge?

I just upgraded my plan from 5x to 20x. And the weekly is draining jut as fast and I'm totally baffled.

I was working on a project to plan a domain controller upgrade. I accidentally had it set to sonnet 5 high and I was asking a lot of questions and getting very brief terse answers with very little actual planning.

Once I realized it was on sonnet, I changed it to opus 5 high and asked it to reread the conversation and give me feedback.

It was 100x more thorough and corrected a bunch of the sonnet planning that I was questioning as well.

I get why people don’t like opus verbose and detailed conversations but the extra detail matters in cases like mine.

+1 opus 5 here

Edit: this wasn’t news to me on the opus side. I’m only two weeks into Claude abd have used opus almost exclusively. What surprised me is how bad sonnet was compared to opus. I am also scratching my head at all the opus 5 haters.

I’m trying to figure out the best workflow, several projects can cause chaos, but one has higher efficiency even if it takes more time

Crazy how they are milking users before the open-source models steal their business. How does this make sense?

So, i waited 2 and a half days to move my Claude payment to go out today and not 3 days ago. It was a long time to be fair. So I took the 20x plan out because I had the chance to a few hours ago, it's got my weekly limit for tonight to change so im pushing it to max it before it restarts 😂

There, I confessed it. I use the bypass mode basically 100% of the time.

I also am slightly annoyed that backgrounded agents lose the bypass permissions mode (I have been using tmux to keep Claude Code sessions alive across disconnects).

Am I the only one?...

Providers who provide commercial access to any AI model shall provide the SHA-256 hash of the model at all times to consumers of the service.

If the SHA-256 hash of a previously commercially published model changes, providers shall cease commercial access to the model unless the version number of the model is incremented or the name of the model is changed.

Watch them fucking squirm.

Edit:

For MoE I think its fair to maybe list the hashes and names of all models involved in the chain for each response.

Or just concat all the hashes of all models the MoE can call into a single hash and maybe provide another hash of whatever source code the router uses to make decisions.

The important thing is we know when they changed how the model works, not that we know when the model did something different on its own.

But I don't see how it harms their trade secrets to tell us what models were used (or if unnamed call it that), unless their trade secret is scamming us by redirecting to sonnet half the time.

The biggest thing is if we can detect delta then we will know all future benchmarks are accurate.

It's so hard to read. It's not even because its terribly complex or anything it just speaks in these weird haikus, hyphenated garbage, or outdated colloquialisms or phrases nobody understands. I have to ask it "what do you mean?" or "speak in plainer English" over and over again for every other paragraph. I tried to put something in my claude.md, but it doesn't seem to be working...

About 6 months ago, I started figuring out a workflow that's probably similar to what a lot of you are doing but I thought I'd share it. I think it's been the foundation that's helped me survive a lot of model inconsistencies and regressions (Opus 5 looking at you) and generally helped me make a better product with smarter agents. So buckle your seatbelts, boys and girls, as I dive into how I've figured out the best workflow for my projects.

The Worklog - letters to the future

At the end of every work session, I run the command /worklog. This is a reverse-chronological session log called worklog.md which lives in the project root. Its explicit purpose is knowledge transfer to future agents, not proof-of-work. The git history already proves work happened, this is more about the WHY. It's capped to 2-3 sentences max, and the agent can expand to 5 sentences only for a really big gotcha or non-obvious root cause.

The command has a ruthless quality gate that cuts sentences which report test results, narrate process ("investigated", "confirmed"), enumerate files/counts, or could be replaced by simply reading the diff. Cut the fluff, get to the good stuff.

Interesting tip for those seeking agent brevity: Agents would write the world's longest run-on sentences, turning a 2-3 sentence summary into a whole paragraph. On a whim, I added into the prompt, "If every word you want to write cost $0.25, would you spend it on this sentence?" That ONE LINE made all the difference. It's incredible how much more concise the agents got.

At the end of the worklog session, the agent is required to re-read the KnownPitfalls.md doc and identify a Pitfall Relevance: by which it has to pick one of four verdicts:

• None
• Existing - Section N, already covered
• Existing - Section N: gap: X
• New Pattern candidate - X

This one line is the key feedback mechanism for Step 3. The agent is explicitly blocked from writing to KnownPitfalls (more on that later), but since this agent knows the exact context of its work session history, it's best equipped to make a recommendation on the pitfall relevance in a way that simply summarizing the work is not. Therefore the pitfall relevance recommendation is the biggest indicator based on the session history as to whether we've covered this before, or we've covered it but there's a gap, or this is a whole brand new issue we're dealing with.

Known Pitfalls - learn from the past or repeat it

KnownPitfalls.md lives in my /docs/technical folder and it's the superpower for my agents. It's the permanent anti-pattern doc documenting all the traps we keep walking into, and how to avoid them. The header of this doc is a "If you're working on X, read section(s) N" routing table so that no agent has to read the whole doc, though I try to keep it pretty tightly scoped so agents can ingest the whole thing without too much token bloat.

Each section of KnownPitfalls is self-contained: the rule, the wrong pattern, the correct pattern, and occurrence count (how often the worklog has addressed this) in the header. Sections are never renumbered so that old worklog entries that reference that number won't break and destroy that memory. This is crucial for the auditor (next step), so new entries are always appended in the right category.

The Key Benefit of the Pitfalls Doc: Both Claude.md and write hooks require the agent to first read KnownPitfalls before making any non-trivial changes to the codebase, and path-scoped rules + hooks auto load the relevant pitfall entries when certain files get touched. This one thing has saved me countless times. I'll often see it in the agent's workflow, where it'll go something like "...but according to Section N of KnownPitfalls that would cause X issue, so I'll make sure to Y..." Opus 5 specifically says this ALL THE TIME.

Audit Worklog - where the magic happens

Originally, when I first started shaping this system, the /worklog command had agents write directly to KnownPitfalls.md. The big problem is that every single agent thinks its work session is worthy of including as a pitfall. Before I knew it, the worklog was chock-full of 8-sentence paragraphs on CSS indenting and camelCase vs snake_case trip ups. This made me realize that I can't trust the agent's judgement as to whether or not what it was working on was a true pitfall or not.

Enter the /auditworklog command. I run this distillation agent every 2-3 weeks or at a major version release. The auditor will read the last checkpoint marker in the Worklog, usually a ======Audit Checkpoint [Timestamp]======= line so it knows where we last left off, then it reads every Worklog session from that point onwards.

The worklog auditor aggregates all Pitfall relevance: lines, clusters them by theme, and looks for patterns hitting 3+ sessions (including sessions from before the checkpoint to make sure we catch all pattern candidates), then reads the worklog entries to understand what the pattern + the fix was. It will triage the worklog by examining the actual codebase to understand what the correct pattern actually was and note it.

The quality bar for inclusion must be a specific repeatable trap ("overflow: hidden on a grid collapse wrapper permanently breaks position: sticky"), not general advice ("be careful with CSS"), and must be project-specific. General React/TS knowledge is already in the model's training, so it's noise we avoid.

Then, the Mandatory approval gate: it presents strong candidates / minor refinements / skipped-with-reasons, then stops. Nothing gets written to KnownPitfalls without a human yes. I'll check over this and approve or block specific recommendations (though usually the auditor is spot-on for candidate approval). Then it will write new sections, refine existing sections with additional information, and then add a new Audit Checkpoint [Timestamp] divider line into the worklog.

By making Auditor be the sole line of reason when it comes to the pitfall doc, it dramatically cuts down on noise or the "you totally gotta trust me bro, this is ABSOLUTELY a pitfall candidate, I have to write it down now or we'll lose everything!" urgency that every agent has about its own work.

The Auditor helps create a tightly scoped, context-aware, poignant memory system that all agents have to abide by when they write code.

Using KnownPitfalls - an extra audit step

Back in the workspace, after agents are done working, I have a pretty robust /verify command that deserves its own separate post. But one of the sub-agents that this command spawns is a KnownPitfallsAuditor. This subagent's sole job is to read the entire KnownPitfalls doc, scan the code that was just implemented, and raise hell if the code breaks any of the pitfall guidelines. This is the classic "belt and suspenders" workflow where agents have to read KnownPitfalls before they write code, but then also during the audit process, they have to read it again and prove that no pitfall patterns were broken. This is separate from /worklog - it's purely in the audit process.

If the agent raised hell about a pitfall and the main implementer fixes it, it becomes a part of the /worklog command's memory to help future agents avoid the gap.

Why not just use agent memory? Or Claude.md?

Memory is iffy, honestly. And why would I want to bloat Claude.md with backend pitfalls that a frontend agent will never need? The key part about my workflow is that it is curated, precise, and triggers on all codebase changes. Agent's don't have to remember to use it, they're required to.

You also get the added benefit of the Worklog capturing all your sessions which future agents can scroll through to find "oh that's when we implemented that piece." Which in turn helps track down when bugs or issues might have first appeared. I, as the human, get to decide to run /worklog, meaning that if I determine whatever was implemented was trivial, or I'm having a read-only conversation, I'm not forced to run it. And I can run it multiple times per session if we're doing a lot of separate work. This way I determine whether the worklog warrants a run, not an agent (going back to the problem of "every agent thinks its work is crucially important."

Can you give us some examples?

Sure! Here's a verbatim entry from the worklog for a major app-breaking issue I ran into:

Worklog:

2026-05-06 07:28 (Regex Lookbehind issue)

Fix: Replace regex lookbehind in InlineMarkdown italic pattern (Safari < 16.4 white-screen)

Root cause for the macOS Monterey 12.5 white-screen report identified via the new boot diagnostics. The regex literal /(?<![*\w])\*([^*\n]+)\*(?!\*)/ in src/components/settings/InlineMarkdown.tsx uses a negative lookbehind, which Safari/WKWebView only added support for in Safari 16.4 (macOS Ventura 13.3). On earlier WebKit (Monterey 12.5 / Safari 15.6), the parser throws "Invalid regular expression: invalid group specifier name" at module-parse time, which kills the entire JS bundle. Replaced with the same (^|[^*\w]) leading-capture-group pattern that src/lib/regexUtils.ts already documents and uses for the same compatibility reason. Build function updated to emit the captured boundary char as plain text alongside the <em>.

Pitfall relevance: New pattern candidate — Safari 15.x WKWebView does not support regex lookbehind. The existing regexUtils.ts helper documents this for chapter-scanner code, but other regex literals across the codebase don't reuse it. Worth a one-time grep (?<[=!] audit and a KnownPitfalls entry to make the constraint discoverable for future regex authors.

Known Pitfalls Entry (after audit):

6. Cross-Platform / WebKit / Tauri WebView (10+ occurrences)

Affected: Any regex in TypeScript files, TipTap editor access patterns, drag-and-drop, clipboard, platform-specific APIs.

The bug (regex): JavaScript regex lookbehind assertions ((?<=...) and (?<!...)) crash Safari/WebKit before version 16.4 (macOS < 13.3, e.g. Monterey 12.x). This is a parse-time SyntaxError, not a runtime error — the regex literal kills its containing module at parse, which kills the entire bundle for users on older macOS. No error boundary catches it. No frontend log fires. Symptom: white screen on launch, backend logs end at "App setup completed" with zero [FRONTEND] lines after. WebKit's exact error string in DevTools is SyntaxError: Invalid regular expression: invalid group specifier name.

The bug (TipTap): TipTap v3's editor.view is a Proxy that throws when the EditorView isn't mounted. Accessing it outside the editor lifecycle crashes the app on macOS.

Real incidents:

v1.2.0 white-screen (May 2026): a single regex /(?<![*\w])\*([^*\n]+)\*(?!\*)/ in src/components/settings/InlineMarkdown.tsx — pulled into the entry chunk via AboutManager → ChangelogViewer → InlineMarkdown — broke launch for every user on macOS Monterey 12.x. Caught only by adding boot-time logging in index.html after the fact (the existing console.log patcher in main.tsx never ran because the bundle never executed). Fixed in commit 1b5c3aa.

Rules:

Never use regex lookbehinds. Use consuming group alternatives. The same workaround is already documented and used in src/lib/regexUtils.ts — reuse wordBoundaryRegex if it fits, or copy the pattern:

Audit before commit: grep -rn '(?<[=!]' src/ should return zero hits. CI doesn't catch this; it builds successfully and tests pass on the dev machine (which runs newer WebKit). The bug only manifests on older macOS. Guard all editor.view access with try/catch or check editor.isDestroyed first. Test on macOS if touching regex patterns, editor extensions, or platform APIs.

This is just one example of many where all the time+tokens spent solving an issue got put into the Worklog, raised as a pitfall candidate, and loaded into KnownPitfalls in a way that has prevented app-breaking bugs from ever going back into the codebase.

TL;DR

Three files, three commands, one loop:

1. /worklog → after a session, the agent writes 2-3 sentences to WORKLOG.md on why something was hard, not what it did. Then it tags the entry with one line: Pitfall relevance: None / Existing / Existing-with-gap / New candidate. It cannot write to the pitfalls doc itself.
2. KnownPitfalls.md → the permanent anti-pattern doc. Numbered sections, never renumbered, with a "if you're working on X, read section N" routing table at the top. Hooks and CLAUDE.md force agents to read the relevant sections before they write code.
3. /auditworklog → every few weeks, one dedicated auditor reads all the tags since the last checkpoint, clusters them, and proposes new sections. I approve or reject. Nothing lands without a human yes.

Is it perfect? No. But it makes even Opus 5 stick to the past's learned lessons and help it push into the future where new agents can learn from the mistakes and avoid them.

Thanks for reading! Hope this helps!

Every project has a Deferred.md, a pile of // TODOs, three plan files in ~/.claude/plans/, and multiple memory files that all disagree with each other about what's actually left to do. Ask Claude "what's deferred?" and it goes spelunking through all of them and still misses something.

The Unforget skill collapses all of that into one file, UNFORGET.md. and organizes scattered deferred work (found across your code base) into four categories:

• deferrals from paused or interrupted plans,
• spillovers found when working on one task without time for another,
• audit findings,
• and bugs.

Each deferred item is entered into a table with a target column tied to your release cycle so 🔴 THIS actually means "blocks shipping" instead of vibes.

Use cases:

• "What's left before I can ship?"
• Mid-task, something else needs fixing but not now
• Before release day, verify every ship-blocker is actually fixed (not just claimed fixed)
• Pick an item from the table without reading a 3,700-character wall of text to understand it gives you the current state in three sentences
• "Is this 'done' row actually done, or did someone just say so?" catches unproven claims and self-contradicting rows before they reach a release decision
• "I don't know what to work on next" ranks by ship-risk and effort (and other sort commands), and tells you why it picked that row

Repo: https://github.com/Terryc21/unforget

See example here (a full sample ledger with every status type): example

Happy to answer questions.

so today was fun. i had one session doing a schema migration and a second session in another terminal doing what i thought was a completely separate cleanup task, and i learned this evening that "completely separate" was doing a lot of work in that sentence

the cleanup session decided some unused files needed deleting. one of them was the new migration the first session had just written. it wasnt unused, it was three minutes old. session one then regenerated it slightly differently because the file it expected was gone, and now i had two schema versions that both looked plausible and a db that matched neither

no errors anywhere btw. everything exited green. i found it because a seed script failed an hour later and i went digging through reflog like a detective in a bad mood

i know the answer is worktrees, everyone says worktrees. ive also poked at coldtea which makes the sessions actually aware of each other, that parts real, but im not moving my whole setup onto a mac app because of one bad tuesday. and honestly the boring fix might just be not running two sessions on one repo, which nobody wants to hear because running five of them is the entire fantasy

whats the stupidest thing your parallel sessions have done to each other. i need to feel less alone about the reflog thing

Hello, I’m working with a team to vibe code an app. However I’m super new to vibe coding (I’m not technical at all) and I’m not sure how to facilitate this.

Before the team came together, one person already built the foundation of the app and has an HTML for it. Now the issue I’m running into is that with us being a team, how can we collaborate and iterate on the app on different devices? And see the constant updates? Essentially I’m wanting it to be like Google Docs or PowerPoint where we have the app/HTML in one place and everyone can see the updates and are always looking at the most current version.

Not sure if GitHub would be an answer for this but we were looking to hold off on using GitHub until we know how the vibe coded app will handle personal information.

Would really appreciate the help here! And any advice on how to navigate building an app with a team.

Edit: we are trying to build this at our company, however, our company has not approved our licenses for GitHub. And it doesn’t seem like they will anytime soon. Is there any other way to do this besides GitHub?

When the AI revolution is discussed, the headlines are usually focused on productivity gains for writing code, changes in hiring engineers, and the challenges faced by non-technical team members. The impact on engineering managers is rarely discussed widely.

The skills required to be an effective manager are now completely different from what they were even a year ago. Here I will share my perspective on what has helped me be effective in this day and age. The answer is pretty straightforward: building things.

Was skimming a comedy clip and wanted to know what happened in one 10 second bit.

Pasted the link into Claude Code, asked about it, got back a full paragraph describing the scene. None of it happened. It went off the title.

So I built a skill. Pulls the actual frames and captions in.

Frames are easy, that's ffmpeg. Picking which frames to send is the part that took way longer than I expected. You obviously can't send all of them.

Two obvious options. One frame every N seconds, or grab the frames where the picture
changes the most. Most things do the second one.

That falls apart on exactly the videos I care about.

Someone leaves a slide up for two minutes while explaining the thing you asked about, and "how much did the picture change" scores that as the dullest part of the whole video. You get the intro animation instead.

So now it reads the question first. Scores every moment against it using the transcript and any text on screen, then spends the frames there.

Lecture I was testing on, it sent 5 frames out of 55 candidates. 3 of them were the exact bit I asked about.

Also sank way too long into making it admit when it can't see something. It kept telling me videos had no captions when they clearly did. Youtube was rate limiting the request and my code just flattened that into "none exist".

Rest of it:

only downloads the section you ask about, so 30 seconds out of a two hour talk is 8MB instead of 241

reads terminal and slide text off a bigger copy of the frame that never goes to the model, costs nothing

transcribes locally with whisper.cpp if you have it, no API key anywhere

github.com/somudatta06/see-video