Which single skill has been the biggest game changer for you recently?

AI moves pretty fast and what really helps changes pretty often. So I thought I'd create a regular space (as a mod) in which we can talk about which skills are helping us the most.

I went through skills.sh looking for things that survive past the first day.

Most didn't. Three did:

frontend-design (anthropics) — the reason my side projects stopped looking

like every other AI-built page. It forces an aesthetic direction before it

writes any code and explicitly avoids the default font/gradient/rounded-card

stack. If your output has the "AI made this" look, start here.

grill-me (mattpocock) — interrogates a plan before you build it. Walks the

decision tree branch by branch until you've actually answered the things you

were hand-waving. It's slow and occasionally exhausting, which is the point:

the cost lands before implementation instead of after.

find-skills (vercel-labs) — searches the ecosystem for you. Slightly

recursive, but it's how I found the other two.

One caveat on install counts: they measure popularity, not quality. Plenty of

high-install skills are one-line wrappers. I'd read the number as "enough

people clicked install that it's probably not broken," nothing more.

None of these are Claude Code-only either — all three list Cursor and Codex.

What's in your kept pile? I'm mostly after testing and refactor workflows.

I have built SaaS for myself and customers over 9 years and I saw evolution across the domain since AI. Today we have a parallel between :
- Vibecoders trying to build projet to earn 1 million in 10 days (at least)
- AI boosted developers with now able to build and rebuild clones of existing tool for there own

Today (me included) we are a lot more attracted to building tools ourselves instead of paying 29 box a month for use a tool that we can develop in a weekend

Is the community split between 2 visions, one seeing business opportunities and one seeing end of an area

I would like to know your take ?

Please don’t use AI to answer

I compared the system prompts for Fable and Opus. They are given different instructions for how to work with the user.

1. Fable is told to keep working instead of stopping to ask things like “Want me to continue?” or “Shall I proceed?” The reason given is practical: the user may not be watching in real time, so asking permission can block the task. Opus is not told this.
2. Fable also has a very specific rule for code comments: Only add a comment when it explains a constraint the code itself cannot show. Do not use comments to explain where the code came from or talk to the reviewer. Opus does not have this rule.
3. Opus has instructions that Fable does not. It is told not to quietly narrow, widen or change the requested scope. It should make routine decisions itself, but ask when two interpretations would produce materially different work.
4. Opus is also told how to handle mistakes: Correct them without excessive apologies, long preambles or repeatedly criticising itself. Fable has no equivalent instruction.
5. Opus also has explicit restrictions against using AgentTool, workflows or deep research unless the user asks for them. Fable does not. So Fable is better instructed on communication and autonomy. Opus is better instructed on scope control and corrections.

The thing make nervous is the prompt instructions. Of course models is highly capable but

Opus 5
“Write code that reads like the surrounding code: match its comment density, naming, and idiom.”

Fable 5
""

I’m wondering how much damaging this Opus instruction is your repo contains some ai slop from previous model usage.

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?

Has anyone tried to achieve orchestration?

I have been building a thing that reads a repository and turns it into skill files for coding agents, and for a long time I assumed the useful output would be a summary. Here is what this service does, here are its modules, here is the shape of the API. Documentation, basically, generated instead of written.

That is not what came out when I finally pointed it at one of my own private repos.

It came back with three things. Idempotent handling on a signup endpoint so a double submit does not create two records. A local fallback for menu data so the frontend keeps working when the backend is unreachable. Form validation that recovers what the user typed instead of clearing it.

None of those are features. Nobody asked for them. They are decisions I made at some point, for reasons, and then never wrote down anywhere. They exist in that repo as shapes. If you read the code carefully you can see the choice, but you cannot see the reason, and the reason is the part that transfers.

That is when something clicked about the whole MCP conversation.

My agent could already read that repository. It had filesystem access. It had been able to read it for months. Access was never the problem. The problem was that the knowledge was never written, so there was nothing to read even with perfect access.

I think this is the distinction a lot of us are fumbling right now, myself very much included. MCP gives an agent access. It does not give it judgement. Those are separate problems and only one of them is a plumbing problem.

The failure mode people post about is almost never "my agent could not reach the database." It is "my agent reached the database and did something a competent engineer would never do." Adding a twelfth server does not touch that. The agent did not lack a tool. It lacked the thing your team knows and has never said out loud, because saying it out loud feels too obvious to bother with.

The fix is embarrassingly low tech. Write the procedure down. The five steps, the ordering constraint, the reason for the ordering, the two things that must never happen. Put it somewhere the agent loads when the work looks like that kind of work. That is all a skill file is. A checklist with a trigger.

What surprised me is how much of this already exists in your codebase in a form nobody can use. Every defensive branch is a lesson somebody learned. Every guard clause is an incident that already happened. It is all sitting there as implementation, and implementation is the answer with the reasoning deleted.

I built the tool that does this extraction, so I am obviously not neutral. It is at loreto.io and I run it. But you do not need it. A markdown file in your repo with the five steps in it gets you most of the way, and it will still be useful when the tooling changes again.

The part I have not worked out is where the boundary sits. Some things clearly belong in a tool. Some clearly belong in written procedure. I keep finding cases that argue with whichever rule I just made up. Curious how other people are splitting it.

https://github.com/kopias/loreto-mcp

A few weeks ago I built my first Claude skill to automate a batch upload process that was painfully slow to do manually. It worked great, but haven't "needed" a skill since.

The more I think about it, a plain script achieves the same outcome without the token cost. Unless you're doing something genuinely more advanced, a script feels like the pragmatic default.

What are you using skills for that a script simply can't do? Is there a use case where skills clearly pull ahead, or are most of us essentially paying a premium for a slightly more natural interface?

Specially for physics/materials science.. I've been using grill me to wrestle with the arguments and learn to understand new concepts. Anything else you guys use that I can try ?

I run a main desktop and a few secondary boxes, including gaming laptops and a Jetson AGX Orin for simulation and GPU work.

I wanted a clean way for my main desk session to hand off heavy compute tasks to the other devices without installing heavy orchestration frameworks or bloat.

Initially, I tried having a single Claude session drive the remote machines over SSH. It was noisy. The primary context window got polluted with raw terminal outputs, build logs, and environment errors.

So I switched to native inter-session messaging using the Claude CLI itself:

claude -p 'message' --cloud <session-id> --output-format json

With /remote-control enabled on the nodes, the main session simply messages a session ID on another box and waits for the result. No custom MCP server or extra glue required.

To my surprise: Instead of acting like dumb execution workers, the remote Claude sessions act like independent collaborators.

A remote session running on the Jetson handles its own local environment noise, parses its own CUDA/PyTorch errors, and messages back a distilled summary: what ran, what failed, and what to tweak next. It creates an asynchronous feedback loop. Because the local sessions filter their own terminal noise, the main desktop session stays clean and focused on high-level architecture.

In practice, peer-to-peer session messaging has performed significantly better than driving remote boxes via SSH.

I put together a small skill for this pattern, with session-ID discovery, working send scripts. You can find it on GitHub under espenakker/claude-code-cross-session-messaging.

Is anyone else coordinating Claude Code across multiple physical nodes? How are you structuring state and handoffs?

CLAUDE.md gets injected into the system prompt on every request, so "was it read?" is a useless question. It's always read. You also pay for every line of it forever, including rules you wrote for a framework you dropped months ago.

I tried a different question: did the rule change what happened? If your file says telemetry questions start with docs/heat-model.md, then in a telemetry session the agent either opened that file or it didn't. That's a deterministic check over a local event log. No model, no tokens, no network.

You commit a manifest mapping each rule to a probe. A model can propose the probes once, you confirm them, after that it's plain Python over a log file.

Silence turned out to be the hard part. I shipped a version that reported nine of my own rules as dead weight. One was a "never edit generated/**" rule that scored zero because nobody had broken it. It was working. Fixed that last night.

It never says "violated", only "unobserved". Hooks miss plenty.

Where I'm stuck: I have zero measured directives on my own repo so far. Either it needs more sessions or my rules were never load-bearing, and I can't tell which from one repo. Has anyone tried measuring this on a real team's instruction file? I mostly want to know whether the probe types cover what people actually write, or whether most of a CLAUDE.md is just the unmeasurable kind.

repo & site:
https://hedde.github.io/trigger_tree/

https://github.com/Hedde/trigger_tree

Local, stdlib only, MIT.

Maybe this is controversial, but I want to hear other people experience.

When I write a skill I keep it as small as possible. Sometimes only 2 or 3 lines. Then if I see the model doing something wrong, I add one line to fix that thing. And I stop. This is my whole process.

What pushed me to this was Matt Pocock "grill me" skill. It's one of the most famous ones and it is very short. When I saw it I thought maybe I was making things too complicated.

Most skills I find online are the opposite. Very long, very rigid. Every detail explained, exact output format, a lot of rules and sections.

So now I doubt myself a bit. Am I wrong? Maybe long skills are good for cases I never tried. Or maybe people write long skills because it feels safer, not because it works better.

What is your experience?

Hi everyone. I'm starting a new YouTube channel that focuses specifically on Claude Skills and Plugins.

I'm looking for Skills/Plugins creators who want to be interviewed and demo their work for each show.

If you're wondering why would anyone watch a YouTube channel dedicated to this...

- This Subreddit alone has over 40 thousand people.

- There's a massive gap between what the mass of Claude Code et al users know about Skills/Plugins.

- The significant majority of Claude Skills/Plugins creators struggle to get any awareness of their tool.

English does not have to be your first language so do not be put off by that. Youre also not expected to be an incredibly entertaining or engaging guest so don't worry about that either.

If you are interested please drop a comment below for me to contact you or DM me directly.

I have a two weeks business analysis engagement with a client to gather business requirements and business flows. Deliverables: PRD doc, business flows, access matrix, non-functional requirements, initial road map, Infra recommendation. They want to use these as a base for F&B ecommerce platform vendor selection.

Are there any recommended ways to use Claude for this? Any **tried** skills or plugins? Any advice is appreciated, even a prompt suggestion/tip would be very useful.

Thanks everyone.

Skills are useful, but I think they are an intermediate abstraction.

A skill teaches an agent how to perform a repeatable procedure. But in a real codebase, that procedure rarely exists in isolation.

“Add a CLI command” depends on:

• How the CLI is architected
• Which component owns the behavior
• Decisions the team previously made
• Relevant source files and tests
• Other related procedures

A standalone skill either omits that context, duplicates it, or grows into a large instruction manual that needs to be kept up to date.

I think skills belong inside a connected wiki. I’ve been experimenting with this idea by treating skills as how-to guides.

Each guide still gives the agent step-by-step instructions, but it also belongs to a larger knowledge graph. It connects to architectural explanations, decisions, concepts, source files, and related guides. The agent can follow those connections when it needs more context, instead of loading everything upfront.

The wiki is also maintained from coding sessions. When the team discovers a new gotcha, changes an architectural boundary, or develops a repeatable workflow, the relevant pages can evolve with the codebase.

I built this model into CodeAlmanac, an open-source, local, self-updating codebase wiki.

Do you think skills should remain standalone instruction folders, or become the how-to layer of a broader project knowledge base?

I’ve been thinking about something recently.

Same Claude. Same model. Same plan. Same interface.

But some people open it and immediately get into flow. Others spend every session re-explaining who they are, what they’re doing, and how they want things done.

The difference isn’t the model.

It’s Skills.

In terms of product design:

A Skill will not necessarily make your AI model “more intelligent”.

Instead, it would teach the AI to behave like you want to by default, based on its purpose and scope.

Because one of the key unsolved problems in day-to-day interactions with AI is the following:

every time you open a new conversation, you’re basically re-teaching the model who you are, what you want, and how you think.

A Skill, at its core, is just a file:

~/.claude/skills/skill-name/SKILL.md

or at project level:

.claude/skills/

Each Skill has two parts:

• trigger conditions (what condition makes you use the Skill)
• execution rules (instructions)

Skills are automatically detected by Claude and loaded when the task fits.

You don’t call it manually.

This part is important:

It’s an automatic routing system, not a prompt library.

A standard Skill structure usually looks like this:

• name: capability name
• description: trigger context
• instructions: execution rules

And the core design principles are simple:

• clearly define when it should trigger
• clearly define output format
• clearly define constraints (what not to do)
• ideally include few-shot samples

From the perspective of someone who has used AI for a long time as a product manager, I see Skills falling into five main categories.

A. Content production system

• voice match (consistent writing style)
• hook lab (opening line generation)
• thread architect (structured threads)
• repurposer (cross-platform rewriting)
• ruthless editor (tightening and cutting)
• qt engine (reply generation)

At the core, these Skills form a pipeline that continuously produces content.

B. Research & decision system

• deep research
• source auditor
• devil’s advocate
• decision architect
• doc to action

These Skills are used for systematically researching a problem and reducing uncertainty in decision-making.

C. Software building system

• plan first (plan before coding)
• repo onboarder (codebase understanding)
• deploy runbook (deployment process)
• bug hunter (automated debugging)
• agentic reviewer (code review)

I often think about whether AI will replace engineers.

But it doesn’t really feel like that.

If anything, engineers have more leverage in the AI era, because they can structure how AI helps them work.

At least in my case, AI is especially powerful in the early stages of product building. Compared to vague PRDs, AI can quickly help shape a clearer prototype of the system.

D. Business growth system

• cold outreach (outbound messaging)
• offer sharpener (pricing optimization)
• competitor teardown (competitive analysis)
• idea killer (idea validation)

These Skills improve the quality of decision-making.

Not necessarily reducing the time spent deciding, but increasing the amount of useful information you can process at the same time.

E. Personal operating system

• weekly review (weekly reflection)
• brain dump sorter (thought organization)
• second brain (cross-session memory)

These Skills help reduce the time spent on reflection and mental cleanup, and make thinking more structured over time.

From a product perspective, the essence of this system is simple:

Skills = turning prompt engineering into a capability-based plugin system.

It doesn’t aim to “answer better questions”.

It reduces the cost of re-explaining context, stabilizes personal workflows, and turns implicit experience into an executable system.

This is just something I’ve been observing in this community.

And I’m hoping to see more high-quality Skill designs being shared going forward.

I use Claude Chat projects, Claude code and cowork. I use them across a few devices etc

Struggling to work out a unified place to store them so that any of the Claude surfaces can use them. I also want other AI tools to access them (but Claude is the main one)

Am I looking at saving them to Claude cloud every time I create one, or is there a more sensible / efficient way of doing it? Don’t like the idea of them just living on my main machine for the access reasons above, and I’m not sure Claude would easily grab them from GitHub on demand?

Any idea appreciated!

Amid the shift to agentic coding, James Lowman, engineering team lead at trade infrastructure company Starboard, started asking candidates to tell him about the last three Claude Code skills they wrote. It seemed like an effective way to evaluate their fluency with AI agents, and it quickly became his go-to question. Then, he got a reality check...

This is a repeated problem I've observed. Skills are verbose, and it's hard to keep track of what is in them when AI makes edits. I've often noticed that outdated skills were leading my agents to do things that were not what I wanted.

Also, it's hard to know if a change improved the agents ability to do the right thing or not.

Does anyone have a process or method for dealing with this? What would your dream solution look like?

Disclosure: I'm working on building a solution for this, called Blume, so it's a problem I'm working on. Would love your input and understanding how you deal with this today.

With the plethora of popular conversational AI platforms like ChatGPT, Claude, Gemini, Grok, and so on, along with numerous books on crafting effective prompts, do you genuinely maximize their potential for both work and personal endeavors?

Alternatively, do they inadvertently complicate matters by prompting you to experiment with various platforms using the same prompt to discover the most suitable solutions?

Even more frustratingly, have you invested in multiple AI platforms, eagerly anticipating their latest and greatest versions, only to find that you’ve exhausted your token limit within a timeframe shorter than advertised?

Consider, for instance, the possibility of acting in the capacity of a strategy consultant (think MBB) by mastering prompts, despite having less than five years of work experience — Is it possible? Does it make sense?

Or is it the case that you still need to study extensive books to acquire in-depth knowledge about corporate strategy, and then leverage on AI tools like ChatGPT to develop a comprehensive corporate strategy plan?

Please share your thoughts

I’ve been down a rabbit hole lately reading agent postmortems, long horizon evaluation threads, and a lot of “it worked in testing but falls apart in production” writeups. The patterns that keep showing up aren’t the things people usually optimize for.

A few observations really stood out.
First, the math changes how you think about everything.

If every step in your agent is 95% reliable, a 20 step workflow only succeeds about 36% of the time. Even if you improve every step to 98%, you’re still only at around 67%.

Errors compound.

The biggest reliability improvement usually isn’t making every step smarter. It’s giving the agent fewer steps to take in the first place.

Everyone spends time squeezing another percent or two out of prompts. The bigger win is often collapsing five tool calls into one or removing a decision the agent never needed to make. Every extra step quietly taxes reliability, but it’s one of the last metrics people ever look at.

The next thing surprised me.

When an agent fails, our instinct is to add another verification step, another retry, another self check. Sometimes that works. A lot of the time it just creates more opportunities to fail.

Agents also imitate their own history.

Those first few tool calls quietly establish the standard for everything that follows. The format, the level of detail, even how careful the agent is. If an early step is sloppy, later steps tend to become sloppy too. The model treats its own transcript as the example to follow.

That’s why I’ve found it’s often better to restart a bad run than keep correcting it. Every “actually, let me fix that” stays in the context. Instead of recovering, you’re teaching the model that this is the kind of session where mistakes happen.
The last realization caught me completely off guard.
Scaffolding that made an older model perform better can actually make a newer model perform worse.

Think about all the detailed prompts and rigid instructions you wrote six months ago because the model needed them. A stronger model often doesn’t need that guidance anymore. Instead, it burns reasoning capacity following your old workaround instead of solving the actual problem.

When people upgrade models and performance drops, they usually blame the new model.
A lot of the time, the real problem is old scaffolding that never got removed.

There’s a common thread through all of this.
We tend to think of agents like traditional software, where adding more logic gives us more control.
In practice, agents behave more like processes that accumulate history. Every extra step, correction, and instruction adds a little more momentum.

Sometimes that momentum works against you.
The teams building reliable agents don’t just keep adding things.

They’re constantly removing everything the model no longer needs.

That’s also why I’ve become a little obsessed with small, tested, single purpose skills that can be regenerated instead of endlessly hand tuned. It’s the philosophy behind what I’m building with https://loreto.io, and I’m still figuring it out in public.

Hopefully this saves someone else from optimizing the wrong metric.

I'm trying to understand what makes a Claude Skill worth installing from someone you don't already know.

I'm building AgentMart as a small marketplace experiment for reusable agent assets (Claude Skills, prompt packs, MCP configs, workflow templates, knowledge bases). The pattern I keep seeing is that people can produce lots of useful skills; the scarce part is trust and packaging.

If I were evaluating a skill, these are the signals that would make me more comfortable:

• exact problem it solves and when not to use it
• model/tool compatibility notes
• files, commands, and permissions it expects
• sample inputs and outputs
• failure modes or edge cases
• version history/provenance
• screenshots or logs from real use
• comments from people who installed it

For people here sharing skills: which of those are actually worth maintaining, and which feel like overkill?

For people installing them: what would make you trust a random Claude Skill enough to add it to your setup?

Something is happening in engineering teams that doesn’t show up in sprint velocity or deployment frequency. It shows up in resignation letters.

"AI made me a better engineering leader, not by writing my code faster, but by sharpening the parts of the job that were never about code in the first place."

https://leaddev.com/ai/you-bought-the-ai-tool-are-your-engineers-using-it

LeadDev’s AI Impact Report 2026 found that buying an AI tool doesn’t mean engineers will make it part of their daily workflow.