Comment by losvedir

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.

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.

So I don't use stuff like Superpowers either - I think if it were actually that good, it would work it's way into the core product.

But I do mod Claude Code to incorporate gotchas from my specific workflows. For example: Which snowflake instance should you look at, where are the tables in my data warehouse, [Product] doesn't have an API, here's a Skill that uses the Chrome MCP to handle repetitive tasks, here's an agent that should explore the schema, you don't have write-access to this repo. A recent skill I made was to modify our terraform config (after doing it 4 times in the same way) - it requires pulling the ticket from JIRA, knowing how our terraform config works (or at least the bit I'm interested in), and making a pull request in a certain format.

Agents solve a real problem of keeping your main context shorter, and you can also have your main thread on Fable/Opus/Sonnet, but use Haiku for certain tasks in a subagent because you know the dumb AI can figure it out - but you need to think about the tasks in your job.

I've done my fair bit of modding with electric bicycles and 3d printers and in general the lesson I learnt is that a small bit of modding can cause an improvement (e.g. I want a usb charger from my battery), but overmodding breaks things, and either you want ebikes and 3d printers to be your hobby, or your hobby can be fixing your ebike or 3d printer. I think the same applies to claude code or Vim. Incidentally I never modded vim.

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.

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.

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.

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.

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