feat(cli): add checkly status-pages list + get commands [TIM-24, TIM-25]

[thebiglabasky]

Affected Components

• CLI
• Create CLI
• Test
• Docs
• Examples
• Other

Notes for the Reviewer

Adds checkly status-pages list and checkly status-pages list the first commands under the new status-pages topic.

What it does:

• Lists all status pages in an account via GET /v1/status-pages
• Default output: flat subtable with one row per service, all fields (name, url, card, service, id) repeated on every row — agent-friendly, every row is self-contained
• --compact: one row per status page with card counts
• --output json|md: JSON returns full API response, markdown renders a table
• --cursor / --limit: cursor-based pagination (matching the backend's newer pagination pattern, unlike the offset-based pattern used by checks)

Key design decisions:

• Flat subtable over tree view: agents can grep/parse any row independently without tracking state from previous rows
• Cursor-based pagination: the status-pages API uses cursors (not offset/page like checks), so we match the API rather than shimming
• No --page flag: cursor pagination doesn't support random access

New files:

• src/rest/status-pages.ts — REST module wrapping /v1/status-pages
• src/formatters/status-pages.ts — expanded (per-service) and compact (per-page) table formatters
• src/commands/status-pages/list.ts — the command itself
• src/formatters/__tests__/status-pages.spec.ts — 15 tests covering both output modes + pagination helpers

Resolves TIM-24, TIM-25

[MichaelHogers]

should we group these "data commands" separately

we have CORE, ADDITIONAL COMMANDS

maybe we group them separately

XYZ COMMANDS + possible a [PREVIEW/BETA] in the title to make clear these might break

this would help for agents as well, as in, CORE commands create things XYZ commands get things and allow to inspect data...

[MichaelHogers]

should make it less likely that the agent does something unintended with the checkly cli

[thebiglabasky]

True, let me look into changing that now, it's easy enough

[thebiglabasky]

Actually didn't go with a change, and believe that'd be probably better to do it once we have a bunch more so we don't churn this too often, and clean it up once.
wdyt?

[MichaelHogers]

agreed 👍

[MichaelHogers]

Testing this CLI version with CC:

Tested locally against prod — both commands work well. Terminal and markdown outputs look clean.

1. Repeated IDs in list: The flat card/service rows mean the same status page ID appears many times (e.g. 13 rows for one page with 13 services). An agent needs to deduplicate to understand "3 status pages" vs 20 rows. Not sure if there's a better way to structure this.

[MichaelHogers]

looks all good and low risk, some minor comments

[thebiglabasky]

Testing this CLI version with CC:

Tested locally against prod — both commands work well. Terminal and markdown outputs look clean.

1. Repeated IDs in list: The flat card/service rows mean the same status page ID appears many times (e.g. 13 rows for one page with 13 services). An agent needs to deduplicate to understand "3 status pages" vs 20 rows. Not sure if there's a better way to structure this.

I had a similar question and so we have a --compact which won't repeat lines. I actually asked CC to tell me what format would work best for an agent and he told me to repeat so it would easily awk into it, which I figured was smart. Open to another way though!

[MichaelHogers]

Testing this CLI version with CC:
Tested locally against prod — both commands work well. Terminal and markdown outputs look clean.

1. Repeated IDs in list: The flat card/service rows mean the same status page ID appears many times (e.g. 13 rows for one page with 13 services). An agent needs to deduplicate to understand "3 status pages" vs 20 rows. Not sure if there's a better way to structure this.

I had a similar question and so we have a --compact which won't repeat lines. I actually asked CC to tell me what format would work best for an agent and he told me to repeat so it would easily awk into it, which I figured was smart. Open to another way though!

👍 👍