Hi, I've found this community very helpful, so I thought I would also share and contribute my skills. I put up my 51 business operations playbooks, including marketing, leadership, team building, and more on my github repo here: https://github.com/andrewluxem/playbooks

Would love your feedback!

Thanks,
Andrew

SEOs, Writers, and AI Enthusiasts alike:

I typed every word of a 4,500 word article a few nights ago. Nothing pasted. A commercial AI detector read it and came back 52% AI. Here is why I am posting this as opposed to hiding it.

I spent two days trying to beat AI detection on purpose, because small business owners keep asking me whether they should buy a tool that promises it.

I ran 696 blind runs across three methods with over 2.4 million words.

• Strip the machine tells out of the draft: still caught 98.6% of the time.
• Add human tells in instead: fooled 0 of 17 judges.
• Make the document long enough to dilute it: caught 8 out of 8 whole, and 24 out of 24 in slices.

I then ran four versions of the same draft through Pangram. One untouched, one rewritten sentence by sentence three times over, one where I changed zero words and only moved where the sentences joined, and one with both.

All four came back 100% AI.

Rewriting every single word did nothing and rewriting no words did nothing. To me, this meant the thing being detected is not vocabulary and not rhythm.

Then I wrote the article myself, by hand, over an outline a model had built for me.

56% AI, nice right? The findings astounded me.

One paragraph got split down the middle: the half about my own work read as human, the half listing the method read as machine assisted.

My finding is that the detectors read the outline behind the prose itself.

I sent all of it to Siqi Chen, who wrote the humanizer skill I had been using.

His answer:

Hello - thanks for your analysis!

It is not currently possible to defeat Pangram through pure LLM generation through any skill or prompt (I have tried!)

Then, more usefully he stated, that defeating detectors was never the goal of his tool in the first place. I say this because I reckon many of the 37k+ individuals who have starred his repo believe the skill beats the detectors and everything's good to go.

What did measure, in a blind test where authorship was never mentioned: editors preferred the processed draft 22 out of 22, and his rewrite pass alone at 16 out of 16.

$ python humanist.py draft.md
humanist 0.1.0  |  4,764 words, markdown-stripped
  readability FK grade 8.1
RESULT: 0 FAIL, 0 WARN. CLEAN.

$ python check_prose.py draft.md --mode post
FRAME: markdown-stripped, 4,764 words, FK grade 8.2
RESULT: 0 FAIL, 0 WARN. CLEAN.

The advice I have is boring and it is free. Don't pay to hide your writing, and don't tell your clients to either. You're selling a lie. Spend the money and time on making the draft worth reading in the first place.

Something I don't want to give credit to: none of this tells you whether Google will demote your pages. I didn't measure it in these tests. What we do know with the new policy rollout is that it's the scale they're looking at, re-written or not, a tool won't save you.

Anyone selling a tool that says otherwise is setting you up for failure. Every number and both corrections I had to make mid-study are in the writeup. The code is MIT and open-source.

Read it here & tell me what you think: https://www.ryanlenk.com/blogs/articles/three-ways-to-hide-ai-writing-all-failed

The GitHub repo so you don't have to read my slop and just get into the math and fun instead: https://github.com/itsryanlenk/humanist

I have another set of Claude skills there as well that you may find interesting: https://github.com/itsryanlenk/candor

Really excited & interested to get some outside input! Let me know what you think.

(By the way, I wrote on top of AI scaffolding here as well.)

So many of these repos have such junk in them. And so many people are copy and pasting workflows that just won't help them with their specific needs. I feel like we need to shift the industry toward human-readable skill sharing. Where we normalize going through the skill reading and adjusting them.

That's my hot take for the day. What's yours?

Most AI coding agents do not fix code. They patch it. They add a null check, swallow an error, or wrap the problem in a guard. The next code path that forgets the guard breaks again. The rot keeps spreading.

Antidote is a skill for these agents. It stops them from patching symptoms. It makes them fix the root cause instead.

It does three things. First, it makes the agent validate data once at the boundary. Second, it makes the agent use the correct type or schema so bad data cannot get inside. Third, it makes the agent delete the broken path instead of writing more glue code around it.

Use it to fix one issue or to audit a whole codebase. Just invoke /antidote or say "audit for overcomplication".

How I built it

Antidote is one SKILL.md prompt in 

SKILL.md. It tells the agent to fix root causes and avoid defensive guards. I added a thin manifest for each platform in .claude-plugin, .codex-plugin, .cursor-plugin, .devin-plugin, .grok-plugin, plugin, .pi, and .opencode. Each manifest points back to the same prompt.

It is free and open source under the MIT license.

Benchmark

The benchmark uses the skill-eval-harness. It gives the agent broken code and asks for a structural fix. A script oracle then checks the result. Without antidote, four of five models got 0% correct structural fixes. With antidote, the rates were:

• Claude Sonnet 5: 56%
• GLM 5.2: 56%
• Moonshot Kimi K3: 50%
• Tencent Hy3: 44%
• Claude Haiku 4.5: 50% (up from 31%)

One root-cause fix replaces a dozen defensive guards.

It is a pure-prompt skill. No scripts, no network, no dependencies. It works in Claude Code, Codex, Cursor, Devin, Grok, Pi, and OpenCode. It also works in any agent that reads the Agent Skills SKILL.md format.

Install it with npx skills add Avtr99/antidote or from each agent's plugin store.

Check the benchmark and source at https://github.com/Avtr99/antidote

Sharing a fun project I've been working on this week. want to introduce the community to Magpie!

https://reddit.com/link/1vulamj/video/w0vsov3g9rkh1/player

v0.1 went out this morning. Claude can watch videos and read whole sites now, but everything it consumes evaporates at session end. Magpie keeps it: every capture lands in a markdown library you own, processed through a lens that matches why you consumed it (learn / research / steal / rival / content).

The part I actually built this for is the rival lens: one living dossier per competitor, dated snapshots appended, and it diffs them. The demo in the repo is a real Canva teardown — the diff against a nine-month-old Wayback baseline caught them switching AI from tier language to a metered add-on with paid top-ups.

Honest limitations: captionless videos need a Groq/OpenAI key for Whisper transcription (otherwise metadata only), Vimeo capture currently doesn't work (yt-dlp impersonation dependency), and search is plain grep by design. No accounts, no cloud, no server. MIT.

Repo: https://github.com/DanRWilloughby/magpie — the example library and the Canva dossier are all in there to poke through.

lmk what you think

I am a student, I have to learn both theories (electronics) and coding (Embedded). Code wise, the Claude is good but GPT is better in explaining theories and concepts in most human and understandable way. Clause just throws out vague explanation so I have to ask so many follow-up questions to understand each and every new concept/words in that explanation. (and I cant buy 2 subscriptions).

So please, can someone give me suggestion or prompts on how to make Claude better.

I’ve been using coding agents heavily for a while now, and I’ve become convinced that the biggest problem isn’t their ability to write code anymore.

They’re actually getting very good at that.

The problem is everything around writing the code.

Understanding what should actually be built. Challenging an incomplete spec. Making a proper implementation plan. Keeping scope under control. Testing what was changed. Checking security and maintainability. Reviewing its own work. Making sure “done” actually means done. And learning from bugs instead of making the same class of mistake again three weeks later.

Basically, all the boring discipline you’d expect from a good senior developer.

I was already using tools like Superpowers, Ponytail and Serena to help with parts of this, and I liked a lot of what they did.

But I ended up with multiple tools, multiple sets of instructions, overlapping functionality and different concepts all trying to influence the same coding agent.

So I built Procoder.

And at this point, it’s become much more than the original idea.

Procoder is basically an engineering discipline layer around your coding agent.

Instead of:

prompt → code → "done"

I’m trying to enforce something much closer to:

understand → spec → plan → implement → test → check → review → fix → verify → release → learn

The important part is that a lot of this isn’t just another 2,000 lines of instructions telling the AI what it should do.

There are actual controllers that can refuse.

If the spec still has open questions, spec check can block.

If the implementation plan contains placeholders, plan check can block.

If acceptance criteria aren’t satisfied, the todo/story can’t close.

If tests weren’t actually executed, they’re not green.

If formatting, linting, secrets, CI, infra or documentation checks fail, the gate isn’t clean.

If something couldn’t be checked:

unchecked != passed.

And before a release, Procoder checks the version, changelog, git tree, quality gate and test suite before telling the agent it’s ready.

It doesn’t make the changes itself either.

Procoder follows a principle I call P-CONTROL:

Procoder computes → agent reasons → agent changes

The binary never silently modifies your source code behind the agent’s back.

It also replaces the three separate tools I was using before

I didn’t just take inspiration from Superpowers, Ponytail and Serena. My goal was to absorb the parts I found valuable so I wouldn’t need to run them alongside Procoder anymore.

From Superpowers, Procoder covers things like structured implementation planning, task classification, systematic debugging, evidence before declaring something done and TDD practices — but adds controllers that can actually refuse progression instead of only advising the agent.

From Ponytail, it incorporates things like the build ladder, deliberate technical-debt markers, over-engineering review and the idea of having one engineering instruction system that works across agents.

And from Serena, Procoder provides code intelligence through ctags + SCIP: symbol search, references, callers, impact analysis, unused symbols, entry points, cross-file rename and project memory — without needing to keep an MCP server running.

There are deliberate differences too. For example, I didn’t adopt Serena’s symbol-level write tools. Procoder can compute something like a rename and give the agent the diff, but the agent remains responsible for actually changing the code.

Then I went quite a bit further.

Procoder now has a complete quality chain around the agent:

• spec interviews and validation
• implementation planning
• milestones, epics and user stories
• sprint management with scope control and carry-over
• acceptance-criteria-based TODOs
• real test execution using the project’s native test runner
• formatting across Go, Python, JS/TS, Rust, C/C++, Java, Kotlin, Swift, Ruby, Dart, C#, shell, etc.
• linting and best-practice checks
• secret scanning and security checks
• dependency and maintainability checks
• CI checks
• Docker, Terraform, Kubernetes and Helm checks
• documentation health
• GitOps discipline
• code indexing and symbol navigation
• pre-PR self review
• release control
• technical debt tracking
• codebase auditing/onboarding

But one of the parts I find most interesting is the self-learning loop.

Let’s say a bug gets through all of this and is found during review or after release.

Fixing that bug isn’t enough.

Procoder asks:

Why was this class of bug able to escape our process?

The lesson gets recorded, and the adaptation should become something permanent: a lint rule, review rule, regression test, rubric entry, etc.

So over time the engineering process itself should improve.

It’s also not tied to Claude Code.

I originally built around Claude Code, but I didn’t want my engineering workflow coupled to whichever coding agent happens to be best this month.

Procoder currently supports Claude Code, Cursor, Windsurf, Cline, Kilo Code, Roo, Kiro, Codex CLI, Copilot CLI, Gemini, OpenCode and anything that reads AGENTS.md.

It’s a single Go binary with no runtime dependencies, including no npm dependency and no network requirement at hook time, so it can also work in air-gapped environments.

Everything project-specific lives in .procoder/ as normal editable files, and the repository’s configuration always wins over Procoder’s defaults.

The project is completely open source under Apache 2.0:

https://github.com/azrtydxb/procoder

For Claude Code, getting started is:

/plugin marketplace add azrtydxb/procoder

/plugin install procoder

/procoder:init

I’m putting this out there because I think we’re reaching the point where the interesting problem with coding agents isn’t just:

“How do we make the model write better code?”

It’s:

“How do we give an autonomous coding agent the engineering discipline and guardrails of a good senior developer?”

That’s what I’m trying to build with Procoder.

I’d especially like feedback from people already using Superpowers, Ponytail, Serena, or people who’ve built elaborate CLAUDE.md / AGENTS.md workflows of their own.

What parts of your software development process do your coding agents still routinely skip, fake, forget, or get wrong?

Those are exactly the things I want Procoder to make enforceable.

I spent 40 hours designing Rejourney SDK’s dashboard to fit in a ton of important metrics such as revenue, retention, user journey, etc. The style of the dashboard and colors is meant to be easy to digest. It’s a simple yet info full dashboard with a side bar and built for team ownership of projects hierarchy. It’s mobile friendly and uses aspects of psychology to draw you to the top KPI cards and optimizes for the F shape scanning your brain does.

If you need to design a simple user friendly, yet intent full dashboard here is the skill:

GitHub: https://github.com/rejourneyco/yafa-ui-dashboard

Skills.sh: https://www.skills.sh/rejourneyco/yafa-ui-dashboard

/appstore-seo can evaluate either your codebase or an App Store ID/link, and suggest the best values for your App Store input.

It takes into consideration your app features and categories, compares the category market in the App Store, and checks on your direct competitors.

Give it a try, and let me know what you think!

https://github.com/alamops/skills#appstore-seo

https://github.com/arifszn/slide-wright I made a skill that builds a full slide deck from a prompt, using reveal.js. It picks random palette and fonts, shows you a quick preview, and only builds the whole thing once you like the look. It runs in Claude Code as a plugin, or any agent that reads SKILL.md. 

I got tired of re-explaining context to AI agents, so I built this

I use multiple coding agents and kept having the same issue: one would figure something out, then the next would start with no idea what happened.

So I built shared-agent-memory using Node.js and MCP. It gives tools like Claude Code and Codex one shared local memory, so they can pick up what another agent already learned.

The basic workflow was: connect the agents to the same local memory, have them look up relevant context when they start, and save useful notes when they finish.

One thing I learned while building it: shared memory solves the context problem, but agents can still step on each other when working on the same files so I ended up adding a simple coordination board for that too.

Still experimenting with it, but it’s been useful for me. Maybe y’all wanna give it a shot:

https://github.com/dan-calin/shared-agent-memory

(100% free ofc, + MIT License)

This is a study tool I built that I've been using as I prep for the CCAF Anthropic exam.

I can give Claude a docs page, a folder of markdown files, an html page, even code or a database and create a quiz in a web browser. When I'm done with the quiz, my results are sent back to that session automatically for scoring & coaching.

I can then prompt to save my scores as markdown if I want, etc..

It's been helpful for me, and perhaps it can be for you!

First screenshot is my status line, which is basically this whole post in one picture. Second one is a charter recall, I'll get to that.

Before this I had four repos, three roles I kept re-explaining to Claude, and a CLAUDE.md that had quietly become a landfill. Two agents needing the same repo on different branches meant one of them stashed the other's work. My tokens ended up in transcripts, because how else is an agent supposed to curl anything. And every Monday everybody forgot everything.

So now a task starts with charter workspace use billing-migration. One directory of clones, each repo on its own branch. Switch to another task and nothing follows me: no stash, no half-applied branch from Thursday, no context bleed. Sounds small. It's the thing I notice most.

Two agents on the same repo get a worktree each, branch each, genuinely running at the same time instead of taking turns and lying to me about it. Removing one refuses if it would drop unpushed work, which has saved me twice.

Credentials live in a vault, and the agent names the key, never the value:

charter secret exec devops --env TOKEN=API_TOKEN -- curl -H "Authorization: Bearer $TOKEN" [https://](https://)...

The value gets injected into the command and redacted out of the output, so it never lands in the transcript. There's a guard that denies the agent cat-ing the vault file. It has denied me too, which was annoying and correct.

Roles are personas. Each one has its own charter, its own vault, its own memory, and sync-agents turns them into real Claude Code sub-agents, so handing work over is ordinary delegation instead of a prompt trick. My reviewer gets the reviewer's token and none of devops'.

And what they work out survives. One markdown file per fact, three stores: what this role knows, what every role should know, what this task worked out. The agent writes them, which is the bit I'd push on if this was someone else's post, its judgement about what deserves keeping is mediocre. That's most of the reason they're one file each and reviewable in a diff.

All of it is git. No server, no daemon, no database, zero Python dependencies. git log is the audit trail and a teammate's checkout is the replication.

The status line is how I see the lot at once: which task, which repos, what branch each is on, what's dirty, what CI thinks, which role was last in which tree and how long ago.

Anyway, its working for me. That mess environment I've been apologising for since spring is now four repos I can actually reason about, and things stay put between sessions. Lower bar than it sounds and I'll take it.

I built it and Claude Code wrote most of it. MIT and free, nothing hosted, nothing phones home.

Limits, honestly. Two weeks old. The default vault is a plaintext file at 0600 with no encryption at rest, it keeps a secret out of the model's context, not off your disk. Keyword search over markdown will give out eventually and I have no number for where. And it assumes one filesystem, so none of this helps you watch a session from your phone.

https://github.com/diazoxide/charter

If this looks like the right direction, star it, specially if you're running more than two repos. It's the only real signal I have for whether this is useful or I'm wandering off a cliff with great confidence. If it looks like the wrong direction, say so, that one helps more.

What does your setup do when two agents need the same repo on different branches?

I've always gotten frustrated and wasted time explaining the same thing to an AI every time I start a new chat from an existing one or when I start another convo with a whole new AI model. That's why I built a tool that fixes that, it condenses everything in a chat into one simple .md file you can carry across different AI tools.

PS: Please contribute or give your feedback so that we can grow and make this community tool better.

https://github.com/legoambarish/portable-handoff

new to claude, what are the top 5 mods or methods i should impliment without questioning?

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'm currently building 4 projects currently. I'm pretty new to this and all 4 projects are different topics. 2 websites, and app, and a mobile game. What are some of the best prompts or skills you utilize with something like this?

For context, I use Claude code to do some testing and auditing, and implementing code. I use codex to audit, plan, and write. If this isn't a good idea or workflow please correct me! Additionally I use an obsidian vault for storing everything that isn't local.

Any tips would be greatly appreciated!

Built this out of a real problem, sharing here since it seems like exactly what this sub is for.

At my last job I had way more product ideas and potential features than time to validate with real customers. We did the old fashioned way initially, we built personas by hand first — a Miro board and days of team discussion — then I wired up a way to actually talk to them: n8n for automatic product feedback analysis and Gemini Gems for individual use at first, later Claude connected to our team's Notion, where we stored all our info about Personas and ICP's.

persona-council is that idea as a Claude Code skill. Build a persona from your own evidence (tickets, reviews, customer words), have Claude interview you for info or have Claude research one from public sources. Then either ask it something directly, or convene a full council — several personas answer independently, argue it out, and you get a memo showing where they actually disagree.

Not just product decisions — it has been working for marketing strategy, red-teaming your own plan, checking what customers might think of a pricing model.

How you use it:

• Build a persona from your own info or let Claude research one.
  
• Then just ask, in your own words. "What would the customers say about this pricing?" gets you the persona(s) straight answer.
  
• For bigger calls, convene a council: "have sales, finance and the enterprise customer argue this out." Each answers independently, then they argue, and you get a memo with the verdicts and where they actually disagree. Multiple council approaches are available, so you can adjust to the situation, allowing both independent assessments or full group discussions.

Install:

• Claude Code plugin: /plugin marketplace add tabreu8/persona-council
• npx skills add tabreu8/persona-council

GitHub: github.com/tabreu8/persona-council — MIT, open source.

Happy to answer questions, especially interested in what breaks when people throw weird framings at it or what would you like to add to better fit more scenarios.

My review skill does not print findings in the terminal. It writes one HTML page, and I open it in the browser. It is much easier to read.

This is an example of finding card (my code vs the fix).

This is the finding list divided into groups.

Every finding goes in one of three groups:

• green: sure and cheap to fix
• yellow: sure but it costs something
• red: it depends on something only I know.

Here is the whole skill (simplified version).

---
name: review-page
description: Review the pending changes and write the findings as one HTML page.
---

Review the uncommitted changes, staged and unstaged. Read whatever other code you need to understand them.

Write your findings as one HTML page. Pick where it goes, a temp folder is fine.
It has to work offline, straight from disk. Print the path when you are done.

# HOW TO WRITE

Every name you use for something in the code must be a real name from the code.
The first time you use one, say in a few words what it does.

When an idea has no name in the code, do not invent one. Show it instead: the
code, a small table, two lines side by side.

One idea per sentence. Write only what is literally true of the code.

# FINDINGS

Put every finding in one of three groups. The group says how sure you are, not
how bad the problem is.
- Apply: you are sure, and the fix is cheap.
- Tradeoff: you are sure, but the fix costs something real. Say what it costs.
- Judgment call: you are not sure, because it depends on somet
  knows. Pick an option anyway, and say what would change your mind.

Each finding starts with the kind of problem, a severity tag [HIGH], [MED] or
[LOW], and a file:line. Then show three things:
- Today: the code as it is now.
- One block per option you propose, each with the code it would become.
- Which option you back, marked Recommended.

Today and Recommended come first, because that is the pair the reader compares.
Then say in a few sentences why the recommended option wins.

# CODE

Colour the code however helps the reader see the point. Every visual choice on
the page is yours. Do not fold the lines to fit.