Start with install, host onboarding, triggers, pipeline, and delivery.
This documentation covers installation, host onboarding, triggers, pipeline stages, codebase intelligence, regression guard, local knowledge, workflow gates, and delivery requirements.
Install the CLI first. Then run super-dev in the terminal to open the host installer and write the required protocol surfaces.
pip install -U super-dev
# or
uv tool install super-dev
super-devPositioning
Super Dev governs the AI development process inside the host.
The host handles model reasoning, browsing, tool execution, and real coding. Super Dev governs research, the three core docs, approval gates, spec creation, frontend validation, quality thresholds, and delivery standards.
Host executes
Reasoning, browsing, code edits, terminal commands, and runtime execution stay inside the host.
Super Dev governs
Research-first flow, the three core docs, confirmation gates, frontend verification, quality gates, and delivery readiness.
Artifacts stay auditable
Research, PRD, Architecture, UI/UX, Spec, runtime reports, and delivery outputs remain inspectable.
Installation
Installation
Install the tool first, then enter the host onboarding flow. This section covers what gets installed and what to run next.
Installation notes
- pip or uv automatically install Super Dev and its Python dependencies.
- They do not install Claude Code, Cursor, Trae, Gemini CLI, VS Code Copilot, or any host application.
- Running super-dev opens the host installer and writes the required protocol surfaces for the 16 primary host profiles.
pip install -U super-dev
# or
uv tool install super-dev
# open the installer
super-dev
# update later
super-dev updateIntegration Surfaces
Integration surfaces
The installer writes the required project-level and user-level surfaces so the host can recognize and execute the Super Dev workflow.
Python CLI
The governance core. It handles installation, repair, state, quality gates, release checks, and delivery logic.
- super-dev
- doctor / detect / update
- review / quality / release readiness
Host protocol surfaces
Hosts consume Super Dev through commands, rules, AGENTS, steering, subagents, and skills depending on the official model.
- slash / text trigger
- project-level surfaces
- user-level surfaces
Project artifacts
Knowledge bundles, the three core docs, Spec, runtime verification, and delivery outputs define the actual workflow state.
- knowledge/
- output/*
- .super-dev/changes/*
Trigger Model
Trigger model
There are only two trigger syntaxes. Learn those first, then inspect the host protocol surfaces when needed.
Slash hosts
SlashThe host enters the Super Dev pipeline through official commands, workflows, rules, or subagents.
Text-trigger hosts
Text triggerThe host maps the text trigger through AGENTS, project rules, steering, or a compatibility skill surface.
Host Matrix
Host matrix
This matrix lists trigger style, protocol surface, and maturity for each supported host.
CLI
8IDE
8Pipeline
Pipeline
The trigger is short. The actual value is the enforced flow behind it: research, documentation, approval, implementation, verification, quality, and delivery.
Comparable-product research
Use the host web tools first to study adjacent products, interaction patterns, differentiation, and commercial signals.
Requirement expansion
Fill in boundaries, edge cases, acceptance criteria, and priorities before any implementation starts.
Three core docs
Generate PRD, Architecture, and UI/UX as the auditable execution baseline.
User confirmation gate
Pause after the docs. No Spec and no coding until the user confirms or requests revisions.
Spec / Tasks
Create the proposal and task breakdown only after approval.
Frontend first
Build the frontend first, make it runnable and reviewable, then move deeper into implementation.
Backend & integration
Complete the APIs, service layers, data flows, and real end-to-end interactions.
Quality gates
Run UI review, red-team review, security, performance, and architecture threshold checks.
Delivery & release rehearsal
Only finish after the delivery package is ready and release rehearsal passes.
Workflow Control
Workflow control
If the project is already in a later stage, you do not need to restart from zero. Inspect the current state, return to a phase, jump to a phase, or manually clear a gate and continue.
Return to the three core docs
When scope changes or the user adds requirements, move back to docs and update the PRD / Architecture / UI/UX set before continuing.
super-dev run prd
super-dev run architecture
super-dev run uiux
# or return to the docs stage
super-dev jump docsReturn to frontend / backend / quality
Use phase control when the UI needs another pass, APIs must be realigned, or quality checks must be rerun before release.
super-dev run frontend
super-dev run backend
super-dev run qualityJump and confirm
Use jump when you already know the target phase. Use confirm when a workflow gate must be cleared manually.
super-dev status
super-dev jump quality
super-dev confirm docs --comment "core docs approved"
super-dev confirm preview --comment "preview approved"
super-dev run --resumeKnowledge & Gates
Knowledge and gates
Local knowledge, approval gates, runtime verification, and delivery standards define how the workflow runs.
Knowledge-first execution
When knowledge/ and a knowledge bundle exist, the host reads them before external research.
- knowledge before research
- phase-based mapping into PRD / Architecture / UI/UX
- continued reuse in quality and delivery
Inspect impact before changing critical flows
Before refactoring a mature repo, changing auth, reshaping APIs, or touching major state flows, run impact analysis so the host starts with the likely blast radius.
- super-dev repo-map
- super-dev impact "change description" --files ...
- review scope before coding
Codebase intelligence and regression guard
Do not let the host guess its way through a large repo. Generate the dependency graph first, then turn impact analysis into an executable regression checklist.
- super-dev dependency-graph
- super-dev regression-guard "change description" --files ...
- lock the regression focus before modifying critical paths
Frontend runtime gate
A page file existing is not enough. A passing frontend runtime report is required before later stages continue.
- preview.html
- frontend-runtime.json
- backend starts after runtime verification
Quality & delivery gates
UI review, Spec Quality, delivery packaging, release rehearsal, and release readiness define completion.
- UI Review
- Spec Quality
- Proof Pack / release readiness
Commands
Commands
Keep the critical commands visible: install, onboarding, codebase intelligence, impact analysis, regression guard, bugfix, approval, quality, release checks, and update.
Install & bootstrap
pip install -U super-dev
# or
uv tool install super-dev
# open the host installer
super-devOnboarding & repair
super-dev onboard --host claude-code --force --yes
super-dev doctor --host trae --repair --force
super-dev integrate validate --auto
super-dev detect --jsonCodebase intelligence & impact
super-dev repo-map
super-dev dependency-graph
super-dev impact "Change the login flow" --files services/auth.py
super-dev regression-guard "Change the login flow" --files services/auth.pyBugfix mode
super-dev fix "Fix login 500 and add regression verification"Spec quality and scaffolding
super-dev spec propose add-billing --title "..." --description "..." --no-scaffold
super-dev spec scaffold add-billing
super-dev spec quality add-billing
super-dev spec quality add-billing --jsonApprove & resume
super-dev review docs --status confirmed --comment "core docs approved"
super-dev run --resumeWorkflow control
super-dev status
super-dev run research
super-dev run prd
super-dev run architecture
super-dev run uiux
super-dev run frontend
super-dev run backend
super-dev run quality
super-dev jump docs
super-dev jump quality
super-dev confirm docs --comment "core docs approved"Quality / release / update
super-dev quality --type all
super-dev release proof-pack
super-dev release readiness --verify-tests
super-dev update --check
super-dev updateTroubleshooting
Troubleshooting
Most failures happen because the host did not load commands, rules, AGENTS, steering, or skills. Check the integration surface before you blame the trigger.
Troubleshooting order
- 1Run super-dev doctor --host <host> --repair --force.
- 2Verify that the project-level and user-level surfaces reported by onboarding actually exist.
- 3Close the host completely, reopen the project, and start a fresh chat.
- 4Use a smoke prompt before trying the real requirement.
- 5If the host starts coding immediately, assume the current session did not reload the rules.
Smoke validation
# slash hosts
/super-dev "Do not start coding. Reply only with SMOKE_OK and explain that you will do research first, then generate the three core docs, then wait for confirmation."
# non-slash hosts
super-dev: Do not start coding. Reply only with SMOKE_OK and explain that you will do research first, then generate the three core docs, then wait for confirmation.