Seeking advice on integrating Spec-Kit with Superpowers (context awareness & task continuity)

[khuong-dv]

Hi everyone,

I'm currently using Spec-Kit together with Superpowers in my workflow:

• Spec-Kit: for writing specifications, generating plans, and defining tasks
• Superpowers: for executing those plans

However, I'm running into a few issues:

1. Lack of awareness of constitution.md
   During execution, Superpowers doesn't seem to take constitution.md into account. This leads to inconsistencies between the defined rules/principles and the actual implementation.

2. Task continuity between sessions
   When a session ends before the work is completed, Superpowers doesn't know how to resume. It cannot easily rediscover or continue the tasks that were originally generated by Spec-Kit.

I'm wondering if anyone has experience dealing with these problems, or has suggestions on:

• How to ensure Superpowers respects or loads constitution.md during execution
• How to persist and resume task context across sessions
• Any best practices for integrating Spec-Kit and Superpowers more effectively

Thanks in advance for any guidance.

[mnriem]

So you are not using /speckit.implement?

[khuong-dv]

Yes, I'm not using /speckit.implement. I'm using Superpowers executing-plans instead.

[specularis-org]

I'd be interested to know why you decided to use Superpowers for implementation rather than the spec-kit implementation?!

[khuong-dv]

Yes, I actually approached both spec-kit and Superpowers for the first time recently.
From my research so far:

spec-kit is really strong on the input/structure side — the constitution keeps the team’s principles consistent, the “clarify” step removes ambiguity before any code is written, and tasks.md gives you very concrete output with clear file paths and dependencies.
Superpowers excels on the reliable output side — subagent-driven development can run for hours without drifting off course, it enforces strict TDD, and it does automatic code reviews between tasks. It can also orchestrate different subagents for different purposes (TDD, subagent-driven development, etc.).

Both tools can communicate through task.md, so I decided to combine them instead of relying on just one. That way I avoid being locked into a single component.
However, I’d really appreciate advice from anyone who has actually tried this hybrid approach and has real experience with it.

Here’s my basic workflow:

• \speckit.specify
• \speckit.plan
• \speckit.task
• superpowers executing-plans

[rhuss]

You might be interested in https://github.com/rhuss/cc-sdd , which adds on top of spec-kit and introduces superpowers as traits. Happy to help if there are any questions.

[rhuss]

ALso looking how to improve my integration there, might be not the optimal way how to bring both sides together (at least you can update both packages independently)

[rhuss]

The superpowers trait actually add this skill as quality gates to speckit skills, so that the usual speckit flow with speckit.implement stays the same (and people can choose to optin/optout of superpowers via sdd:init)

[khuong-dv]

@rhuss
Thanks a lot for your response and for sharing your work on cc-sdd — I really appreciate the support.

I’ll spend some time experimenting with it and using it as a reference for my own setup.

Also, is cc-sdd something you plan to keep updated alongside future changes in spec-kit or superpowers? I’d like to understand if you’re planning to continue maintaining it over time.

[rhuss]

Yes, I'm committed personally to cc-sdd as this is my playground for exploring what I call collaborative SDD . For now, SDD with spec-kit works super well when doing it on my own pace. But how to apply SDD in teams ? How does the PR review process changes ? My current take is to have a PR on the spec, but then, then the spec are also huge and auto-generated. So I've introduced a REVIEWERS.md which pin points the most critical decissions that need an opinion. It's by far not perfect and I'm not super happy with it, but still, this is the best I came up with.

I use cc-sdd daily, so it's really something I care about :-)

[mnriem]

@rhuss Would you consider listing cc-sdd in a new section called "Community Friends" in the main Spec Kit README? And for folks asking about what constitutes a Community Friend? You integrate Spec Kit into something larger. You visualize Spec Kit stuff. You use Spec Kit's extensions to deliver another style flow. Etc.

[rhuss]

Yes, great idea. I will send a PR. thanks 🙏

[Cris-z123]

Great, I’m currently using the same workflow as you.
I think it’s better to carry out tasks in small batches each time, as this ensures the context remains manageable, rather than trying to complete tasks automatically in bulk.

[mnriem]

Love seeing folks using the Kit in Spec Kit :)

[lihan3238]

Hit this exact wall — constitution drift during execution, and losing the thread when a session dies mid-task — and went a different direction than a plugin/wrapper, in case the "keep both upstreams stock" angle helps anyone here.

@rhuss's cc-sdd traits and Superspec are great if you want batteries included. I wanted the opposite: change nothing about Spec Kit or Superpowers, just add a thin seam between them so either side can be upgraded independently. Three small things, no new commands grafted onto speckit:

• handoff — a single .specify/superpowers-handoff.json carries feature / artifact-owner / status, so a fresh session (or a different agent) knows exactly where execution stopped. That's the task-continuity gap.
• guard — ~5 hardcoded boundary rules so the two systems can't double-own a phase: e.g. block speckit.implement and speckit.constitution while a handoff is executing. Keeps the Spec Kit artifacts authoritative during execution instead of being silently bypassed. (It doesn't make Superpowers read constitution.md — that stays Spec Kit's job at plan/tasks time; it just stops execution drifting off those artifacts.)
• status — a [bridge state] block on every invocation + an append-only bridge-events.jsonl audit log.

Two deliberate choices: explicit invocation only (no auto-trigger — the dev.to comparison article flags how auto-trigger derails sessions), and the same contract peers across Claude Code and Codex, so you can plan in one and implement in the other. Division of labor stays boring: Spec Kit owns WHAT, Superpowers owns HOW, tasks.md is the contract.

Not trying to win against cc-sdd / Superspec — different taste. Thick opinionated harness → those fit. Keep stock Spec Kit + stock Superpowers and just add a safety seam → this might. Honest full comparison table (incl. cc-sdd, Superspec, SuperB, Comet) + install steps: https://github.com/lihan3238/speckit-superpowers-bridge

[rhuss]

Just a quick update from my side: cc-sdd has been renamed to cc-spex to avoid collision with an unrelated already existing project that I have overlooked, and I moved away from the home grown traits system to leverage vanilla spec-kit extensions. And yes, I picked up mostly the parts of superpowers that fits to spec-kit (by doing a regular sync with upstream superpowers), namely the guided brainstorming phase, the intermediate spec and plan reviews and the deep review after the implementation with 5 orthogonal sub-agents.

For the actual spec and implementation phase, superpowers uses a different, not so explicit planning, so I prefer spec-kits approachs for that part.

But I agree, it's really a matter what you prefere, none of the approaches is superior per-se.

[lihan3238]

Thanks @rhuss, and good call on the rename — I'll update my comparison to point at cc-spex and drop the stale "traits" wording (I'd written that up before you moved to vanilla extensions). Fully agree it's preference, not hierarchy.

Funny that we converged from opposite ends: you kept the Superpowers phases that fit spec-kit (guided brainstorming, the intermediate spec/plan reviews, the multi-subagent deep review) and lean on spec-kit's explicit planning for spec + implement — which is exactly the split I landed on too, just enforced from outside via the handoff/guard instead of pulled inside as extensions. Either way spec-kit's planning stays authoritative, which feels like the real shared lesson.