Project setup

styre setup writes one file per repo: the project profile. It records what your project is made of and how to build and test it, so that later runs can check work against your real commands instead of guessing.

styre setup ~/code/acme-app

The profile lands at ~/.config/styre/<slug>/profile.json — outside your repo. Styre adds nothing to your project.

What the probe detects

Styre looks for manifest files and builds a component for each one it finds:

Stack	Found by	Notes
Rust	Cargo.toml	Workspace members become separate components.
Node	package.json	A root package with a frontend signal is typed sveltekit.
Python	pyproject.toml, setup.py, requirements.txt	Nested modules anchor on the first two only.
Go	go.mod
Java / Kotlin	pom.xml	Prefers ./mvnw over a system mvn.
Java / Kotlin	build.gradle, build.gradle.kts	Prefers ./gradlew over a system gradle.
Ruby	Gemfile	bundle exec rspec if there is a spec/, else bundle exec rake test.
PHP	composer.json	Pest if the project uses it, otherwise PHPUnit.

Monorepos work. Manifests are found up to three directories deep, so a repo with services/api/go.mod and apps/web/package.json comes out as two components, each with its own commands and its own paths.

Styre will not invent a test command

If a component gives no signal of how it is tested, that command is recorded as unavailable rather than filled in with a plausible guess. An honest gap shows up at verification time; a fabricated command would pass without ever running your tests. This is the same principle as the rest of the loop — a verdict has to come from something real.

What is in the profile

The parts worth knowing about:

Field	What it is
components	The detected pieces of your project. Each has a name, a kind, the paths it owns, its commands, and optionally a prepare install command.
defaultBranch	Detected from origin/HEAD. This is the base for every pull request.
checksSystem	How CI status is read — github, external, or none.
repoCommands	Repo-wide commands that are not tied to one component.
promptVars	Free-form values of your own, available to every prompt. Never written by setup.
runtimeContext	What the probe worked out about your topology, data, caching, observability, config, docs and release process.

paths matter more than they look: they decide which component a change belongs to, and therefore which commands run to verify it.

Re-running setup

Run it again whenever the shape of the project changes — a new service, a new test runner, a component that moved:

styre setup ~/code/acme-app

By default a re-run enriches the existing profile rather than replacing it, so anything you resolved by hand survives. To throw the old profile away and probe from scratch:

styre setup ~/code/acme-app --force

--force discards your edits

A forced re-probe drops hand-resolved values, including anything you fixed up in runtimeContext. Use it when the profile is genuinely stale, not as a routine refresh.

Editing the profile by hand

The profile is plain JSON and is meant to be edited. The two most common reasons:

A command is wrong or missing. Fix it in the component’s commands and it stays fixed — a normal re-run will not clobber it.

Setup told you it needs input. When the probe cannot work out part of your runtime context, it says so and names the sections:

setup: NEEDS INPUT — the probe could not determine these runtime-context sections.
       Edit ~/.config/styre/acme-app/profile.json and set presence/detail
       (or re-run after adding tooling):
         - caching
         - observability

This is not an error and the profile is already written. Filling these in gives later runs more to work with; leaving them alone is also a valid choice.

You want to tell every run something the probe cannot detect. promptVars is a set of your own key/value pairs, passed into every prompt. Setup never writes this field, so it is yours to keep.

The one that is wired up for you is stack, which fills the “Project stack notes” slot in the design and implement prompts and is empty until you set it:

{
  "slug": "acme-app",
  // …
  "promptVars": {
    "stack": "Postgres via Drizzle — no raw SQL. All money values are integer cents."
  }
}

House conventions, a library to prefer, a pattern to avoid: anything a new engineer would be told on their first day and no probe could work out on its own.

Do not reuse a name the runner computes

promptVars is applied last, so a key that collides with a value Styre works out itself — such as test_plan, files_to_touch, authored_checks or feedback — replaces it silently. Stick to stack and names of your own.

Before a run will start

A run refuses to begin unless every component has a resolved build, test and check command. That is deliberate: a half-configured profile would produce work that looks verified without being verified.

If a profile was written by an older version of Styre, it is rejected rather than silently migrated, and the message tells you to re-run styre setup.

Useful flags

Flag	What it does
--force	Discard the existing profile and probe from scratch.
--checks <github|external|none>	Override how CI status is read.
--slug <name>	Store the profile under a different project name.
--out <path>	Write the profile somewhere else entirely.

See the CLI reference for the full set.

---

Next: Writing a ticket — what Styre needs from a ticket to deliver it.