docs(cli): allow for a pinned target in the confirmCommand contract

The confirmation docs promised that the `confirmCommand` is the command you
ran plus `--force`, and that it "echoes back only the flags that were
actually passed". That is true of every command on main today: the two
callers that reshape their preview flags (`members delete`, `members
update`) only drop empty ones, they never add.

It stops being true the moment #1402 lands. `import commit` and `import
cancel` resolve their plan and pin it into the preview, so a bare
`checkly import commit` confirms as:

  checkly import commit --plan-id="abc123" --force

The pin is the right call — it stops the approved run from re-resolving to
a plan the user was never shown — but it makes an absolute claim in this
reference false, and #1402 merges first. Widen the contract to allow a
resolved target, and keep "treat every flag you see there as deliberate",
which was always the operative rule and covers the pinned flag too.

Worded to hold under either merge order: it describes the mechanism without
pointing at the import section that arrives with #1402.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: martzoukos

packages/cli/src/ai-context/references/communicate.md

@@ -20,12 +20,12 @@ Write commands (`incidents create`, `incidents update`, `incidents resolve`, `de
 **Rules for agents:**
 
 1. When exit code is 2 and output contains `"status": "confirmation_required"`, **always present the `changes` array to the user** and ask for confirmation.
-2. **Run the `confirmCommand` verbatim, and only after the user explicitly approves.** It is the command you just ran, plus `--force` to skip the second prompt. Don't append `--force` to anything yourself, and don't edit the `confirmCommand` — changing its flags changes what you were authorized to do.
+2. **Run the `confirmCommand` verbatim, and only after the user explicitly approves.** It is normally the command you just ran, plus `--force` to skip the second prompt. Don't append `--force` to anything yourself, and don't edit the `confirmCommand` — changing its flags changes what you were authorized to do.
 3. This applies to **every** write command, not just the first one. Incident updates and resolutions also require confirmation.
 4. Use `--dry-run` to preview what a command will do without executing or prompting.
 5. Read-only commands (`incidents list`, `status-pages list`) execute immediately without confirmation.
 
-The `confirmCommand` echoes back only the flags that were actually passed — flags left at their default are omitted, so a bare `npx checkly deploy` confirms as `checkly deploy --force`. Treat every flag you see there as deliberate.
+The `confirmCommand` omits flags left at their default, so a bare `npx checkly deploy` confirms as `checkly deploy --force` rather than echoing back every boolean the parser filled in. It can also carry a flag you did not pass: a command that resolves a target for you pins that target into the `confirmCommand`, so the approved run cannot drift onto a different one. Treat every flag you see there as deliberate.
 
 ## Available Commands
 

packages/cli/src/ai-context/skill.md

@@ -36,7 +36,7 @@ Run `npx checkly skills manage` for the full reference.
 
 Write commands (e.g. `incidents create`, `deploy`, `destroy`) return exit code 2 with a `confirmation_required` JSON envelope instead of executing. **Always present the `changes` to the user and wait for approval before running the `confirmCommand`.** This applies to every write command individually — updates and resolutions need confirmation too, not just the initial create.
 
-The `confirmCommand` is the approved command, ready to run verbatim: it repeats the flags you passed and already ends in `--force`. Run it as-is once the user approves — don't add `--force` to a command yourself, and don't add flags the user didn't ask for.
+The `confirmCommand` is the approved command, ready to run verbatim: it repeats the flags you passed, already ends in `--force`, and may pin a target the CLI resolved for you. Run it as-is once the user approves — don't add `--force` to a command yourself, and don't add flags the user didn't ask for.
 
 Run `npx checkly skills communicate` for the full protocol details, or `npx checkly skills configure` for what `deploy` confirms.
 

skills/checkly/SKILL.md

@@ -36,7 +36,7 @@ Run `npx checkly skills manage` for the full reference.
 
 Write commands (e.g. `incidents create`, `deploy`, `destroy`) return exit code 2 with a `confirmation_required` JSON envelope instead of executing. **Always present the `changes` to the user and wait for approval before running the `confirmCommand`.** This applies to every write command individually — updates and resolutions need confirmation too, not just the initial create.
 
-The `confirmCommand` is the approved command, ready to run verbatim: it repeats the flags you passed and already ends in `--force`. Run it as-is once the user approves — don't add `--force` to a command yourself, and don't add flags the user didn't ask for.
+The `confirmCommand` is the approved command, ready to run verbatim: it repeats the flags you passed, already ends in `--force`, and may pin a target the CLI resolved for you. Run it as-is once the user approves — don't add `--force` to a command yourself, and don't add flags the user didn't ask for.
 
 Run `npx checkly skills communicate` for the full protocol details, or `npx checkly skills configure` for what `deploy` confirms.