docs(cli): drop the pinned-target claim until the behavior lands

The confirmation protocol told agents that a command resolving a target
pins it into the confirmCommand. No command on main does that: every
call site passes raw user input, and members delete drops its email/id
disambiguation before confirming. The pinning behavior arrives with
import commit/cancel in #1402, which documents it there.

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

Author: martzoukos

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

@@ -25,7 +25,7 @@ Write commands (`incidents create`, `incidents update`, `incidents resolve`, `de
 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` 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.
+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. 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, 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.
+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.
 
 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, 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.
+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.
 
 Run `npx checkly skills communicate` for the full protocol details, or `npx checkly skills configure` for what `deploy` confirms.