The only skill I genuinely find useful is the /strategic-compact from ecc (everything Claude Code) but you can get the same effect by saying something like "I am going to compact the session, give the next Claude session a summary of what was added or changed and what the next step is". The you can just use /compact <message>. Other than that, just barebone too. ECC is shipped with something like 300 skills, maybe I should just delete it!

At least for me, writing the code // using the IDE // prompting the LLM to do the thing is not the hard part. The hard part is always understanding the actual problem // underlying assumptions // actual customer need and then architecturing the right solution to that. Actually implementing the solution is the easy part, and LLMs have made that now even easier.

But they've not really helped interpret customer requirements when they give you logically inconsistent / unimplementable business processes that need major re-vamping before they can be coded. To some extent they can help de-code poorly worded emails sent by some exec while golfing or in a meeting. But they still can't conjure information out from nothing. Nor are they that good at helping to play the political game when you have team X and team Y depending new feature Z, but feature Z requires completely changing how either team does process Ab but neither will even admit that their processes aren't compatible with each other.

The main advantage of skills is defining a process that is at least vaguely consistent across different executions for a given task, and plugging in some of the common pitfalls an LLM might fall into for some of those executions.

But to me, both the process and the pitfalls are going to be heavily specific to the individual or team, and to the work they are doing... It's something that evolves over time as you bump into repeated rough edges.

Taking someone else's skills and blindly applying them to my situation feels odd. I don't know what rough edges those skills were made to address, so I have no reason to believe they would fit my specific needs, initially, any better than the baseline LLM.

Same here but yesterday I decided to give this a goal. It started a workflow that spawned like a 100 sub agents to research the best o11y product I can use. It burnt through all my max plan (before it could start making any changes), something I could never do simply by using claude code yet. It's not for me.

Agreed. I often take a look at the skills and maybe take something from there to create a more minimal version that does just enough for my needs and nothing more. YAGNI is definitely the principle to be followed here.

I'm sure all these people on Reddit that talk about having 5 Claude Max 20x plans and hitting the weekly limits on them all have a ton of these loaded.

Agreed. It seems like a large and growing artifice sitting on a foundation that is constantly shifting.

100% Also good to note that Cherny and Steipete have said in interviews that they keep it simple and do not use any of these shenanigans.

Ultracode is pretty good. I’m not basically using the grill-with-docs from Matt and default plan mode on Cc or codex. It’s just enough.

I am currently slowly exploring subagent based feature factories people have been talking about. I looked at superpowers and it just felt like a lot. The process seems be trying to match the complexity of a human team workflow. Seems like the wrong angle to take for this. I am getting a lot out of my simple subagent team by just clearly defining their roles and restricting what they can access. Although experimenting with orchestration policies is required. This feels like tokenmaxxing for marginal improvements.