checkly 0.0.0-canary.7166ed8

package/dist/ai-context/skills-command/references/configure-icmp-monitors.md

@@ -0,0 +1,42 @@
+# ICMP Monitor
+
+- Import the `IcmpMonitor` construct from `checkly/constructs`.
+- Reference [the docs for ICMP monitors](https://www.checklyhq.com/docs/constructs/icmp-monitor/) before generating any code.
+- When adding `assertions`, always use `IcmpAssertionBuilder` class.
+- Latency assertions require a property parameter: `'avg'`, `'min'`, `'max'`, or `'stdDev'`.
+- Use `degradedPacketLossThreshold` and `maxPacketLossThreshold` for packet loss thresholds (percentages).
+- **Plan-gated properties:** `retryStrategy`, `runParallel`, and higher frequencies are not available on all plans. Check entitlements matching `UPTIME_CHECKS_*` before using these. Omit any property whose entitlement is disabled. See `npx checkly skills manage` for details.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/icmp-monitor/
+
+```typescript
+import { AlertEscalationBuilder, Frequency, IcmpAssertionBuilder, IcmpMonitor, RetryStrategyBuilder } from 'checkly/constructs'
+
+new IcmpMonitor('example-icmp-monitor', {
+  name: 'Example ICMP Monitor',
+  request: {
+    hostname: 'INSERT_HOSTNAME',
+    pingCount: 10,
+    assertions: [
+      IcmpAssertionBuilder.latency('avg').lessThan(100),
+      IcmpAssertionBuilder.latency('max').lessThan(200),
+    ],
+  },
+  degradedPacketLossThreshold: 10,
+  maxPacketLossThreshold: 20,
+  activated: true,
+  locations: [
+    'eu-central-1',
+    'eu-north-1',
+  ],
+  frequency: Frequency.EVERY_10M,
+  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
+    amount: 0,
+    interval: 5,
+  }, {
+    enabled: false,
+    percentage: 10,
+  }),
+  retryStrategy: RetryStrategyBuilder.noRetries(),
+})
+```

package/dist/ai-context/skills-command/references/configure-multistep-checks.md

@@ -0,0 +1,34 @@
+# MultiStep Checks
+
+- Import the `MultiStepCheck` construct from `checkly/constructs`.
+- Generate a separate `.spec.ts` file for the Playwright code referenced in the `MultiStepCheck` construct.
+- Use the `code.entrypoint` property to specify the path to your Playwright test file.
+- For env vars Checkly exposes at runtime (`CHECK_ID`, `REGION`, `RUNTIME_VERSION`, etc.), see `npx checkly skills configure environment`.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/multistep-check/
+
+```typescript
+import { AlertEscalationBuilder, Frequency, MultiStepCheck, RetryStrategyBuilder } from 'checkly/constructs'
+
+new MultiStepCheck('example-multi-step-check', {
+  name: 'Example Multistep Check',
+  code: {
+    entrypoint: './example-multistep-check.spec.ts',
+  },
+  activated: true,
+  locations: [
+    'eu-central-1',
+    'eu-west-2',
+  ],
+  frequency: Frequency.EVERY_1H,
+  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
+    amount: 0,
+    interval: 5,
+  }, {
+    enabled: false,
+    percentage: 10,
+  }),
+  retryStrategy: RetryStrategyBuilder.noRetries(),
+  runParallel: true,
+})
+```

package/dist/ai-context/skills-command/references/configure-playwright-checks.md

@@ -0,0 +1,70 @@
+# Playwright Check Suites
+
+- Import the `PlaywrightCheck` construct from `checkly/constructs`.
+- Use Playwright Check Suites to run an existing Playwright project. Do not rewrite tests as Browser or Multistep Checks unless the user asks.
+- Set `playwrightConfigPath` relative to the `.check.ts` file that declares the construct, not the project root. If the check is in `monitoring/suites.check.ts` and the config is at the repo root, use `"../playwright.config.ts"`.
+- Use `pwProjects` only when the user wants specific Playwright projects. Values must match the Playwright project `name`, such as `"Cart & Checkout"`, not a folder or slug. Wrong names can deploy but run zero tests.
+- Use `pwTags` only when the user wants tag-based selection.
+
+## Dependencies
+
+- Use the user's `package.json` and lock file for dependencies. Do not add dependency declarations to check code.
+- For private packages or custom registries, include the registry config file, usually `.npmrc`, with `include`.
+- The `.npmrc` should reference a Checkly environment variable such as `${NPM_TOKEN}`. Tell the user that the token must exist in Checkly before `deploy` or `trigger`.
+- Use `installCommand` only when the default package-manager install command is not enough.
+- In Checkly CLI v8.0.0 and later, `include` patterns resolve relative to the Playwright config directory, not the project root. If `playwrightConfigPath` points to a subdirectory, adjust `include` globs. Example: `playwrightConfigPath: "./e2e/playwright.config.ts"` with root `.npmrc` needs `include: ["../.npmrc"]`.
+
+## Install troubleshooting
+
+- The execution environment is Linux and non-root, and it does not include a C/C++ compiler. Browsers are pre-installed, so never add `playwright install`, `npx playwright install`, Puppeteer browser downloads, or similar browser installation commands.
+- If `scripts.postinstall`, `scripts.prepare`, or `scripts.install` references missing files, downloads browsers, sets up git hooks, or compiles native code, set `installCommand` to skip project lifecycle scripts and rebuild dependency scripts:
+  - npm: `npm install --ignore-scripts && npm rebuild`
+  - pnpm: `pnpm install --ignore-scripts && pnpm rebuild`
+- Flag likely dependency problems before suggesting a deploy:
+  - `puppeteer` is usually unnecessary because browsers are pre-installed.
+  - Native dependencies that require a compiler, such as `sharp` or `better-sqlite3`, may fail.
+  - `fsevents` must be optional; a locked non-optional `fsevents` dependency can fail on Linux.
+  - `workspace:*` dependencies must be included in the uploaded bundle.
+  - Private registries must have auth configured through Checkly environment variables.
+
+## Runtime model
+
+- Do not use `runtimeId` for Playwright Check Suites. Browser and Multistep Checks use `runtimeId`; Playwright Check Suites use project dependencies plus `engine`.
+- Omit `engine` unless the user explicitly asks to override the JavaScript engine or version.
+- If an engine override is needed, import `Engine` from `checkly/constructs` and use `Engine.node("24")` or `Engine.bun("1.3")`.
+- If no engine is configured or detected, Checkly defaults to Node.js 22. Node.js engine majors map to pinned patch versions: `22` -> `22.14.0`, `24` -> `24.13.1`, and `26` -> `26.2.0`.
+
+```typescript
+import { PlaywrightCheck } from "checkly/constructs"
+
+new PlaywrightCheck("checkout-suite", {
+  name: "Checkout suite",
+  playwrightConfigPath: "./e2e/playwright.config.ts",
+  // Include root .npmrc for private package or registry auth.
+  include: ["../.npmrc"],
+})
+```
+- `playwrightConfigPath` is resolved **relative to the `.check.ts` file that declares the construct**, not the project root. If your check lives in `monitoring/suites.check.ts` and your config in `playwright.config.ts` at the repo root, use `'../playwright.config.ts'`.
+- use `pwProjects` if you're tasked to reuse a Playwright project. Values must match the `name` field of each project in your `playwright.config.ts` (e.g. `'Cart & Checkout'`), **not** the directory slug. Mismatched names deploy silently and resolve to zero tests.
+- use `pwTags` if you're tasked to reuse a Playwright tag.
+- Use `include` only for non-code assets that specs read via `fs` at runtime (markdown, JSON fixtures, snapshots). Test files and anything reachable through `import` are already bundled via Playwright's project discovery and the import graph — listing them in `include` is redundant. Globs resolve **relative to the directory of `playwrightConfigPath`**, not the project root and not the `.check.ts`.
+- For env vars Checkly exposes at runtime (e.g. `CHECKLY=1` for "am I running on Checkly?"), see `npx checkly skills configure environment`.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/playwright-check/
+
+```typescript
+import { PlaywrightCheck } from "checkly/constructs"
+
+const playwrightChecks = new PlaywrightCheck("multi-browser-check", {
+  name: "Multi-browser check suite",
+  playwrightConfigPath: "./playwright.config.ts",
+  // Playwright Check Suites support all browsers
+  // defined in your `playwright.config`
+  pwProjects: ["chromium", "firefox", "webkit"],
+  // Bundle non-code assets that specs read via `fs` at runtime.
+  // Test files and anything reachable through `import` are already
+  // bundled — `include` is only for files outside the import graph.
+  // Globs resolve relative to the playwright config's directory.
+  include: ["fixtures/**/*.json", "docs/**/*.md"],
+});
+```

package/dist/ai-context/skills-command/references/configure-supporting-constructs.md

@@ -0,0 +1,120 @@
+# Supporting Constructs
+
+## Status Page
+
+- Import the `StatusPage` construct from `checkly/constructs`.
+- Status pages are used to display the status of your services to your users.
+- A Status Page consists of cards which include Status Page Services.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/status-page/
+
+```typescript
+import { StatusPage } from 'checkly/constructs'
+import { exampleService } from './services/example-service.check'
+
+new StatusPage('example-status-page', {
+  name: 'Example Status Page',
+  url: 'example-status-page',
+  cards: [
+    {
+      name: 'Example service',
+      services: [
+        exampleService,
+      ],
+    },
+  ],
+  customDomain: 'status.example.com',
+  defaultTheme: 'AUTO',
+})
+```
+
+## Status Page Service
+
+- Import the `StatusPageService` construct from `checkly/constructs`.
+- Status Page Services are used to represent individual services on a Status Page.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/status-page-service/
+
+```typescript
+import { StatusPageService } from 'checkly/constructs'
+
+export const exampleService = new StatusPageService('example-status-page-service', {
+  name: 'Example Service',
+})
+```
+
+## Dashboard
+
+- Import the `Dashboard` construct from `checkly/constructs`.
+- Dashboards are used to display the results of your checks on screens external to Checkly.
+- To apply custom styling, set `customCSS` to an entrypoint object so Checkly bundles and hosts the file: `customCSS: { entrypoint: './dashboard.css' }`. Passing a raw string read with `fs.readFileSync` is rejected at deploy time.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/dashboard/
+
+```typescript
+import { Dashboard } from 'checkly/constructs'
+
+new Dashboard('example-dashboard', {
+  tags: [
+    'app:webshop',
+  ],
+  customUrl: 'example-dashboard',
+  customDomain: 'dash.example.com',
+  header: 'Example Dashboard',
+  description: 'Example dashboard',
+  width: 'FULL',
+  refreshRate: 60,
+  paginate: true,
+  paginationRate: 60,
+  checksPerPage: 15,
+  useTagsAndOperator: false,
+  hideTags: false,
+  enableIncidents: false,
+  expandChecks: false,
+  showHeader: true,
+  isPrivate: false,
+  showP95: true,
+  showP99: true,
+})
+```
+
+## Maintenance Window
+
+- Import the `MaintenanceWindow` construct from `checkly/constructs`.
+- Maintenance windows are used to pause checks during maintenance periods so no alerts are sent.
+- Checks are referenced by their tags in the `tags` property.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/maintenance-window/
+
+```typescript
+import { MaintenanceWindow } from 'checkly/constructs'
+
+new MaintenanceWindow('example-maintenance-window', {
+  name: 'Example Maintenance Window',
+  tags: [
+    'app:webshop',
+  ],
+  startsAt: new Date('2025-07-01T09:00:00.000Z'),
+  endsAt: new Date('2025-07-01T10:00:00.000Z'),
+  repeatInterval: 1,
+  repeatUnit: 'WEEK',
+  repeatEndsAt: new Date('2025-08-01T00:00:00.000Z'),
+})
+```
+
+## Private Location
+
+- Import the `PrivateLocation` construct from `checkly/constructs`.
+- Private locations are used to run checks from your own infrastructure with the Checkly Agent, an OCI compatible container.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/private-location/
+
+```typescript
+import { PrivateLocation } from 'checkly/constructs'
+
+export const examplePrivateLocation = new PrivateLocation('example-private-location', {
+  name: 'Example Private Location',
+  slugName: 'example-private-location',
+  icon: 'location',
+})
+```

package/dist/ai-context/skills-command/references/configure-tcp-monitors.md

@@ -0,0 +1,41 @@
+# TCP Monitor
+
+- Import the `TcpMonitor` construct from `checkly/constructs`.
+- When adding `assertions`, always use `TcpAssertionBuilder` class for TCP monitors.
+- **Plan-gated properties:** `retryStrategy`, `runParallel`, and higher frequencies are not available on all plans. Check entitlements matching `UPTIME_CHECKS_*` before using these. Omit any property whose entitlement is disabled. See `npx checkly skills manage` for details.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/tcp-monitor/
+
+```typescript
+import { AlertEscalationBuilder, Frequency, RetryStrategyBuilder, TcpAssertionBuilder, TcpMonitor } from 'checkly/constructs'
+
+new TcpMonitor('example-tcp-monitor', {
+  name: 'Example TCP Monitor',
+  degradedResponseTime: 5000,
+  maxResponseTime: 5000,
+  activated: true,
+  locations: [
+    'eu-central-1',
+    'eu-west-2',
+  ],
+  frequency: Frequency.EVERY_1H,
+  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
+    amount: 0,
+    interval: 5,
+  }, {
+    enabled: false,
+    percentage: 10,
+  }),
+  retryStrategy: RetryStrategyBuilder.noRetries(),
+  runParallel: true,
+  request: {
+    hostname: 'INSERT_HOSTNAME',
+    port: 4242,
+    ipFamily: 'IPv4',
+    assertions: [
+      TcpAssertionBuilder.responseTime().lessThan(200),
+      TcpAssertionBuilder.responseData().isEmpty(),
+    ],
+  },
+})
+```

package/dist/ai-context/skills-command/references/configure-url-monitors.md

@@ -0,0 +1,40 @@
+# URL Monitor
+
+- Import the `UrlMonitor` construct from `checkly/constructs`.
+- When adding `assertions`, always use `UrlAssertionBuilder`.
+- **Important:** The target URL must be publicly accessible — checks run on Checkly's cloud, not locally.
+- **Plan-gated properties:** `retryStrategy`, `runParallel`, and higher frequencies are not available on all plans. Check entitlements matching `UPTIME_CHECKS_*` before using these. Omit any property whose entitlement is disabled — Checkly applies safe defaults. See `npx checkly skills manage` for details.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/url-monitor/
+
+```typescript
+import { AlertEscalationBuilder, Frequency, RetryStrategyBuilder, UrlAssertionBuilder, UrlMonitor } from 'checkly/constructs'
+
+new UrlMonitor('example-url-monitor', {
+  name: 'Example URL Monitor',
+  activated: true,
+  locations: [
+    'eu-central-1',
+    'eu-west-2',
+  ],
+  frequency: Frequency.EVERY_5M,
+  alertEscalationPolicy: AlertEscalationBuilder.runBasedEscalation(1, {
+    amount: 0,
+    interval: 5,
+  }, {
+    enabled: false,
+    percentage: 10,
+  }),
+  retryStrategy: RetryStrategyBuilder.noRetries(),
+  runParallel: true,
+  degradedResponseTime: 5000,
+  maxResponseTime: 20000,
+  request: {
+    url: 'INSERT_URL',
+    ipFamily: 'IPv4',
+    assertions: [
+      UrlAssertionBuilder.statusCode().equals(200),
+    ],
+  },
+})
+```

package/dist/ai-context/skills-command/references/configure.md

@@ -0,0 +1,152 @@
+# Checkly Monitoring
+
+- Refer to docs for Checkly CLI v6.0.0 and above.
+- Check the Checkly CLI output to figure out into which folder the setup was generated.
+- Use the [Checkly CLI reference documentation](https://www.checklyhq.com/docs/cli/overview/).
+- Use the [Checkly construct reference documentation](https://www.checklyhq.com/docs/constructs/overview/).
+- Import and / or require any constructs you need in your code, such as `ApiCheck`, `BrowserCheck`, or `PlaywrightCheck` from the `checkly/constructs` package.
+- Always ground generated code and CLI commands against the official documentation and examples in this file.
+- Use `runtimeId` for Browser Checks and MultiStep Checks. Runtimes are managed Checkly execution environments with fixed Checkly-provided dependencies such as Playwright, browser binaries, and runtime libraries.
+- Use `engine` only for Playwright Check Suites. `engine` selects the JavaScript engine version that runs the user's own Playwright project.
+
+## Using the Checkly CLI
+
+- Use `npx checkly` instead of installing the Checkly CLI globally.
+- NEVER make up commands that do not exist.
+- Use `npx checkly init` to set up Checkly in an existing project.
+
+## Project Structure
+
+- `checkly.config.ts` - Mandatory global project and CLI configuration. We recommend using TypeScript.
+- `*.check.ts|js` - TS / JS files that define the checks.
+- `*.spec.ts|js` - TS / JS files that contain Playwright code for Browser and MultiStep checks.
+- `src/__checks__` - Default directory where all your checks are stored. Use this directory if it already exists, otherwise create a new directory for your checks.
+- `package.json` - Standard npm project manifest.
+
+Here is an example directory tree of what that would look like:
+
+```
+.
+|-- checkly.config.ts
+|-- package.json
+`-- src
+    `-- __checks__
+|-- alert-channels.ts
+|-- api-check.check.ts
+`-- homepage.spec.ts
+```
+
+The `checkly.config.ts` at the root of your project defines a range of defaults for all your checks.
+
+**Reference:** https://www.checklyhq.com/docs/constructs/project/
+
+```typescript
+import { defineConfig } from 'checkly'
+import { Frequency } from 'checkly/constructs'
+
+export default defineConfig({
+  projectName: "Production Monitoring Suite",
+  logicalId: "prod-monitoring-2025",
+  repoUrl: "https://github.com/acme/monitoring",
+  checks: {
+    activated: true,
+    muted: false,
+    runtimeId: "2025.04",
+    frequency: Frequency.EVERY_10M,
+    locations: ["us-east-1", "eu-west-1", "ap-southeast-1"],
+    tags: ["production", "critical"],
+    checkMatch: "**/__checks__/*.check.ts",
+    ignoreDirectoriesMatch: ["node_modules/**", "dist/**"],
+    playwrightConfig: {
+      use: {
+        baseURL: "https://app.example.com",
+      },
+    },
+    browserChecks: {
+      frequency: Frequency.EVERY_30M,
+      testMatch: "**/__tests__/*.spec.ts",
+    },
+  },
+  cli: {
+    runLocation: "eu-west-1",
+    privateRunLocation: "private-dc1",
+    retries: 2,
+  },
+})
+```
+
+## Check and Monitor Constructs
+
+Parse and read further reference documentation when tasked with creating or managing any of the following Checkly constructs.
+
+If the Checkly CLI is installed (`npx checkly version`), use `npx checkly skills configure [CONSTRUCT]` to access up-to-date information:
+
+### `npx checkly skills configure agentic-checks`
+Agentic Check construct (`AgenticCheck`) for AI-powered prompt-driven monitoring with skill and env var allowlists
+
+### `npx checkly skills configure api-checks`
+Api Check construct (`ApiCheck`), assertions, and authentication setup scripts
+
+### `npx checkly skills configure browser-checks`
+Browser Check construct (`BrowserCheck`) with Playwright test files
+
+### `npx checkly skills configure playwright-checks`
+Playwright Check Suite construct (`PlaywrightCheck`) for multi-browser test suites
+
+### `npx checkly skills configure multistep-checks`
+Multistep Check construct (`MultiStepCheck`) for complex user flows
+
+### `npx checkly skills configure tcp-monitors`
+TCP Monitor construct (`TcpMonitor`) with assertions
+
+### `npx checkly skills configure url-monitors`
+URL Monitor construct (`UrlMonitor`) with assertions
+
+### `npx checkly skills configure dns-monitors`
+DNS Monitor construct (`DnsMonitor`) with assertions
+
+### `npx checkly skills configure icmp-monitors`
+ICMP Monitor construct (`IcmpMonitor`) with latency and packet loss assertions
+
+### `npx checkly skills configure heartbeat-monitors`
+Heartbeat Monitor construct (`HeartbeatMonitor`)
+
+### `npx checkly skills configure check-groups`
+CheckGroupV2 construct (`CheckGroupV2`) for organizing checks
+
+### `npx checkly skills configure alert-channels`
+Email (`EmailAlertChannel`), Phone (`PhoneCallAlertChannel`), Slack App (`SlackAppAlertChannel`), and other alert channels
+
+### `npx checkly skills configure supporting-constructs`
+Status pages (`StatusPage`), dashboards (`Dashboard`), maintenance windows (`MaintenanceWindow`), and private locations (`PrivateLocation`)
+
+### `npx checkly skills configure environment`
+Environment variables: built-in vars Checkly injects at runtime (`CHECK_ID`, `CHECK_NAME`, `REGION`, `CHECKLY_*`), user-defined variables and secrets at global/group/check scope, reference syntax (`process.env` vs `{{handlebars}}`), and the `checkly env` CLI for managing global vars.
+
+## Important: Public URL Requirement
+
+All checks (API, Browser, URL monitors) run on **Checkly's cloud infrastructure**, not on the user's local machine. Target URLs must be publicly accessible from the internet.
+
+- `localhost` and private network URLs will **not work** with `npx checkly test` or `npx checkly deploy`
+- For local development, suggest: tunneling tools (ngrok, cloudflare tunnel), preview/staging deployments, or CI preview URLs
+- Always confirm with the user that their target URLs are publicly reachable before creating checks
+
+## Check Locations and Plan Entitlements
+
+Not all features and locations are available on all plans. **Before configuring checks, run:**
+
+```bash
+npx checkly account plan --output json
+```
+
+This returns your exact entitlements and available locations. Use only locations where `available` is `true` in the `locations.all` array. If a feature is disabled, the response includes an `upgradeUrl` to share with the user.
+
+Run `npx checkly skills manage plan` for the full reference.
+
+## Testing and Debugging
+
+- Test checks using the `npx checkly test` command. Pass environment variables with the `-e` flag, results are recorded by default (use `--no-record` to skip), and use `--verbose` to see all errors.
+
+## Deploying
+
+- Deploy checks using the `npx checkly deploy` command. Use `--output` to see the created, updated, and deleted resources. Use `--verbose` to also include each resource's name and physical ID (UUID), which is useful for programmatically referencing deployed resources (e.g. `npx checkly checks get <id>`).

package/dist/ai-context/skills-command/references/initialize.md

@@ -0,0 +1,134 @@
+# Checkly Project Setup
+
+Follow these steps in order to set up a new Checkly monitoring project.
+
+## Step 0 — Pre-flight checks
+
+Before starting, verify:
+
+1. **Node.js** is installed (`node --version`). Checkly CLI requires Node.js 18 or later.
+2. **npm** is available (`npm --version`).
+3. The current working directory is the right location for the project (or create/navigate to it).
+
+If any pre-flight check fails, help the user fix it before proceeding.
+
+## Step 1 — Choose a setup method
+
+Ask the user which setup method they prefer:
+
+- **Option A: Initialize with CLI** — Run `npx checkly init` to set up Checkly in the project. The CLI handles skill installation, dependencies, configuration, and optionally creates demo checks. This is the fastest way to get started.
+- **Option B: AI-first** — Generate the project structure and checks from scratch using this skill. Best when the user already knows what they want to monitor and prefers a tailored setup.
+
+### Option A: Initialize with CLI
+
+Run the following command:
+
+```bash
+npx checkly init
+```
+
+The CLI will guide you through skill installation, configuration, and dependency setup. Once finished, setup is complete.
+
+### Option B: AI-first
+
+Continue with the following steps:
+
+#### Step 1: Install dependencies
+
+1. **Install the Checkly dependency**
+
+Check if `npx checkly --version` works. If not, run `npm install --save-dev checkly`.
+
+2. **Do you want to use TypeScript? (recommended)**
+   - If **yes** → install `jiti`:
+
+     ```bash
+     npm i --save-dev jiti
+     ```
+
+   - If **no** → there's nothing to do
+
+#### Step 2: Gather the project requirements
+
+Ask the user the following questions to determine the setup:
+
+1. **What do you want to monitor?** (multiple selections allowed)
+   - **Uptime monitoring** — Monitor URLs for availability and response times
+   - **API checks** — Validate API endpoints with custom assertions
+   - **Browser checks** — Run Playwright scripts to test user flows
+   - **Multistep API checks** — Chain multiple API requests into a single check
+   - **Playwright Check Suites** — Reuse your existing Playwright project for synthetic monitoring
+
+   Remember the selection for later steps when creating checks.
+
+2. **How do you want to get alerted?** (multiple selections allowed)
+
+Run `npx checkly skills configure alert-channels` to access up-to-date information on alert channel options and setup.
+
+3. **Where do you want to store your monitoring configuration?**
+   - **__checks__** — create all resources and `check.ts` files in a separate `__checks__` directory
+   - **next to the resource** — place the `check.ts` files next to page routes, api endpoints etc.
+
+
+#### Step 3 — Check your account plan
+
+Before writing checks, verify what your account can do:
+
+```bash
+npx checkly account plan --output json
+```
+
+This shows your entitlements, limits, and available locations. Use this data when creating the config:
+
+- **Only use locations** from `locations.all` where `available` is `true`. Using unavailable locations will cause deploy failures.
+- **Check feature availability** before configuring constructs like private locations, advanced alert channels, or higher-frequency schedules.
+- **Respect metered limits** — the `quantity` field shows maximums for each metered feature.
+
+If a feature the user wants is disabled, the response includes an `upgradeUrl` — share it so they can upgrade their plan.
+
+Run `npx checkly skills manage plan` for the full reference.
+
+#### Step 4 — Create the config file
+
+Run the following command to retrieve the configure skill reference:
+
+```bash
+npx checkly skills configure
+```
+
+Use the output to create a `checkly.config.ts` (or `checkly.config.js` if the user chose JavaScript) in the project root.
+
+Adjust the `checkMatch` property according to previous selection. Use only locations verified as available in the previous step.
+
+Present the generated configuration to the user and ask if it looks correct. Allow the user to make changes.
+
+Congratulate the user on completing the config. Now it's time to test the configuration and turn everything into monitoring!
+
+#### Step 5: Log in to Checkly CLI
+
+To use the Checkly CLI the user needs to be logged in. Run the following command:
+
+```bash
+npx checkly whoami
+```
+
+If the user is logged in, verify the information and if it's the correct account.
+
+If the user is NOT logged in, present two options (lead with env vars — they work for agents, CI, and interactive use):
+
+- **Option A: Environment variables (recommended)** — The user sets `CHECKLY_API_KEY` and `CHECKLY_ACCOUNT_ID` as environment variables. They can create an API key at https://app.checklyhq.com/accounts/settings/user/api-keys. This is the recommended approach as it works in all contexts (agentic, CI/CD, and interactive). Once both variables are set, re-run `npx checkly whoami` to verify.
+- **Option B: Interactive login** — The user runs `npx checkly login` themselves. This command opens a browser for OAuth authentication and **cannot be completed by an AI agent**. Tell the user to run the command, complete the browser flow, and let you know when they're done so you can re-run `npx checkly whoami` to verify.
+
+#### Step 6: Summarize and test the new monitoring configuration
+
+Read the generated `checkly.config.ts` (or `checkly.config.js`) and summarize the configured checks, locations, and frequencies.
+
+Run the following command to test the new monitoring setup:
+
+```bash
+npx checkly test
+```
+
+If the command passed, congratulate the user and ask them what they want to do next!
+
+Share more Checkly CLI options and ask if they want to deploy their new monitoring setup using `npx checkly deploy`.