Superpowers 6(blog.fsck.com) |
Superpowers 6(blog.fsck.com) |
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.
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.
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'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.
Here's what that methodology looks like: https://github.com/obra/superpowers#the-basic-workflow
The steps, described [here](https://github.com/obra/superpowers#the-basic-workflow), are: brainstorming → using-git-worktrees → writing-plans → subagent-driven-development or executing-plans → test-driven-development → requesting-code-review → finishing-a-development-branch.
The principles, described [here](https://github.com/obra/superpowers#philosophy), are: Write tests first, always; Process over guessing; Simplicity as primary goal; Verify before declaring success.
Install it, take a complex tasks, and instruct the agent to implement it; it's easier to watch it in action than to describe it.
In my own experience, the advantage is that it's a very systematic workflow - investigation of requirements, breakdown in simpler steps, and TDD development, among the other aspects.
When I used it though , I only found it burning too many tokens to do too little. I guess Superpowers is useful only in hands that know how to manipulate it.
Similar to Addy Osmani's Agent Skills and Matt Pococks skills.
Great way to build larger projects!
Gonna take a moment to share my own generic "retro" prompt, which has found many areas of improvement IME.
> Let's conclude with a retro. Did you run into any issues during this session that you think could be improved? Any failed tool calls, confusing docs/prompts, or tricky wording that took you effort to figure out, etc? Any final thoughts that you want to raise? Anything minor you didn't mention? Help make this codebase easier for the next agent to work in.
It's somewhat doc-focused since I'm currently working on fairly dense design docs... but you can easily customize it for your own needs.
This prompt reveals how absolutely _ass_ the Claude Code harness is (so many stupid tool call failures), but not much I can do about that.
I've just started using Claude Code this month after months of Claude in VSCode + GitHub Copilot (and a bit of dabbling with AWS Kiro), and I'm actually impressed by how seemingly polished Claude Code is.
I think Copilot in VSCode broke far more in my months of (ab)using it.
As if it really would work like that. The noise added by the verbosity alone is not taken care of enough, and this entire thing belongs on the great pile of ai vaporware.
* 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.
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.
For me personally, it was a game changer when I first began using it and now it simply is as much a part of my workflow as any say, using git (yeah it has its warts but way way more value).
Also, the latest (version 6) is noticebly token efficient as claimed.
Did the people who found it underwhelming not try starting with the brainstorming skill first?
It works very well for the way that I work (interactively and iteratively, not "one-shot"), and it helps me to better work in less time. Superpowers is one of the few skill/agent suites I use for all software development projects.
If you like building skill/agents, the posts at https://blog.fsck.com/ are a great resource for learning how to do well. The effectiveness of my project Axiom (a skill/agent suite for Apple OS developers) has benefited enormously from the knowledge that Superpowers' creator Jesse Vincent has been kind enough to share.
TLDR: You owe it to yourself to try it.
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.
The most annoying thing is that it always pauses before implementing to ask if I want it to use Subagents (which it always recommends) or not.
I’d be curious to see if there was a way to automatically do this for me in Claude Code.
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...
I often end my Claude Opus 1M sessions at around 60-80% context, and that's with doing `/context` once in a while, and forcing the agent to wrap up and write handover notes, so that I can start on a new unit with fresh context.
I had similar prompts back when the models were terrible at instruction-following, so it was actually useful to fill up their context with a mass of instructions so they'd be less likely to forget rules.
Now I've got a few small slash commands or pasted prompts that work perfectly every time as the models follow them exactly.
I picked up superpowers back when it first started gaining traction; the first iteration felt like an “oh shit” moment for me, then the sheen quickly wore off. Higher spend, slower throughput and mediocre results made me eventually drop it and go back to plan mode, which had improved significantly during that time.
Coming back, 6.x does feel different and I’m back on the superpowers train. I’m finding it great at taking discrete tasks from beginning to end with very little hand holding.
I run every session with a /goal as well: “Spec + Plan is written and you have implemented the plan without my involvement. You have validated that the implementation is complete and ready to merge”
It’s also great in situations where you may need to complete a plan over multiple sessions, because you get a whole ton of state with superpowers that new sessions can pickup on.
Writing skills is the new writing code.
From TFA (well, blog):
> The long and the short of it it is that across about 36 hours of work and what would have been $650 of unsubsidized token spend, our Anthropic eval benchmarks were looking like we'd reduced wall-clock runtime for Superpowers builds by 50% and token spend by 60%.
But when I don't trigger brainstorm mode, even using the built in plan mode, it's just never as in depth of a brainstorm partner for me.
Yeah on the token consumption, I'll be doing something small at work, and it'll consume a lot of tokens.
The model
|
The harness
|
The harness of the harness?!!