Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Superpowers 6

blog.fsck.com

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Superpowers 6

#61

Post by bashtoni »

losvedir wrote: post #24

Superpowers feels like 20 years ago when people would be sharing and debating their incredibly elaborate .vimrc files, which totally made them super productive. Meanwhile, I tried to stick to stock configuration as much as possible (mostly for portability / ssh reasons). In a similar vein, these days some of my colleagues are sharing all their skills and prompt tricks and stuff, and I try to just use barebones Claude…

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.

Re: Superpowers 6

#63

Post by tmach32 »

I used Superpowers for a few weeks. I ran into a couple issues:

* I wish I could turn it on selectively. Many of my requests do not require the "verification before completion" and TDD ceremony. For example, agents using stock Superpowers will go so far as to grep a file every time you ask to add something to them to verify that the edit really landed.

* While I like speccing out/designing a project before implementation (nothing new in that regard), I don't like how precisely superpowers plans out the implementation in the /writing-plans skill. It tells future agents exactly what files to edit. There are two big issues with this:

  * We need to manage context rot. If one LLM session is responsible for writing out the entire plan, we aren't solving context rot. Not only is the "smart window" of context exhausted by the time the agent is planning, eg, step 7 out of 15, but it's also dragging forward all the possibly bad ideas it had earlier. It would be better if steps were planned independently.

  * Implementation is an iterative process. You find things out as you go. Your assumptions turned out to be wrong, you realize APIs don't behave the way you thought you did, etc. This is why writing out a precise plan ahead of time is an issue – it's written without this iteration.
IMO, the strongest part of Superpowers is /subagent-driven-development. Yes, it's SUPER slow. For a laugh, you can ask it to make a change you know can be done in one line. It'll do it in one line, but it take literally an hour with all the verification. But that's sort of the point. It is _very_ deliberate. For each step, it reviews the step for both compliance and code quality, then has another agent implement the fixes, _and then it reviews the fixes again_. It does this for every step (not at the end of the project). While this might seem like overkill, it leads to code which complies with the spec far better.

Instead of writing a super detailed spec, I think I'd like /writing-plans to come up with appropriate "units" of work (sometimes called slices) and to brainstorm with the user regarding implementation, but to leave it looser than "edit this exact file in this exact way". That should leave a lot more leeway to implementation agents but still give the review agents something to check compliance against.

Re: Superpowers 6

#64

Post by Maxion »

losvedir wrote: post #24

Superpowers feels like 20 years ago when people would be sharing and debating their incredibly elaborate .vimrc files, which totally made them super productive. Meanwhile, I tried to stick to stock configuration as much as possible (mostly for portability / ssh reasons). In a similar vein, these days some of my colleagues are sharing all their skills and prompt tricks and stuff, and I try to just use barebones Claude…

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.

Re: Superpowers 6

#65

Post by YuukiRey »

I can't believe that a bunch of Markdown files now comes with a "Commercial Services" section. It feels like an elaborate GitHub Karma farm. Everything has to be commercialized and advertised.

Re: Superpowers 6

#66

Post by yard2010 »

losvedir wrote: post #24

Superpowers feels like 20 years ago when people would be sharing and debating their incredibly elaborate .vimrc files, which totally made them super productive. Meanwhile, I tried to stick to stock configuration as much as possible (mostly for portability / ssh reasons). In a similar vein, these days some of my colleagues are sharing all their skills and prompt tricks and stuff, and I try to just use barebones Claude…

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.

Re: Superpowers 6

#67

Post by d4rkp4ttern »

losvedir wrote: post #24

Superpowers feels like 20 years ago when people would be sharing and debating their incredibly elaborate .vimrc files, which totally made them super productive. Meanwhile, I tried to stick to stock configuration as much as possible (mostly for portability / ssh reasons). In a similar vein, these days some of my colleagues are sharing all their skills and prompt tricks and stuff, and I try to just use barebones Claude…

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.

Re: Superpowers 6

#68

Post by throwaway314155 »

overflowy wrote: post #3

How does Superpowers compare with Matt Pocock's skills[1]? I only tried the latter, and to be honest, I had positive results without burning a quadrillion tokens. [1] https://www.youtube.com/watch?v=-QFHIoCo-Ko

Is this available in written form or even as a GitHub repository?

Re: Superpowers 6

#69

Post by luipugs »

smrtinsert wrote: post #57
artisin wrote: post #6

I gave Superpowers 5.x a whirl for a week, and aside from consuming a stupid amount of tokens, it did materially worse across all my personal benchmarks and general day-to-day development compared to plain Codex/Claude. I'm convinced it's either some 4D ploy by the AI cartels to set tokens ablaze, or it only provides Superpowers to those without any power to begin with. Rating: 1/5 Pinocchios. Would not recommend.

The model | The harness | The harness of the harness?!! This structure doesn't make any sense to me. It's like adding a half leather half shag wrap to your steering wheel. Not to mention the harness itself is updated almost multiple times daily. I'm sure these framework authors are keeping tabs on the harness of the harness performance for every release of the harness.

It's harnesses all the way down.

Re: Superpowers 6

#70

Post by newswasboring »

losvedir wrote: post #24

Superpowers feels like 20 years ago when people would be sharing and debating their incredibly elaborate .vimrc files, which totally made them super productive. Meanwhile, I tried to stick to stock configuration as much as possible (mostly for portability / ssh reasons). In a similar vein, these days some of my colleagues are sharing all their skills and prompt tricks and stuff, and I try to just use barebones Claude…

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.
Post reply on HN