docs: refresh Checkly CLI 8.19.0 skills

VERSION

@@ -1,8 +1,12 @@
-1.0.11
+1.0.12
 
 Release/version change metadata for this skill set lives here, not in individual skill files.
 
 Historical notes consolidated from skill docs:
+- checkly-cli v8.19.0
+  - Reviewed upstream release `8.19.0`, compare `8.18.0...8.19.0`, PR `checkly/checkly-cli#1425`, construct source/tests, and live `checkly@8.19.0` version/help output on 2026-08-01.
+  - Documented account-aware response-time validation: standard client-side ceilings remain in force unless the authenticated account advertises extended limits, in which case the CLI defers the upper bound to the API while preserving the degraded-versus-maximum consistency check.
+  - Added the standard response-time ceilings for API, TCP, DNS, URL, gRPC, SSL, and traceroute constructs and distinguished top-level monitor/check thresholds from request assertions.
 - checkly-cli v8.18.0
   - Reviewed upstream release `8.18.0`, compare `8.17.1...8.18.0`, command/construct source, and live `checkly@8.18.0` version/help output on 2026-07-27.
   - Added the new `checks run` workflow for triggering deployed checks by ID or tag, including selector semantics, output/detach/cache/timeout behavior, exit-status handling, and live-run safety guidance.

checkly-checks/SKILL.md

@@ -324,6 +324,12 @@ new ApiCheck('scheduled-check', {
 })
 ```
 
+### Response-time validation
+
+`degradedResponseTime` and `maxResponseTime` are top-level `ApiCheck` properties. They control check-state thresholds and are separate from `AssertionBuilder.responseTime()` request assertions.
+
+The standard client-side ceiling for both API-check properties is 30 seconds. When the authenticated account advertises extended response-time limits, the CLI skips that fixed ceiling and lets the Checkly API enforce the account-specific limit. Do not assume that entitlement is present: run `npx checkly test` with the target account and treat its validation or API response as authoritative. Older or self-hosted APIs that do not expose account feature flags keep the standard ceiling. In every case, `degradedResponseTime` must be less than or equal to `maxResponseTime`.
+
 ### Tags and organization
 
 ```typescript

checkly-monitors/SKILL.md

@@ -210,6 +210,23 @@ new TracerouteMonitor('network-path', {
 - `responseTime()` accepts `avg` (default), `min`, `max`, or `stdDev`.
 - `hopCount()` and `packetLoss()` do not take a property.
 
+## Response-time validation
+
+`degradedResponseTime` and `maxResponseTime` are top-level monitor properties. They control degraded/failing check states and are separate from response-time assertions inside `request.assertions`.
+
+The CLI applies these standard client-side ceilings when the authenticated account does not advertise extended response-time limits:
+
+| Monitor | Standard ceiling |
+|---------|------------------|
+| TCP | 5 seconds |
+| DNS | 5 seconds |
+| URL | 30 seconds |
+| gRPC | 180 seconds |
+| SSL | 30 seconds |
+| Traceroute | 30 seconds |
+
+For accounts with extended limits, the CLI skips the fixed ceiling and lets the Checkly API enforce the account-specific limit. Do not assume the entitlement is present: validate with `npx checkly test` against the target account. Older or self-hosted APIs that do not expose account feature flags keep the standard ceilings. In every case, `degradedResponseTime` must be less than or equal to `maxResponseTime`.
+
 ## Validate and deploy
 
 ```bash