superpowers VS nori-skillsets

Meanwhile, the ecosystem materialized. obra/superpowers shipped a complete software development methodology built on composable skills — 1,276+ stars and growing. The cobusgreyling/loop-engineering repo cataloged patterns from Osmani and Cherny into a practical reference.

Projects like Superpowers proved that agents can follow structured methodologies — brainstorm before coding, write tests before implementation, review against specs before declaring success. The skills are mandatory workflows, not suggestions. The agent checks for relevant skills before any task.

If you're looking for complementary skills and plugins then have a look at Addy Osmani's Agent Skills or Superpowers, both provide essential coding assistant skills like Test-Driven Development (TDD). OpenSpec provides consistency, and your workflow can evolve around it.

Before any implementation, I plan. I use the brainstorming skill from Superpowers to think through the approach, then Grill Me - a separate skill that probes for contradictions, gaps, and missing assumptions, question by question. Once I'm satisfied, I save the result as a PRD and move to writing-plans (also from Superpowers), which produces a detailed implementation plan: class names, properties, architecture, tests.

These don't replace the spec; they govern how the agent acts on it. Superpowers uses guided Q&A to clarify intent, then runs sub-agents behind a verification-before-completion gate. GSD manages context in waves for solo developers. HVE Core runs an RPI loop: Research, Plan, Implement, Review.

> It would be extremely cool to be able to write one or two lines of prompt in my harness, and have a light model iterate with me a few times writing/proposing requirements, guidelines and explanations, refining the prompt until it's ready to be sent to the actual LLM.

I feel like the vast majority of AI-using coders already do this via skills suites like Superpowers (see /superpowers:brainstorming), no? https://github.com/obra/superpowers

I sometimes use Superpowers skills such as writing-plan and writing-spec. The Superpowers brainstorming skill stores design specs under docs/superpowers/specs/YYYY-MM-DD--design.md, and the writing-plans skill stores implementation plans under docs/superpowers/plans/YYYY-MM-DD-.md. (GitHub, GitHub)

obra/superpowers – GitHub

> My strong hunch is they are moving to closed source because it is now trivial to copy a product with AI clean rooms. Which, tbf, is a totally valid reason to move closed source.

The "clean room" part of clean-room reverse engineering implies that there is no exposure to the original copyrighted code on the part of those doing the reimplementation, whether human developers or AI. Traditionally, if you're working of the source code itself, you have one party translate the source code back into a design document, specifying behavior, and then you have another party implement that design spec with original code.

If you already have a running copy of the software to model the behavior off of, then you don't need the original source code in the first place. So going closed source will have zero effect on the capacity of AI tools to be used for clean room reverse engineering: all you need is the runtime.

> But I'd want to see more adoption of something like the Ship of Theseus license (https://github.com/tilework-tech/nori-skillsets/pull/465/cha...) before giving up on open source entirely

This license doesn't seem valid: a license can't redefine what qualifies as a derivative work. That's determined by copyright law itself, and if copyright law says that a clean-room reimplementation isn't a derivative work, then it isn't restricted by copyright, so doesn't need a license in the first place.

Nori uses Claude Code's skills extensively, which you can see here: https://github.com/tilework-tech/nori-profiles/tree/main/src...

We use Claude Code's ability to use skills by defining a bunch of really useful and common skills that are necessary for writing software. For e.g. brainstorming, doing test driven development, or submitting a git commit.

The specific skills you linked are interesting demos of what you can do with skills! But most of them are not useful for the day to day of building software