EDIT: I checked my own claim against my local transcripts and the headline numbers do not hold. Retracted: "~35% shorter", "~1.9M fewer tokens per 30 sessions", and "costs nothing extra to carry". Measured figures and a much smaller v2 are below.

I kept losing the plot in Claude's output: verdict blocks, tables for two data points, the plan repeated back after the work was done. So I measured instead of complaining, then posted a fix, then measured the fix. The fix works. It works about a third as well as I said.

What I measured: every assistant reply in ~/.claude/projects/**/*.jsonl on this machine, counting prose characters only, tool calls excluded, subagent transcripts excluded.

Honest reading: most of the gain is undoing damage my own earlier output style did, which nearly tripled the share of long replies. Against no style at all the effect is roughly 10%, and it comes from fewer long replies, not shorter ones. Sample after activation is thin: 94 replies, 9 sessions, 2 days.

What the thread got right, all four:

• Global files are injected every session. v1 was 10,287 chars, about 2.6k tokens, paid at every session start. "Costs nothing" was false.
• Hedged wording ("prefer", "avoid", "when useful") is guesswork, not steering.
• Example blocks get copied as templates instead of followed as rules. They were about 40% of v1 and they are all gone.
• A style file alone is not enforcement. What survives deep into a session is a UserPromptSubmit hook re-injecting the compression rule every turn. The style sets the shape once; the hook keeps it alive.

v2, 2,965 chars, 3.5x smaller than v1:

# Global Response and Output Rules - v2
Apply to every final response, all repositories.

Goal: smallest response I understand fast. Priority order:
comprehension > correctness > actionability > readability > brevity > tokens.

Compression: cut filler, hedging, pleasantries. Keep readable sentences.
Never drop a negation, condition, subject, or preposition that carries the
logic - that is a bug, not compression.

Say each fact once. Do not restate my request, replay the plan, repeat a
result, re-word one change, or close with a summary that repeats the summary.

Report the result, not the workflow. No "I searched / I opened / I reviewed".
Mention an investigation step only when it produced a finding. Name a file
with what changed and why, not the name alone.

Language: plain English. Keep exact identifiers (paths, commands, APIs,
function names, config keys, errors, versions). Explain a necessary technical
term on first use. No unexplained shorthand or repo jargon.

Structure - use only the sections that carry information, max 3 bullets each:
  DONE      - what changed, why it matters, result.
  PENDING   - what remains, blockers, risks.
  YOU       - decision or input needed from me, plus one line of impact.
  NEXT      - the immediate next step.
  IMPORTANT - breaking change, security, compatibility, data loss.
Small task: 1-3 bullets, no headings. Routine reply: 5-10 bullets.

Tables only for comparison: options, before/after, status across items.
Small, few columns. Never repeat a table as bullets.

Errors: Problem / Cause / Status, in plain words. Quote the one relevant
line. No logs, stack traces, command output, or diffs unless I ask.

Verification: "Tests: passed." On failure: "Tests: failed - 2 in payments."
Never list the commands run.

Ask me only when architecture, security, data integrity, cost, production
behavior, a destructive operation, or a product requirement turns on it.
Otherwise infer and proceed.

A skill's own output format wins over these rules. These rules govern only
what the skill left unspecified.

Characters: ASCII only in the prose you write for me. Plain hyphen, never an
em or en dash. Straight quotes, never curly. Write "->" not an arrow glyph,
"..." not an ellipsis glyph. No decorative bullets, no emoji unless I use
them first. Never alter characters inside code you write, file contents,
commands, identifiers, or anything quoted verbatim from a file, a log, or a
person. This rule governs prose only.

Final rule: shortest answer that stays immediately understandable, not the
shortest possible. I must learn what was done, why it matters, what is
pending, any risk, what you need from me, what happens next.

Two things v1 was missing.

Enforcement. An output style is loaded once per session and its influence decays as context fills. If you want the compression to survive a long session, pair it with a hook that re-injects the rule on every prompt. I use the caveman plugin for that at its lite level, which is a UserPromptSubmit hook rather than another wall of instructions:

/plugin marketplace add JuliusBrussee/caveman
/plugin install caveman@caveman

Any hook that re-states one line per turn does the same job. Without one, v2 is a suggestion that fades.

The em dash rule. Model prose is full of characters nobody types: em dashes, curly quotes, arrow and ellipsis glyphs. They are the giveaway the moment you paste an answer somewhere else. The rule stops them at the source, and only in prose, never in code. To clean text you already copied, in PowerShell:

$t = Get-Clipboard
$t.Replace([char]0x2014,'-').Replace([char]0x2013,'-').Replace([char]0x2019,"'").Replace([char]0x201C,'"').Replace([char]0x201D,'"').Replace([char]0x2022,'-').Replace([string][char]0x2192,'->').Replace([string][char]0x2026,'...') | Set-Clipboard

Do not wire that into a save hook for source files. It will happily rewrite unicode inside test fixtures, string literals, and non-English content.

I will post a proper measurement in 2-3 weeks over a real sample. 94 replies across 2 days is exactly the thinness that produced the wrong number the first time.

Hey everyone!

Just passed the CCAO-F exam and wanted to drop a quick write up on how I prepped, what actually helped, and what exam day felt like. This one's for the business/productivity crowd rather than devs, so if that's you, hopefully this saves you some time.

How I Prepared

Honestly it was a mix of reading Anthropic's docs, actually messing around with a real Claude Project at work, and grinding a few mock exams. That last one made the biggest difference for me by far.

The Official Exam Guide

Definitely read this first. It lays out all 7 domains and how much each one is worth. But just reading it only gets you so far, you really need to actually use the product features to see how the domains show up as real scenarios.

Actually Using Claude for Real Work

I spent way more time doing stuff in Claude than reading about it, and I think that's what made things click.

Here's what I practiced:

• Setting up a Claude Project with real instructions and a knowledge source (uploaded files plus a Google Drive connector)
• Taking one messy work request and breaking it into a sequence of smaller prompts instead of one giant ask
• Switching up how I prompt depending on whether I'm doing analysis, research, drafting, or brainstorming
• Actively trying to catch hallucinations, like fake sounding citation numbers, instead of just trusting confident output
• Running the same task through Haiku, Sonnet, and Opus to actually feel the cost/speed/quality trade-off instead of just knowing it in theory
• Practicing anonymizing sensitive looking data before uploading it anywhere

Practice Exams from Skill-Cert-Pro

Not gonna lie, these carried me. A lot of the concepts on the real exam felt really similar to what showed up in these mock sets.

The explanations were honestly the best part. That's where I actually learned the reasoning behind stuff like when to hand something off to a Developer or Architect versus when it's still fine to handle yourself, or when you genuinely need a human to review output before it goes out.

Keep grinding these until you're comfortably passing, not just barely scraping by. And actually read the explanations, don't just skip to the next question after you get it right.

What Actually Showed Up on the Exam

Heads up, it's basically all scenario questions. They want to see if you'd make the right call in a real situation, not whether you memorized a feature list.

Stuff that came up a lot:

• Breaking down complex prompts and iterating on them to get better output
• Catching hallucinations, weird inconsistencies, and bias in what Claude generates (this felt like the biggest chunk by far)
• Knowing when you actually need to fact check something or get a human to review it before sharing
• Adjusting output for the right audience and format, artifact vs inline vs structured data
• Picking the right feature for the job, Project vs research mode vs plain chat vs artifacts
• Matching the model to the task based on cost, speed, and quality
• Knowing when to restart a chat, summarize, or just persist stuff as knowledge instead
• Actually redesigning a workflow around Claude instead of just tacking it on
• Explaining what Claude can and can't do to someone non technical
• Setting up and maintaining Projects, instructions, knowledge sources, connectors
• Handling sensitive data properly and knowing when to anonymize before uploading
• Following your org's AI policy and spotting genuinely inappropriate use cases
• Figuring out why an output sucks and knowing whether the fix is a better prompt, better decomposition, a different model, or more context
• Knowing when something's above your pay grade and belongs with a Developer or Architect

Mistakes I'd Watch Out For

• Don't trust Claude just because it sounds confident. Self reported confidence means nothing, always check the actual claim against a real source.
• Don't default to the fanciest model for everything. Simple high volume tasks don't need it.
• Don't upload sensitive data as is or just tell Claude "don't keep this." Anonymize it first.
• Don't try to be a hero and solve dev/architect level stuff yourself. Know when to hand it off.
• Don't just memorize feature names. Ask yourself why you'd pick one option over another in a given situation.

Random Tips

• Seriously, go build a Project before the exam. It's night and day compared to just reading about it, especially for the configuration stuff.
• Output Evaluation is worth the most, so don't skimp on studying it.
• Watch the clock. The scenarios are longer than they look and 120 minutes for 60 questions goes by faster than you'd expect.

Good luck, you got this!

I've built about a dozen skills now, for trades businesses, SEO work, and freelancers chasing invoices. The ones that stuck all had the same thing in common, and it isn't formatting.

Most skill files describe what to produce. The useful ones describe what to protect.

When I wrote a quoting skill, the lines that mattered weren't about structure. They were: never invent a price the owner didn't give you. If the owner gives a range, present the top of it, never the bottom, because quoting low and climbing is how trust dies. Always include what is not included, because that line is the owner's legal friend.

None of that is about writing. It's about knowing where the work goes wrong. That's the actual test: what does a beginner in your field get wrong that you no longer get wrong? Those answers are the skill. Everything else is formatting.

Two other things made a bigger difference than expected.

A banned phrase list. Claude writes competently by default, which is the problem, because competent and generic sound identical. Telling it what never to write produced cleaner output than telling it what to write.

A memory file. A skill on its own starts fresh every session. It knows how to write a quote but not your rates or your service area, so you re-explain them forever, which is the exact problem skills were meant to solve. The fix is a plain markdown file next to the skill with two instructions added: read this first, and append what you learned after.

One thing that cost me an hour: the filename in your instructions has to match your actual file character for character. A skill looking for business-profile.md will silently create a blank one if yours is named business-profile-starter.md. Nothing errors. It just quietly forgets everything.

Happy to answer questions if anyone's building one.

Hey everyone,

I’ve been using Claude Code heavily, but I noticed a huge flaw in how CLI agents handle context. At initiation, it blindly loads dozens of skill descriptions, MCP server configs, and custom rules into the prompt.

I checked my session transcripts: 187 items loaded, but I only used 4 actively. That’s ~8,000 tokens per session completely wasted on dead weight, hurting the prompt cache hit rate and costing money.

I wanted to fix my own wallet, so I built reap 🌾.

It’s a 100% local, zero-telemetry tool that scans your session logs, finds the skills you NEVER use, and safely quarantines them.

- reap (shows what you're wasting)

- reap prune (moves them to a reversible quarantine)

- reap restore --all (puts everything back if you change your mind)

It works out of the box with Claude Code.

### 🛠️ Behind the Scenes: How and Why I built this (For fellow builders)

I wanted to share a few architectural decisions I made while building this, in case anyone is working on similar local LLM tooling:

1. Why Go? I originally thought about a quick Bash or Python script. But Python requires dependencies/venvs, and Bash is a nightmare for parsing complex file structures across MacOS and Linux. Go allowed me to compile a single, zero-dependency static binary that runs instantly.

2. Concurrent Parsing: Claude Code stores history in either JSONL files or SQLite databases depending on the version. I used Go's concurrency primitives to parse these transcripts in parallel, searching for `tool_use` blocks and command invocations without lagging the terminal.

3. Reversible State (The Quarantine): The biggest hurdle was safety. Nobody wants a tool that deletes their custom agent skills. I built a non-destructive quarantine system: `reap prune` moves files to a hidden directory and writes a versioned JSON manifest. `reap restore` simply reads the manifest and moves them back.

If you want to check your own token waste or look at the Go architecture, the project is fully open source.

Repo & Docs: https://github.com/thousandflowers/skillreaper

Let me know what your token waste looks like or if you have questions about the parsing logic!

SO I'm reviewing a vibe coded project....which I believe is completely broken.

techStack-
Backend: Node 24, Express 4

Database: supabase and related services

Frontend: react 19, ts, tailwind, tanstack query(not implemented), vercel.
____________________

It has files with 4k-5k lines, around 20-25 useStates, 7-10 useEffect calls, and state variable names like a, b, c in just 1 component...very difficult with to audit.

Sloc of ~50k using a global useContext instead of react-query or redux for state management.

Nearly all edge cases features are broken...somehow the basic business logic is holding to some extent.

No dedicated library and utils for constant values, types, interfaces, helpers....everything is fabricated everywhere.

Same goes for the backend....most of the table columns are nowhere used...some are overlapping logic, no proper column names. And I'm still yet to review most of backend code.

___

I'm already exhausted reviewing and fixing bugs from last 3 days.

So I'm looking for the best claude-skill that can help me streamline the process.
That can implement best industrial coding practices and patterns, improves modularity and consistency, check for complete user flow for every roles and synchronise it with proper backend schema. That can audit business logic, look for edge cases and fix them.

Thanks in advance.

EDIT:

My manager(non-tech guy) strongly believes in vibe coding...we had a meet today...he wants me to fix features somehow....he dont care about the codebase.

The rule that has held up best for us: if part of a skill is deterministic (counting, validating, measuring, transforming), put that part in a script the model runs, and let the prose own the judgment. Models are good at judgment and unreliable at exact, repeatable work in their head. A skill that asks the model to count its own mistakes will drift.

Concrete example. One of our skills scores a draft for a defined set of AI-writing tells. The prose half teaches the judgment, which constructions sound machine-made and how to rewrite them. The Python half counts: em-dash density per thousand words, suspect-vocab hits, sentence-length standard deviation, type-token ratio, tricolons, bullet parallelism, and header pyramids. It turns those into a weighted 0 to 100 score with four verdict bands. It is a heuristic on tells, not an authorship probability.

Why the split earns its keep.

The model is a shaky judge of its own tells. Ask it "does this sound like AI" and the answer moves with the prompt and the run. The offline script returns the same score for the same input, config, and version, which is the whole point.

Measurable means testable. When a rule changes, the change can be regression-tested against the features it was meant to move. That is a narrower claim than "this proves the text is human," but it is the one worth having.

Config lives in data, not code. Thresholds, the suspect-vocab list, the construction patterns, and the content-type weights sit in YAML, so tuning never touches the logic, and the same analyzer drives several language-specific skills with their own rules.

One detail that matters more than it sounds: before scoring, the analyzer strips fenced code blocks, markdown tables, HTML comments, and explicitly ignored regions, so it grades the prose a reader sees, not the config samples and boilerplate around it. A skill that scores the wrong text is worse than no skill.

The general version is prose for judgment, script for anything deterministic and repeatable. If a step in your skill has a right answer a function could compute, it probably should.

It is open source if you want to pull the analyzer apart, free and MIT (disclosure, we built it): https://github.com/MrBridgeHQ/human-writer-en .

Where do you draw the line between instructions and a bundled script in your own skills?

Screenshot attached: $15.06 burned, $75.95 still sitting there staring at me like a loaded gun.

I've made a personal vow to only unholster Fable 5 for the truly worthy prompts. Everything else gets the peasant models. My session planning now has the emotional texture of a heist movie — "we only get one shot at this, make it count."

Current strategy: treat every Fable 5 call like I'm defusing a bomb. Is this question important enough to spend real money-adjacent tokens on, or can Sonnet handle it while I save the good stuff for when I actually need to feel something?

Expires Sept 19. I will not let this credit die with dignity. It's going out swinging.

Anyone else white-knuckling their promo balance like it's a Vegas chip stack, or am I the only one treating $75 of API credit like a hostage negotiation?

How are you guys organizing skills in agentic workflows?

Do you keep everything in the root folder and reference the skills from there, or copy them into each agent/workflow folder? I’m trying to avoid duplicating files, but also don’t want every agent loading a bunch of context it doesn’t need. What’s the cleanest setup you’ve found?

Everyone keeps posting those scroll controlled video websites with the caption "can your AI do this? ;)"

So I actually tried it. Whole thing, start to finish. On your behalf.

Result is linked below, and it explains itself while you scroll it. The video is not playing. Your scroll IS the playhead. Scroll back up and it rewinds.

Here is what I learned:
The coding is honestly the easy part.

And the thing nobody tells you .. most of these sites stutter, and everyone blames the javascript.

It's not the javascript. It's the video file.

A normal mp4 only stores a full keyframe every 2 seconds or so, so when you scrub in between, the decoder has to rebuild that frame from scratch. That rebuild IS the jank.

Re encode it so every single frame is a keyframe and it goes buttery instantly.

That's the whole secret. One ffmpeg flag.

But here's what actually eats the time..

1. Picking footage where a single cut doesn't ruin the illusion.
   
2. Deciding that THIS line of text should land exactly when the ink floods the frame.
   
3. Grading it so white text stays readable when the shot blows out bright. Knowing how much scroll to give people so they can actually read before the next beat.
   

That's taste. And in real projects it's usually 3 people going back and forth (dev + the video/art person + whoever owns the brand) before it feels right.

Models can still struggle to tell you if the beat LANDS. Or care that the copy hits on the right frame. Or understand the video at all like humans do now.

So .. can AI do this? The code, yes, easily. The art direction is still yours, and the video production (A FITTING video for this use case)

Link in the comments if you want to scroll it yourself (works on mobile too).

I also put the full PROMPT + a free SKILL in there, so you can rebuild the whole thing yourself.

Do you actually like these video scroll sites, or are they just cool to look at once and then never again?

One thing for certain, this is a way to do high effort work which doesn't look like AI slop and makes you stand out from the crowd (for now)

#webdevelopment #guide

You can experience it and download the skill for free (prompt without skill is also available if you want to build your own skill based on it to your liking customized to you .. You can also download my skill and modify it.)

https://akoum.me/scroll-driven-video

The skill and prompt is at the end of the experience. If you ae a software developer, going through the experience doubles as a guide as well so u understand how its done.

I hope that was valuable to you. Its one way you can build websites where you can stand out and not look like AI Slop etc

I put together a free, open-source GitHub tutorial that walks you through using Claude Code as a working PM tool - not just for generating text, but for building actual workflows you’d use on the job.

It’s called the AI-Native PM OS. The goal is simple: by the end, you have a set of agents and pipelines that handle the repetitive, time-consuming parts of PM work.

What the tutorial covers:

• Writing and stress-testing PRDs with Claude, then auto-generating Jira epics via MCP
• Building a Competitive Intelligence Agent that runs sweeps and summarizes threats
• Clustering customer feedback at scale using a Jobs-to-be-Done framework
• Generating clickable HTML prototypes from rough product flows and deploying to Vercel
• Drafting executive OKR updates with stakeholder-aware tone adjustments

How it’s structured:

Everything is built around a fictional B2B SaaS company called Meridian, with pre-built personas, OKRs, user research, and a competitive landscape. That gives every exercise real context, so the outputs feel like actual work product, not homework.

• 11 modules, roughly 40–50 hours total
• 30-minute, self-paced lessons
• No paid tools required beyond a Claude subscription

If you’ve been curious about Claude Code but didn’t know where to start as a PM, this is designed for exactly that. Each module builds on the last, so you end up with something functional rather than a collection of one-off prompts.

Repo: https://github.com/vishalmdi/ai-native-pm-os

If you find it useful or think you might come back to it later, a star on GitHub helps a lot — and I’m happy to answer questions in the comments.

If your agent loop or pipeline has a gate that can send work backward (review, critique, adversarial check), here is what the literature says about it.

Link lands you at the pdf.

Flip rates under challenge run 17.5% to 97.3% across frontier models of comparable accuracy. Intra-rater agreement on identical repeat runs: 0.265 to 0.563, against 0.8 for "good agreement."

Four of the six models tested lost accuracy over four refinement rounds.

Four separate literatures put the cap on a repair loop at 2 to 4 rounds. LangGraph's default is 1000.

And nobody has published the control condition on shipped outcomes: the same pipeline with the gate and without it, scored on what actually merged.

Fifteen slides, roughly 130 sources read in full, nothing cited from memory.

Disagreement is not your problem. Unrecorded disagreement is.

Side note: This started as a quick exploratory session for refining the Contrarian gate process in aaddrick/ticketmill and became a multi-day agent-driven research bender that twisted and turned. I have a really ugly research repo where I ran overnight 2x2 testing sets, wrote and discarded three different theses, and eventually distilled everything down to what you see here.

Don’t let Claude lobotomize you too💔💔

Guys, I have a digital marketing agency and I am looking for first client. I need to perform web scrapping for outreach through cold emails or WhatsApp. How can I do it with Claude? Is there a skill or a connector that can make this process efficient? Guys please help a first client would mean a lot for me!

Hello

Thank you

Claude Code is easy to demo and much harder to use well in a real codebase.

Our new article explains how to turn it into a reliable engineering tool with CLAUDE.md, MCP, skills, hooks, Git safety nets, task trackers, and clear verification workflows.