superpowers VS OpenSpec

It's crazy to me that some GitHub repos, that were just created in the last year, have more stars then some of the most popular programming frameworks out there. At the time of writing, Superpowers, is around 226,000, ahead of the Vue repo and way ahead of Next.js. A separate repo based on Andrej Karpathy's coding advice has 174,000. And they aren't even code. They're folders of markdown files that tell your AI coding agent how to write software better.

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

For anything bigger, the planning phase matters more than the writing phase. The agent can plan a feature end-to-end, but the first plan is almost always overbuilt: defensive abstractions for problems you do not have, optionality you will not use, indirection that hides what the system actually does. The fix is to iterate on the plan before any code is generated, and this is where you will want an expert eye on it. A useful trick is to feed the plan file to a second agent and ask it to cut the fluff; the second one has no stake in the first agent's elaborations and will strip them without ceremony. OpenSpec takes this further by pinning specs into the repository as their own markdown files, so the plan outlives the chat session.

I'm one to stare at the screen blankly, not knowing where to start, or get distracted mid-flow by a shiny new idea. OpenSpec and Spec-Driven Development help automate many of the tedious aspects of the development flow so I can break away when necessary:

That's literally what OpenSpec does (https://openspec.dev/). It's quite nice. I've only exceptionally rarely seen claude do something wrong based on spec docs when it's fully spec'd out. More often it's because something wasn't nailed down and claude was forced to make assumptions.

The downside is the ospx markdown specs sometimes end up too granular, focusing on the wrong or less important details, so reading the specs feels like a slog.

what are the fundamental differences between Spec-Driven-Development and OpenSpec (https://github.com/Fission-AI/OpenSpec)?

This isn't original to me. The 2026 wave of spec-driven tooling (OpenSpec, cc-sdd, amux, Kiro) is all built on the same observation. GitHub Copilot Workspace doesn't even let you skip the step: it generates an editable "proposed specification" before it touches code, because the team that built it figured out that the spec is the only artifact in the workflow that the human can actually review.

OpenSpec Getting Started

Yep I agree. I was looking for a getting started like for example here for openspec: https://github.com/Fission-AI/OpenSpec/blob/main/docs/gettin... but couldn't find anything like that

I'm an IT consultant. CCleaner was a good choice to speed up clients' web browsing experience. Unless you paid, it keeps vomiting ads for the product. Which made it a bad choice.

mTTCleaner does most of the same thing to clean most browsers by cleaning caches, compacting databases, and removing unnecessary metrics files.

It can create it's own cron job/scheduled task to run itself every month, if you choose.

It covers 28 browsers on 3 platforms, assuming you have PowerShell 7+.

Please file any bugs if you find them.

This isn't really going anywhere except to help internet users and my clients.

Hope it's helpful

PS - All of it generated with VS Code, Augmentcode AI (https://www.augmentcode.com/), OpenSpec (https://github.com/Fission-AI/OpenSpec), and beads (https://github.com/gastownhall/beads).