Start with install, host onboarding, triggers, pipeline, and delivery.
This documentation covers installation, host onboarding, triggers, pipeline stages, 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, or any host application.
- Running super-dev opens the host installer and writes the required protocol surfaces into the host and the project.
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
10IDE
7Pipeline
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.
Knowledge & 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
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, red-team review, delivery packaging, release rehearsal, and release readiness define completion.
- UI Review
- delivery ready
- rehearsal passed
Commands
Commands
Keep the critical commands visible: install, onboarding, codebase intelligence, impact analysis, 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 detect --jsonCodebase intelligence & impact
super-dev repo-map
super-dev impact "Change the login flow" --files services/auth.pyApprove & resume
super-dev review docs --status confirmed --comment "core docs approved"
super-dev run --resumeQuality / release / update
super-dev quality --type all
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.