Scaffolding a Stack

Most workflow tools tell you to scaffold the app yourself first, because framework generators refuse to run in a directory that already has files — and a Syntaxis project always has files.

Syntaxis solves that directly. /scaffold runs each stack’s own official generator and merges the result, so you can create an application before or after installing the workflow.

Supported stacks

Stack	Generator	Family
Next.js	create-next-app	Web, full stack
React + Vite	npm create vite	Web, client only
SvelteKit	sv create	Web, full stack
ASP.NET Core	dotnet new webapi	Backend
Flutter	flutter create	Mobile
React Native (Expo)	create-expo-app	Mobile
Ionic + Capacitor	@ionic/cli start	Mobile
Electron	electron-app (Forge)	Desktop
Tauri	create-tauri-app	Desktop

Syntaxis never hand-writes an application skeleton. If your stack is not listed, /scaffold finds its official generator, confirms the command with you, and follows the same approval and merge steps.

From an empty directory

mkdir my-app && cd my-app
npx create-syntaxis@latest --scaffold

The installer asks which stack, shows the exact command, confirms, runs it, initializes Git, then installs the workflow on top.

Non-interactively, name the stack explicitly:

npx create-syntaxis@latest --stack nextjs --yes

Caution

--yes without --stack is refused. Syntaxis will not pick a stack on your behalf, and --scaffold will not run in a directory that already has files.

Into a project that already has files

Run the skill instead:

/scaffold
/scaffold flutter

This is the case the installer cannot handle, and it is the point of the skill. It scaffolds into a temporary directory and merges the result under strict rules:

• Syntaxis-managed paths are never overwritten — AGENTS.md, CLAUDE.md, .agents/, .claude/, and syntaxis/.
• The generator’s .git/ is never copied. Many generators run git init; that repository is throwaway and must not replace or nest inside yours.
• Installed dependency trees are never copied. The manifest and lockfile move across, then dependencies install at the destination.
• .gitignore is merged, not replaced — only missing lines are appended.
• Your README.md and LICENSE are kept.
• Any other collision stops the merge and asks you which version to keep.

Some stacks support genuine in-place creation — flutter create . and dotnet new both write into a non-empty directory — and /scaffold prefers that when available.

Adding a second stack

A mobile client next to a web app, or an API next to a front end, is a normal second run:

/scaffold dotnet

The new application lands in its own subdirectory, and the report says which one. One application per invocation; ask twice for two.

What happens afterwards

/scaffold writes the real commands the generator produced into the AGENTS.md Commands section — dev server with its URL, build, start, lint, typecheck, plus the working directory for anything that does not run from the repository root. Later skills read those commands rather than guessing.

Then it proves the scaffold: install, build, and start the app. A generator that exits zero is not proof; a project that cannot install or build is a failed scaffold and gets reported as one.

What it will not do

• Install or upgrade a system toolchain. Missing .NET, Flutter, or Rust is reported with what to install, not silently fixed.
• Switch your package manager.
• Add a router, ORM, state library, UI kit, auth, or Docker. Those are feature decisions for /feature.
• Commit, push, or deploy.

Next

Run /onboard to tune the workflow to the stack you just created.