Skip to content
SyntaxisSyntaxisSyntaxis

Getting Started

Requirements: Node.js 22 or newer, and Git.

1. Get the project in place

Section titled “1. Get the project in place”

Two starting points, depending on what you already have.

Nothing exists yet

Section titled “Nothing exists yet”

Let Syntaxis build the application first, then install itself right on top:

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

You’ll be asked which stack to use, shown the exact generator command before it runs, and then watch it initialize Git and install the workflow once you approve. Scaffolding a Stack lists everything it can build.

There’s already an app here

Section titled “There’s already an app here”

Get the application scaffolded or opened first, then lay Syntaxis over it:

Terminal window
cd my-app
git init          # only needed if the scaffolder skipped this
npx create-syntaxis@latest

The installer asks which AI tool adapters you actually want and never touches your application’s own README.md.

2. Run onboard

Section titled “2. Run onboard”

Open the project in your AI tool and run the onboarding skill — how you invoke it depends on the tool:

Tool Invocation
Claude Code /onboard
Codex $onboard
GitHub Copilot, OpenCode, others Ask the agent to run the onboard skill

/onboard figures out your real stack, its commands, your conventions, and how much visibility you want into each step along the way.

3. Write the two plans

Section titled “3. Write the two plans”

You own exactly two files:

  • syntaxis/project-plan.md — what’s being built, who it’s for, and why.
  • syntaxis/build-plan.md — an ordered feature list carrying stable numbers.

Write these directly, or talk them through with /discovery instead — that’s never required, and a plain bulleted feature list is already enough for the build plan. See Writing Your Plans for the full shape of both.

4. Generate the project overview

Section titled “4. Generate the project overview”
/overview

/overview turns the build plan into a tracked checklist — its scope and order stay untouched — and produces syntaxis/context/project-overview.md, the durable context that every other skill reads from. The first time it runs, it also offers a reviewed local commit covering your setup and plans.

5. Land your first feature

Section titled “5. Land your first feature”
/feature        →  review and approve the spec
/implement      →  build it in small, visible steps
/check          →  prove it against the running app
/audit current  →  review the code and record findings
/complete       →  final gates, archive, then merge with your approval

The Build Loop spells out exactly what each of these steps guarantees.

6. Bring in testing whenever it’s time

Section titled “6. Bring in testing whenever it’s time”

Nothing here is mandatory until you decide the project needs it:

/tests            set up a unit test runner
/tests browser    set up a browser harness
/tests mobile     set up a device harness
/test-plan        work out what testing this project actually needs

From there, the QA loop takes over — designing cases, automating whichever ones have stabilized, and running cycles that leave real evidence behind.

Where everything ends up

Section titled “Where everything ends up”
syntaxis/
├── project-plan.md       yours
├── build-plan.md         yours
├── config.json           yours
├── context/              generated context and standards
├── qa/                   test plan, cases, cycle records
└── history/              completed work, immutable

The File Reference covers the full contract for each of these.

If something feels off

Section titled “If something feels off”

Run /status for a read on where the project stands, or /doctor to check the installation itself. Troubleshooting covers the situations that come up most often.