Suite manifest (main.json)

A suite manifest (main.json) lists one or more .stk files to run together. The runner entrypoint for a packaged test suite is typically:

strikekit run main.json

Use a manifest when you want to split flows across files (for example auth bootstrap + feature smoke) while keeping one shared browser session across the whole run.

Schema

main.json has two fields:

Field	Type	Required	Meaning
`name`	string	No	Human-readable suite name in reports. If omitted, the runner uses the manifest directory name.
`files`	string[]	Yes	Ordered list of `.stk` paths relative to the directory that contains `main.json`.

Minimal example (single file):

{
  "name": "Acme Ops Full Showcase",
  "files": [
    "acme-ops-full-showcase.stk"
  ]
}

Multi-file example (login first, then feature):

{
  "name": "Checkout E2E",
  "files": [
    "auth/login.stk",
    "checkout/payment.stk"
  ]
}

Files run top to bottom. Cookies, page state, and @@ group slots from an earlier file are still available in later files.

Folder layout

Place main.json beside your .stk files (or in a parent folder that owns them):

stk-tests/
├── main.json
├── auth/
│   └── login.stk
├── checkout/
│   └── payment.stk
└── smoke/
    └── dashboard.stk

Example manifest for that layout:

{
  "name": "Web smoke",
  "files": [
    "auth/login.stk",
    "smoke/dashboard.stk",
    "checkout/payment.stk"
  ]
}

Paths in files are resolved from the manifest directory, not from your shell cwd.

How to add a new file

Create the .stk file under the same tree as main.json (for example reports/export.stk).
Open main.json and append the relative path to the files array.
Choose the right position — order matters. Put bootstrap steps (login, seed data) before scenarios that depend on that state.
Run the suite, not the new file alone, when you need shared session state:

strikekit run main.json
strikekit run --headed --browsers chrome main.json

Example — adding a third file:

{
  "name": "Checkout E2E",
  "files": [
    "auth/login.stk",
    "checkout/payment.stk",
    "reports/export.stk"
  ]
}

Path rules

Each entry in files must:

End with .stk
Be relative to the manifest directory (not an absolute path)
Not contain ..
Point to a file that exists when you run the suite

The files array must be non-empty and must not contain blank entries.

Run a suite

Command	Behavior
`strikekit run main.json`	Run the listed files in order
`strikekit run`	Walk up from cwd until a `main.json` is found
`strikekit run path/to/stk-tests/`	Walk up from that directory for `main.json`
`strikekit run feature.stk`	Single-file run — no shared session with other files

Filter flags apply while merging the suite:

strikekit run --tag smoke main.json
strikekit run --group "Authentication" main.json

Shared session behavior

When you run a manifest:

All listed files share one browser session (web) or one Appium session (mobile native).
A step failure in one file does not skip later files; the process exits 1 if any file failed.
@@ group slots set in an earlier file remain available in later files.

That is why login-heavy apps often use a separate auth/login.stk listed first, then feature files that assume an authenticated session — without repeating login steps in every file.

{
  "name": "Authenticated smoke",
  "files": [
    "auth/login.stk",
    "smoke/dashboard.stk"
  ]
}

Run the manifest when auth is required:

strikekit run --quiet main.json

Running smoke/dashboard.stk alone starts a new session with no cookies from login.stk.

Every .stk in a main.json must declare the same platform headers (Platform:, and for mobile the same Driver:, OS:, Device:, Package:, Activity:). You cannot mix Platform: web and Platform: api in one manifest.

Keep API-only flows in a separate .stk and run it on its own:

strikekit run acme-ops-api.stk

Single file vs suite

Approach	When to use
Single `.stk`	One self-contained flow; no login bootstrap split; quick local runs
`main.json`	Multiple files, shared session, team/CI entrypoint, Strikekit cloud sync package

First test — write a single .stk scenario
File structure — Group → Scenario → steps inside each .stk
Slots and dynamic values — @ / @@ slots persist across files in a suite
Examples — full .stk files to copy