Install once, then go back to the host and start the real work.
This page is not a protocol dictionary. It exists to move you from install to the host first prompt and the first five minutes. What matters is simple: install, go back to the host, start with research, then generate the three core docs and wait for approval.
Install the CLI first. Then run super-dev in the terminal to open the host installer and write the required protocol surfaces.
uv tool install super-dev
super-dev
super-dev update
super-dev uninstallv2.4.0 Highlights
v2.4.0 Current Focus
Version 2.4.0 keeps pushing Super Dev back toward its core product shape: project-first onboarding, a unified host matrix, standard-flow vs. SEEAI readiness, host-specific first prompts and resume guidance, clearer post-install verification, and a stronger UI contract that pushes design quality away from generic AI-looking output.
Project-First Onboarding
onboard / setup / install / start now write project-level protocol surfaces by default. User/global surfaces are explicit opt-ins instead of silent defaults.
Unified 26-Host Matrix
CLI 12, IDE 9, and desktop assistants 5 now sit inside the same current host matrix. Claude / Claude Code, Codex / Codex CLI, and the Trae family are all split into separate entries.
Host-Specific First Prompts
Each host now exposes a standard-flow first prompt, competition-flow first prompt, resume guidance, and repair priority instead of one generic trigger script.
Standard vs. SEEAI Readiness
Host reports now explicitly distinguish "ready for standard flow" from "ready for SEEAI competition flow" rather than treating written files as equivalent to a working host runtime.
Current project focus
The installer and smoke guide now tell users which pages, previews, and delivery signals matter first for the current project.
Post-Onboard Self-Check
The installer now tells users what to verify first so onboarding is not mistaken for real readiness.
Project-Level SEEAI Supplements
The super-dev-seeai project supplements now participate in formal injection closure, so competition mode is no longer a manual afterthought.
UI Design Anti-Slop Upgrade
The UI contract now freezes art-direction candidates, visual philosophy, anti-AI-slop guardrails, and a five-dimension critique rubric; the screenshot-grade visual gate blocks flat, generic, template-looking pages from passing delivery.
Core path
The real development loop starts after you return to the host.
The terminal only handles install, upgrade, and cleanup. The real first pass happens inside the host: research, the three core docs, approval gates, spec, implementation, preview validation, quality gates, and delivery all move through one governed path.
The terminal only onboards
The installer connects the current host and tells the user what to type next.
The first pass happens in-host
Research, the three core docs, approval gates, and the first frontend preview stay in the host conversation.
Key artifacts stay on disk
Research, PRD, Architecture, UI/UX, Spec, runtime reports, and delivery evidence are written back into the repo.
Installation
Installation
The terminal only handles onboarding, upgrade, and uninstall. The homepage defaults to pip; uv, source installs, and pinned versions stay in the installation docs. This section answers three public questions: which host apps are not installed for you, what the installer writes, and what to type next inside the host.
Installation notes
- The homepage and primary docs use pip as the default install path; uv remains supported but stays in the dedicated installation guide.
- Super Dev does not install Claude, Codex, Cursor, Trae, Gemini CLI, or any other host app for you.
- Running super-dev opens the installer and writes project-first host files by default; user/global enhancements are explicit opt-ins.
- The installer now exposes the recommended host, first prompts, and post-onboard checks. Droid CLI is part of the unified matrix.
uv tool install super-dev
# open the installer
super-dev
# Droid CLI / Claude Code / Codex and other hosts are onboarded from the same installer
# public terminal maintenance entrypoints
super-dev update
super-dev uninstallFirst 5 Minutes
The first 5 minutes after install
This is where the product either feels sharp or feels like just another setup page. After install, the terminal should get out of the way. Users should go straight back into the host, copy the first prompt, read the framework coaching focus, and confirm the host really enters the commercial delivery flow.
Leave the terminal
Installation, upgrade, and uninstall happen in the terminal. Real project work should immediately move back into the host.
- Close the host completely and reopen the project
- Use a fresh host session instead of the stale conversation
- Keep the terminal for install / update / uninstall only
Copy the first prompt exactly
Do not paraphrase. Do not preload your own background. Start with the standard-flow or competition-flow first prompt from the smoke guide so the host enters Super Dev precisely.
- Use the standard-flow first prompt for normal projects
- Use the competition-flow first prompt for SEEAI work
- The first host reply must explicitly promise research and the three-core-doc gate
Follow the smoke guide and the first prompt first
Do not paraphrase the workflow. Start with the exact standard-flow or competition-flow first prompt from the installer, then use the smoke guide to confirm the host really enters the research → three core docs → approval path.
- Copy the first prompt instead of rewriting it
- Use the smoke guide to inspect the first reply
- Confirm that research, the three core docs, and approval are all explicit
Treat UI as a delivery gate, not decoration
The screenshot-grade visual gate now blocks flat, empty, template-looking pages. Users should demand stronger visual direction from the first UI pass, not after implementation is “finished.”
- Lock art direction before page implementation
- Reject placeholder-grade flat UI
- Expect UI review / quality / release to keep enforcing this
What the installer writes
What the installer writes
You should not have to memorize every host file path. The installer writes the project-level files the current host needs, and user-level enhancements stay optional.
Project-level host files
The installer writes the files this repository needs so the current host can recognize and enter Super Dev here first.
- project-first by default
- make this repo work first
- no silent global pollution
Optional user-level enhancements
Global or user-level host surfaces are opt-ins. They are useful when you use the same host constantly, but they are no longer the default.
- not the default path
- useful for repeat host setups
- project-first still comes first
The project artifacts that keep accumulating
Research, the three core docs, Spec, runtime verification, and delivery evidence are what actually carry the workflow forward.
- knowledge/
- output/*
- .super-dev/changes/*
First prompt
First prompt
Most users only need to remember the first prompt for their host. Slash hosts use /super-dev, Codex CLI uses $super-dev, and text-first hosts use super-dev:. The matrix handles the edge cases.
Slash hosts
SlashWhen the installer has already written the right project-level files for the current host, this is the shortest way to enter Super Dev. Codex App/Desktop also exposes the enabled super-dev Skill in the `/` list.
Text-trigger hosts
Text triggerText-first hosts do not depend on a slash list. They treat this line as the project entrypoint, and the installer tells you whether that host is already ready.
Host Matrix
Host matrix
Read this table for three things only: what you will type first, what Super Dev loads first, and whether that host is genuinely ready to enter the standard product path or SEEAI.
CLI
12IDE
9Desktop assistants
5Pipeline
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 & final checks
Only finish after the delivery package, preview verification, and the final review pass are complete.
How to continue in-host
Workflow control
The public path no longer expects end users to memorize a long list of terminal workflow commands. After install, continue, revise, confirm, and recover primarily inside the host conversation.
Keep revising the three core docs
When scope changes or the user adds requirements, keep the work inside the host and continue revising PRD / Architecture / UI/UX instead of bouncing back to terminal flow-control commands.
/super-dev Add the missing scope and keep revising PRD / Architecture / UI/UX. Do not start coding.
super-dev: The plan is still wrong. Keep revising the three core docs and wait for confirmation again.Continue the current stage
When UI, APIs, or release checks need another pass, keep the user in the host conversation and continue the same Super Dev flow.
/super-dev Continue the current flow
/super-dev What is the next step right now?
super-dev: Continue the current flow. Do not restart the project from scratch.Clear the key gates in-host
Docs approval, preview approval, UI revision closure, architecture revision closure, and quality remediation closure should all be expressed inside the host first.
/super-dev The core docs are approved. Continue.
/super-dev The frontend preview is approved. Continue.
super-dev: UI revision is finished. Continue the current flow.
super-dev: Quality remediation is finished. Continue the current flow.Research, preview, and delivery 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 repo-map, feature-checklist, and impact analysis so the host starts with scope truth instead of guesses.
- super-dev repo-map
- super-dev feature-checklist
- super-dev impact "change description" --files ...
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; when a framework playbook exists, its execution and delivery evidence become part of the gate too.
- preview.html
- frontend-runtime.json
- real preview evidence and delivery materials
- backend starts after runtime verification
Quality & delivery gates
UI review, spec completeness, delivery packaging, and the final review pass define completion. The screenshot-grade visual gate now blocks flat, overly empty, template-looking pages.
- UI Review
- Screenshot-level visual gate
- Spec Quality
- Final delivery checks
The only entrypoints to remember
The only entrypoints to remember
The public path only needs two places: install/update/uninstall in the terminal, then first-prompt / continue / approve inside the host. The rest of the CLI remains available for maintenance and advanced troubleshooting.
Public terminal entrypoints
uv tool install super-dev
super-dev # open the host installer
super-dev update # update to the latest version
super-dev uninstall # remove injected host surfacesNormal usage inside the host
/super-dev your requirement
/super-dev Continue the current flow
/super-dev What is the next step right now?
/super-dev The core docs are approved. Continue.
super-dev: your requirement
super-dev: Continue the current flow
super-dev: Quality remediation is finished. Continue the current flow.Troubleshooting
Troubleshooting
Most failures happen because the host did not reload the project files written by onboarding. First check that the project files exist, then verify the host was fully reopened and a fresh session was used.
Troubleshooting order
- 1Run super-dev again and confirm the installer still recognizes the current host.
- 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.