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

71–80 of 84 posts

Re: Superpowers 6

#71

Post by NorthSouthNorth »

tmach32 wrote: post #63

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 implementa…

I think you can write a quick script to toggle the disable-model-invocation to turn off auto invocation.

Re: Superpowers 6

#72

Post by Otterly99 »

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…

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 . Other than that, just barebone too. ECC is shipped with something like 300 skills, maybe I should just delete it!

Re: Superpowers 6

#73

Post by klibertp »

simonw wrote: post #40
mempko wrote: post #27

This is great in concept but what prevents me from using it is TDD. I don't want to waste tokens on producing code that doesn't ship to the end user. Design by Contract is a far superior approach. If you've never heard of Design by Contract I don't blame you, our culture really failed to bring it mainstream. But I swear by it and it gives me real superpowers. Maybe I should fork this and gut the TDD part and replace…

What programming language are you using for Design by Contract?

I'd like to know, too!

DbC is an actual superpower. Coupled with a gradual type system, especially one that provides type refinements (not sure if that's a Racket-specific[1] or generic term), DbC covers a wide variety of problems and either eliminates them or makes debugging them a lot easier. The problem is that only two/three languages are built around DbC (Eiffel, Racket, Ada/SPARK). There are a few others (e.g., Clojure, Raku, Scala) that provide some degree of support, but their capabilities are incredibly basic compared to what, for example, Racket offers. And for mainstream programming languages, there are libraries, but it's a coin toss whether authors even understand the idea (I once asked in a ticket for some Python contract library about contracts for callables and was met with "what?" - as if specifying range constraints on ints was all DbC was about).

Unfortunately, Racket is tiny, barely a blip in the training data. In theory, you could probably get agents to a new level of reliability by making them write Racket; in practice, though, you'll burn a lot more tokens on every single edit, because the agent will need to rediscover how to do things in Racket much more often than in Python.

I had some hopes that LLMs and agents based on them would be an opportunity for less popular, but technically advanced languages. So far, it doesn't seem like it's happening; the ridiculous per-token API prices mean that you need a really good agent harness for your language - and what niche PL has resources to focus on building one?

[1] https://docs.racket-lang.org/ts-reference/Experimental_Featu...

Re: Superpowers 6

#75

Post by wejick »

So far SDD (Spec Driven Development) with openspec hit the right balance for me, the Workflow is not too heavy while execution still churning good result given the spec is done well.

Re: Superpowers 6

#76

Post by johnfn »

devnonymous wrote: post #58
johnfn wrote: post #37

To be blunt I can't take this product seriously when they don't even run benchmarks. Your prompts make Claude better? Cool: prove it. Methods to evaluate LLM performance exist, they're called evals/benchmarks, and every company that is serious about AI runs them when they release a new version. (Of course benchmarks have their own issues, but squabbling over which benchmark is best and what issues there are is step 2…

To be blunt you should perhaps read the README before being condescending and dismissive. https://github.com/prime-radiant-inc/superpowers-evals

You mean the obviously AI generated README? Did you even read it yourself?

Re: Superpowers 6

#77

Post by alex_c »

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…

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.

Re: Superpowers 6

#78

Post by clickety_clack »

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. It seems like a large and growing artifice sitting on a foundation that is constantly shifting.

Re: Superpowers 6

#79

Post by imgyuri »

I feel like all these fat skills on top of agents will become stale very quickly. Unless it is for a very specific workflow with a need for deterministic outputs, I just don't see them having high value.

If I do need such workflows I just use plan mode, and it is 90% sufficient. I created a skill that hooks on top of plan mode because of its shortcomings, but I'm pretty sure even this will become obsolete soon as models improve.

https://github.com/oliver-im/jidoka

Re: Superpowers 6

#80

Post by verbify »

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…

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.

Post reply on HN