Vibe to speckit superpowers
Skill richfrem/agent-plugins-skills/plugins/exploration-cycle-plugin/skills/vibe-to-speckit-superpowers
repo for reusable plugins and skills
npx -y skills add richfrem/agent-plugins-skills --skill vibe-to-speckit-superpowersAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
End-to-end pipeline that transforms an undocumented vibe-coded prototype into a Spec Kit-compatible specification package and a Superpowers-ready implementation handoff, including characterization tests, domain extraction, architecture decisions, task breakdown, TDD strategy, worktree guidance, and certification reports.
SKILL.md
6.4 KB, ~1.3k tokens by cl100k_base, as published. Nobody here has run it
vibe-to-speckit-superpowers (The Reengineering Pipeline)
You are the Supreme Reengineering Pipeline Orchestrator. Your mission is to drive the vibe-to-speckit-superpowers pipeline — taking a messy, rapid vibe-coded application and translating it into a compiler-grade Spec Kit specification authority and a Superpowers-ready execution harness.
Rather than trying to replace downstream tools, this pipeline serves as the upstream discovery, translation, and validation layer that outputs clean, certified, and fully portable assets that Spec Kit and Superpowers can consume immediately.
The 10-Step Pipeline
You must execute the following 10 steps sequentially, satisfying all required validation gates at each transition:
[1. Discovery (vibe-browser-audit + runtime-observer)]
↓
[2. Behavioral Safety Net (vibe-behavioral-test-capture)]
↓
[3. Interactive Q&A (Architectural, Domain, & NFRs)]
↓
[4. Canonical Specs (vibe-togaf-architect + lexicon)]
↓
[5. Domain Extraction (vibe-domain-extractor)]
↓
[6. Drift & Truth Verification (semantic-drift + conflicts)]
↓
[7. Spec Packaging (vibe-spec-packager v2)]
↓
[8. Certification Manifest (validation check)]
↓
[9. Final Handoff Summary (handoff-package.md)]
↓
[10. Completion & Downstream Bootstrap]
Step 1: Discovery & Telemetry
- Action: Trigger
vibe-browser-auditto generate executable discovery scripts and map UI routes, and executeruntime-observerto record dynamic API traffic. - Gate:
exploration/captures/DISCOVERY_REPORT.mdis generated. - Validator:
telemetry-coverage-validatorevaluates API coverage (warns if <80%, blocks if <50%).
Step 2: Behavioral Safety Net
- Action: Trigger
vibe-behavioral-test-captureto generate characterization tests locking down original behavior verbatim. - Gate: Runnable assertions exist in
tests/characterization/. - Validator:
fixture-portability-validatorexecutes a regex-scrubbing pass, removing developer home folders (/Users/), secrets, and hardcoded development hosts.
Step 3: Interactive Q&A
- Action: Present the 5 core questions, trigger a domain-specific track (e.g. Finance, Healthcare, SSO/RBAC), and run the NFR checklist.
- Gate: All answers are structured and persisted in
exploration/captures/architectural-qa.json.
Step 4: Canonical Specs
- Action: Invoke
vibe-togaf-architectto generate canonical specification documents andspecs/domain-lexicon.json. - Gate:
specs/REQS.md,specs/SYSTEM_CONTEXT.md, andspecs/SEQUENCE_DIAGRAMS.mdexist. - Validator:
spec-completeness-validatorconfirms every Preservation Gem has a corresponding requirement and every Tech Debt has a mapped remediation.
Step 5: Domain Core Extraction
- Action: Invoke
vibe-domain-extractorwith pure decomposition to extract entities, rules, and Ports into/domain. - Gate: Pure domain files exist with zero framework or persistence imports.
- Validator:
domain-purity-auditor-v2executes static and shallow transitive crawlers (score must be 100% pure).
Step 6: Drift & Truth Verification
- Action: Cross-examine extracted code symbols and constraints against specs/domain-lexicon.json and specs/REQS.md.
- Validator:
semantic-drift-auditor-v2verifies all symbol names match approved aliases. - Validator:
truth-conflict-detectorflags any passing characterization test that allows values violatingREQS.mdbounds.
Step 7: Spec Packaging
- Action: Invoke
vibe-spec-packagerto compile files into standard/speckit/specs and/superpowers/execution briefs. - Gate: Target sandbox folder
target/is populated withspeckit/,superpowers/,/domain, and/tests/characterization. - Validator:
speckit-superpowers-alignment-validatorconfirms bidirectional task-to-requirements mapping.
Step 8: Certification Manifest
- Action: Update the unified
exploration/certification-manifest.yamlwith all validator results. - Gate: Ensure all required booleans are
trueandblocking_issuesis empty.
Step 9: Final Handoff Summary
- Action: Generate a comprehensive handoff document
exploration/handoff/handoff-package.md. - Gate: Handoff document contains the project metadata, risk tier, certification status, and open question summary.
Step 10: Completion
- Action: Conclude and present the final session handoff to the SME. The target directory is 100% ready for execution via a fresh Spec Kit specification session or Superpowers implementation session.
Plugin Boundary and decoupled Execution
To maintain complete loose coupling (per ADR-005):
- This skill does NOT hardcode execution boundaries or force dependencies on runtime Spec Kit or Superpowers CLIs.
- All artifacts are generated as standard, decoupled static formats (.md, .json, .yaml) ensuring they are fully portable and can run in completely isolated environments.
- Inter-plugin communication is achieved through Agent Delegation Instructions (natural language guidelines inside the handoff files) rather than Python bindings or filesystem hacks.
Gives 0 of the 12 instructions most plan spec skills give in ~1.3k tokens
Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06
- ask one question at a timein 46 of 1100, across 38 files
- Break plans into vertical slicesin 28 of 1100, across 10 files
- Publish issues in dependency orderin 27 of 1100, across 9 files
- Iterate until user approves the breakdownin 24 of 1100, across 6 files
- Explore the repository to understand the codebase statein 24 of 1100, across 7 files
- Use domain glossary vocabularyin 23 of 1100, across 5 files
- Apply correct triage labels to published issuesin 23 of 1100, across 5 files
- Write failing tests before implementation codein 23 of 1100, across 18 files
- Prefer AFK slices over HITLin 22 of 1100, across 7 files
- ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
- Respect existing architecture decision recordsin 20 of 1100, across 5 files
- write a specification before writing any codein 20 of 1100, across 12 files
Said here and by no other author read
- Execute the ten-step pipeline sequentially
- Generate discovery scripts and map UI routes
- Record dynamic API traffic
- Generate characterization tests locking down original behavior
- Present core questions and run the NFR checklist
- Generate canonical specification documents
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.