Skip to main content
The Suxiaoqiang CLI synchronizes a superun project’s files with a local directory. Its terminal command is sxq. You can edit the project in your preferred IDE or with an AI coding agent, push changes back, build a preview, and deploy to production.
The CLI shares its name with superun’s in-product AI assistant, Suxiaoqiang, but they are different things. The assistant provides guidance in superun; the sxq command manages a project from your terminal.
It is a project development and release tool. It does not replace the superun CLI, which operates a running app’s business data and APIs.

​
Before you start

You need:
  • Node.js 18 or later;
  • access to the superun project you want to link;
  • the project’s sessionId, shown in its superun project URL.

​
Install and log in

sxq login opens a browser to authorize the CLI. You can also use an existing token:
Create an empty directory, link it to the remote project, and pull its files:
Linking verifies that the project belongs to the signed-in account. The first pull is full; later pulls are incremental and use a three-way merge.

​
Work safely with Git

.sxq/attachments.json stores the remote baseline last synchronized in the current directory; it is not a Git index. The .sxq/ directory is intentionally excluded from Git, so switching branches changes the source files without switching this baseline. Files that are older, different, or absent on the new branch can look like intended modifications or deletions even when nobody changed or removed them manually.
After switching branches in a directory that contains .sxq, do not run sxq push immediately. Return to the allowed push branch, run sxq pull, then inspect git status, git diff, and the complete push plan shown by the CLI. If an unexpected number of files appear as modified or deleted, cancel the push and verify that the worktree matches its .sxq baseline.
Git projects allow pushes only from main by default. If the project uses another primary branch, configure it with:
For branches used concurrently, prefer a separate Git worktree for each branch. Run sxq link and sxq pull separately in every worktree so each directory maintains its own .sxq baseline. Never copy .sxq between repositories, worktrees, branches, or partial source directories, and never force-add it to Git. sxq push -f bypasses only the branch restriction; it does not prove that the current files match your intent. Use it only after confirming the exact branch and reviewing the complete plan. It cannot bypass safety checks for reset, rebase, rewritten history, or a mismatched worktree.

​
Edit and push changes

After editing locally, push the changes back to superun:
sxq push pulls remote changes first. If a file cannot be merged cleanly, the command stops and writes Git-style <<<<<<<, =======, and >>>>>>> conflict markers into the file. After pulling and merging, the CLI lists every added (+), modified (M), and deleted (D) file and asks for y/N confirmation. -y keeps the plan visible but skips the input prompt; use it only after those exact paths have been reviewed and authorized. Do not use -f -y as a generic retry after a failed push. Resolve every conflict, remove the markers, test the result, and run sxq push again. If the plan is unexpected—especially if many files suddenly appear as M or D—cancel instead of continuing. Files matched by the project’s .gitignore, plus built-in entries such as node_modules, dist, and .git, are not synchronized.

​
Preview and deploy

Update the frontend preview and wait for the build to finish. front is the default target and can be omitted:
Deploy only the Edge Functions from the latest mainline version to preview:
The legacy sxq publish command remains available and behaves like sxq preview front.
When the preview is ready and verified, open the project release confirmation page:
Check release state without deploying:
sxq deploy only opens the release confirmation page in a browser; it does not call the release API directly. Verify the linked project, preview, and target region on that page, then let the user complete the final confirmation.

​
Apply database migrations

Create migration files under supabase/migrations/ using this format:
The prefix must be an exact 14-digit yyyyMMddHHmmss timestamp, for example:
The timestamp prefix determines migration replay order and must be unique across the project. Do not use Unix timestamps, dates with separators, shortened dates, or any other prefix width. Before creating a migration, check the existing filenames. If the timestamp is already in use, generate a later one instead of reusing it. Then apply migrations that do not yet exist remotely:
The CLI pulls the remote baseline first and identifies pending migrations. If any new SQL filename does not contain an exact 14-digit timestamp prefix, or if a pending migration reuses a timestamp from another pending or remote migration, the entire batch aborts before executing any SQL. Otherwise, migrations run in ascending timestamp order and stop at the first failure. After a migration succeeds, the server saves it as a project attachment. Do not send migration files with sxq push; the CLI blocks them.

​
Command reference

For CI or an AI agent, add -y only after the complete push plan has been reviewed and authorized. Without -y, a non-interactive push stops before submitting instead of waiting indefinitely. Production releases always require the user to confirm in the browser.

Suxiaoqiang CLI on npm

View the published package and current version.

Source code

Read the complete reference or report an issue.