Onboarding a Site

The default onboarding flow is freeform. Scenarios are useful, but optional.

The default discovery mode is human-guided. SiteKit records what happens while you click through the site capabilities you want to expose.

sitekit onboard source_portal \
  --url https://app.example.test \
  --goal "Expose user directory, event records, report downloads, and admin update operations."

Onboarding requires an LLM provider because analysis and review are model-assisted. Configure one before the first analyze run:

sitekit config set llm.provider openai
sitekit config set llm.model gpt-5
sitekit config set llm.apiKey.env OPENAI_API_KEY

SiteKit opens an isolated browser profile. Log in normally, then spend ten minutes exercising the site capabilities you want to expose. Open directory pages. Filter event lists. Edit a safe draft. Visit screens that reveal IDs, lookup values, report details, pagination, and search behavior.

Deterministic Discovery

After login and before task-specific clicking, SiteKit should run deterministic discovery passes when the site allows them:

1. Bundle analysis parses frontend JavaScript for fetch, XHR, axios, route helpers, and GraphQL call sites.
2. GraphQL discovery uses introspection when enabled, then falls back to persisted queries and operation text found in bundles.
3. Convention sniffing checks for OpenAPI, schema documents, and known metadata paths.

These passes do not replace recording. They create a static inventory that becomes the denominator for coverage.

Autonomous Mode

For unfamiliar sites, SiteKit can let an LLM explore the site in a controlled browser session:

sitekit onboard expense_portal \
  --url https://app.example.test \
  --goal "Find draft creation, submitted record status, receipt uploads, and approval settings." \
  --mode autonomous

Autonomous mode uses the same capture pipeline, but the browser actions come from an LLM agent with time, scope, and write-safety limits. The resulting adapter still goes through review, tests, and deterministic generation.

What SiteKit Records

• Network requests and responses from Chrome DevTools Protocol.
• Page titles and URLs so requests can be tied to screens.
• Request bodies, response shapes, GraphQL operation names, and headers.
• Cookie metadata needed to understand auth, without committing raw secrets.
• User notes, if supplied during recording.
• JavaScript bundle references when available, so endpoints can be found before every UI path is clicked.

sitekit note "Opening the user directory"
sitekit note "Editing a draft record, but not saving"
sitekit note "This lookup powers location mapping"

Optional Scenarios

Scenarios organize recordings and make repairs easier later.

sitekit record source_portal --scenario records-list
sitekit record source_portal --scenario events-list
sitekit record source_portal --scenario reports-export

For the first adapter, a messy full-session capture is fine. SiteKit can split the capture into candidate operations during analysis.

Analyze

sitekit analyze source_portal

The analyzer creates a draft adapter:

adapters/source_portal/
  adapter.yaml
  discovery.md
  questions.md
  fixtures/redacted/
  schemas/
  tests/

The deterministic pass clusters routes, normalizes IDs, detects pagination, extracts JSON and GraphQL schemas, and identifies likely auth strategy.

It can also detect when an operation should not be HTTP-backed. If useful work only happens inside frontend JavaScript or UI state, SiteKit can propose a browser-backed or hybrid operation instead of forcing a fragile internal API.

The LLM pass proposes meanings:

• Which calls matter for the stated goal.
• Which routes are noise.
• Which endpoints should become domain operations.
• Which fields need human review.
• Which tests should prove the adapter is not merely plausible.

Coverage

Discovery should report what it saw and what it missed:

Coverage
  static inventory: 47
  exercised routes: 31
  exercised coverage: 66%
  observed API routes: 23
  candidate operations: 11
  auth strategies: 2
  forms observed but not submitted: 3
  GraphQL operations found in bundles: 18
  endpoints found in bundles but not exercised: 5

Coverage is not a proof that every useful operation was found. It is a review tool that helps decide whether to record another pass, run autonomous discovery, or accept a focused adapter.

sitekit coverage source_portal --list-unexercised

Review

sitekit review source_portal

Review is an interview informed by the capture:

I saw POST /api/events/search with include_archived=false.
Should this become events.list()?

I saw /settings/active_workspace/:id before record reads.
Does this set server-side workspace scope?

I saw statusLabel and statusCode in separate fields.
Should the generated client preserve both values?

Confirmed answers are written back into adapter.yaml as durable adapter facts, not loose chat history.

Generate

sitekit test source_portal --fixtures
sitekit test source_portal --live
sitekit generate source_portal --target typescript --target python

Generation is deterministic. If the adapter spec is unchanged, generated client code should be unchanged.