docs(handoff): second copy polish pass on handoff pages

A senior-copywriter follow-up on commit b45a4e8. Focuses on terminology
consistency, list parallelism, active voice, and a few style-guide nits
caught on the second read.

index.mdx
- Frontmatter description: "Move an agent conversation between your
  terminal and the cloud" -> "Move agent work between a local Warp
  session and the cloud" so the description matches the body intro
  (which Rachael's review moved to "local Warp session" terminology).
- "Directions of handoff" Local-to-cloud bullet: "more compute,
  longer-running work, or to fan out variants in parallel" ->
  "more compute, longer-running work, or parallel variants of the
  same task". Now all three list items are parallel noun phrases.
- "Workspace state" bullet: "The cloud-to-local direction does not
  currently apply" -> "doesn't currently apply" (contractions are
  encouraged in the style guide for an approachable tone).

local-to-cloud.mdx
- "Use this handoff direction when:" list: first bullet started with
  "The task is going to run for a long time..." while the other three
  start with "You want...". Rewrote it to "You have a long-running
  task and don't want to keep your laptop awake." so all four bullets
  open the same way.
- Step 1: "trigger handoff with the `&` shortcut or the `/handoff`
  slash command" -> "press `&` or run the `/handoff` slash command".
  Direct verbs match the style guide pattern for keyboard / slash
  commands.
- Step 2: "Pick the environment whose..." -> "Pick the one whose..."
  (avoids repeating "environment" right after the bold header).
  "create one first and add" -> "create one and add" ("first" was
  doing no work).
- Post-steps prose: "After submission, the cloud agent applies your
  workspace snapshot" -> "After you submit, the cloud agent...".
  Active voice; readers don't talk about "submission."
- Troubleshooting (uncommitted changes): "Without it, the
  conversation can't be forked" -> "Otherwise, the conversation can't
  be forked". "Without it" had a fuzzy antecedent; "Otherwise" reads
  cleanly off the preceding sentence.

cloud-to-cloud.mdx
- "Use this handoff direction when:" list: first bullet "A cloud
  agent finished and you want to send a follow-up after the session
  has ended." -> "You want to send a follow-up to a cloud agent
  after its session has ended." Now parallel with the second bullet
  ("You want to continue an ambient agent run...").
- Cleaned up three lingering uses of "execution" that the earlier
  internals scrub missed. All three were re-introduced when applying
  Safia's audit-fix feedback in e4bdd4b. Replaced with "session":
    - "the new execution runs on the same Git branch as the prior
      session" -> "the new session continues on the same Git branch"
      (avoids both the internal term and the "new ... prior" cycle).
    - ":::caution Cloud-to-cloud handoff relies on a snapshot from
      the prior execution" -> "...the prior session".
    - "Click into the run to see the full transcript: each
      execution appears in order, and you can scan the transcript to
      see where one execution ended and the next began. Per-execution
      timestamps aren't currently exposed in the API..." -> all three
      "execution"s -> "session" / "Per-session".
- "What carries over" trailing sentence: "...proceeds with what it
  could before continuing to your follow-up." -> "...rather than
  starting over silently." Now parallel with the same sentence on
  the other two handoff pages.
- "Sending a follow-up" lead-in: dropped the orphan third sentence
  ("Send-follow-up support is available in the Warp app.") and
  folded it into the first: "you send a follow-up from the Warp app,
  and the run continues."
- Step 2: "Type the next message into the conversation's input" ->
  "Enter the next message in the conversation's input" ("Enter" is
  the style guide's verb for text fields).
- Troubleshooting (old runs): "Start a new cloud agent run with the
  prompt you want and reference the prior run in the prompt if
  needed." -> "Start a new cloud agent run with the prompt you want,
  referencing the prior run if needed." (drops the "prompt"
  repetition).

Final grep over the handoff folder for "execution", "harness",
"spiraled", "right move", "Cloud Agents", "Warp terminal" -> zero hits.

Validation
- python3 .agents/skills/style_lint/style_lint.py --changed -> 0 issues.
- python3 .agents/skills/check_for_broken_links/check_links.py --internal-only
  -> 0 broken links (2,439 internal links across 321 files).

Co-Authored-By: Oz <oz-agent@warp.dev>

Author: hongyi-chen

src/content/docs/agent-platform/cloud-agents/handoff/cloud-to-cloud.mdx

@@ -11,18 +11,18 @@ Hand off a cloud agent run to a fresh cloud session when the original session ha
 
 Use this handoff direction when:
 
-* A cloud agent finished and you want to send a follow-up after the session has ended.
+* You want to send a follow-up to a cloud agent after its session has ended.
 * You want to continue an ambient agent run — an agent that runs in the background, such as a scheduled or integration-triggered run — while preserving it as a single unit of work in the [management view](/agent-platform/cloud-agents/managing-cloud-agents/).
 
 ## What carries over
 
 When you send a follow-up to a run whose session has ended, the run continues with:
 
 * **The same conversation** - The follow-up is appended to the same conversation. From your perspective, the run is one continuous conversation across sessions.
-* **The prior workspace state** - The prior session's repository changes (tracked and untracked) are restored before the agent answers your follow-up. For git-managed sessions, the new execution runs on the same Git branch as the prior session.
+* **The prior workspace state** - The prior session's repository changes (tracked and untracked) are restored before the agent answers your follow-up. For git-managed sessions, the new session continues on the same Git branch.
 * **Stable run identity** - The run's ID, task, creator, environment, schedule trigger, and integration source are preserved. Compute usage is recorded per session but rolls up to the same run.
 
-If applying any change fails, the agent reports what couldn't be applied and proceeds with what it could before continuing to your follow-up.
+If applying any change fails, the agent reports what couldn't be applied and proceeds with what it could rather than starting over silently.
 
 ## Prerequisites
 
@@ -31,15 +31,15 @@ If applying any change fails, the agent reports what couldn't be applied and pro
 * **Access to the run** - You need permission to submit follow-ups for the run. For team runs, this is typically any team member. Cloud runs that originated from a local-to-cloud handoff can be continued only by the user who created them, not by other team members.
 
 :::caution
-Cloud-to-cloud handoff relies on a snapshot from the prior execution. Older cloud runs that don't have a snapshot on file can't be handed off; start a new run instead.
+Cloud-to-cloud handoff relies on a snapshot from the prior session. Older cloud runs that don't have a snapshot on file can't be handed off; start a new run instead.
 :::
 
 ## Sending a follow-up
 
-You don't take a separate "hand off" action — you send a follow-up, and the run continues. The handoff happens automatically when the original session has ended. Send-follow-up support is available in the Warp app.
+You don't take a separate "hand off" action — you send a follow-up from the Warp app, and the run continues. The handoff happens automatically when the original session has ended.
 
 1. **Open the ended cloud run.** Find it on the [Runs page](https://oz.warp.dev/runs) in the Oz web app or in the conversation panel.
-2. **Send your follow-up.** Type the next message into the conversation's input and submit it.
+2. **Send your follow-up.** Enter the next message in the conversation's input and submit it.
 
 The run picks up where it left off, with workspace state restored.
 
@@ -49,15 +49,15 @@ Cloud-to-cloud handoff also works for supported third-party agent runtimes, but
 
 ## Inspecting a run that's been handed off
 
-The [management view](/agent-platform/cloud-agents/managing-cloud-agents/) shows one row per run, even when the run spans multiple sessions. Click into the run to see the full transcript: each execution appears in order, and you can scan the transcript to see where one execution ended and the next began. Per-execution timestamps aren't currently exposed in the API; the transcript is the source of truth.
+The [management view](/agent-platform/cloud-agents/managing-cloud-agents/) shows one row per run, even when the run spans multiple sessions. Click into the run to see the full transcript: each session appears in order, and you can scan the transcript to see where one session ended and the next began. Per-session timestamps aren't currently exposed in the API; the transcript is the source of truth.
 
 ## Troubleshooting
 
 **The run continued but no workspace state was restored.**
 The prior session didn't capture a snapshot. This is rare but possible — snapshot capture is best-effort. The run still continues with the same conversation, so the agent has the full transcript context even without the workspace state.
 
 **The run is in a terminal state with no conversation and follow-ups are rejected.**
-Very old runs predate the agent conversation model and can't be continued via handoff. Start a new cloud agent run with the prompt you want and reference the prior run in the prompt if needed.
+Very old runs predate the agent conversation model and can't be continued via handoff. Start a new cloud agent run with the prompt you want, referencing the prior run if needed.
 
 ## Related pages
 

src/content/docs/agent-platform/cloud-agents/handoff/index.mdx

@@ -1,9 +1,9 @@
 ---
 title: Handoff between local and cloud agents
 description: >-
-  Move an agent conversation between your terminal and the cloud, or continue
-  a finished cloud run with workspace state restored, without re-explaining
-  the task.
+  Move agent work between a local Warp session and the cloud, or continue a
+  finished cloud run with workspace state restored, without re-explaining the
+  task.
 sidebar:
   label: "Handoff overview"
 ---
@@ -14,7 +14,7 @@ Handoff lets you move a unit of agent work between a local Warp session and the
 
 Handoff supports three directions:
 
-* **Local to cloud** - Promote a local Warp Agent conversation to a cloud agent run when you need more compute, longer-running work, or to fan out variants in parallel. The cloud agent starts from your conversation history and a snapshot of your uncommitted workspace changes. See [Handoff from local to cloud](/agent-platform/cloud-agents/handoff/local-to-cloud/).
+* **Local to cloud** - Promote a local Warp Agent conversation to a cloud agent run when you need more compute, longer-running work, or parallel variants of the same task. The cloud agent starts from your conversation history and a snapshot of your uncommitted workspace changes. See [Handoff from local to cloud](/agent-platform/cloud-agents/handoff/local-to-cloud/).
 * **Cloud to cloud** - Send a follow-up to a cloud run after its session has ended. The run continues in the same conversation, with the prior session's workspace state restored. See [Handoff from cloud to cloud](/agent-platform/cloud-agents/handoff/cloud-to-cloud/).
 * **Cloud to local** - Fork a cloud conversation into a local Warp session with **Continue locally** or `/continue-locally`. See [Viewing cloud agent runs](/agent-platform/cloud-agents/viewing-cloud-agent-runs/#5-fork-the-session-to-your-local-warp).
 
@@ -30,7 +30,7 @@ Handoff coverage depends on which agent is running the conversation:
 Handoff preserves enough state that the receiving agent can resume the work, not just read about it.
 
 * **Conversation history** - The receiving agent sees the full transcript of the prior session. Local-to-cloud forks the conversation so the source isn't modified; cloud-to-cloud continues in the same conversation.
-* **Workspace state** - Local-to-cloud and cloud-to-cloud capture the prior session's repository changes (tracked and untracked) and apply them in the receiving run before the agent answers the next prompt. The cloud-to-local direction does not currently apply workspace patches to your local checkout; review the cloud agent's branch or pull request artifact to inspect those changes.
+* **Workspace state** - Local-to-cloud and cloud-to-cloud capture the prior session's repository changes (tracked and untracked) and apply them in the receiving run before the agent answers the next prompt. The cloud-to-local direction doesn't currently apply workspace patches to your local checkout; review the cloud agent's branch or pull request artifact to inspect those changes.
 * **Conversation attachments** - Files attached during the prior session remain available to the receiving agent.
 
 Handoff is best-effort. When the receiving agent can apply the prior session's changes cleanly, it picks up where the prior agent left off. When it can't, the agent reports what failed and proceeds with what it could rather than starting over silently.

src/content/docs/agent-platform/cloud-agents/handoff/local-to-cloud.mdx

@@ -12,7 +12,7 @@ Hand off a local Warp conversation to a cloud agent run when the work outgrows y
 
 Use this handoff direction when:
 
-* The task is going to run for a long time and you don't want to keep your laptop awake.
+* You have a long-running task and don't want to keep your laptop awake.
 * You want to fan out variants of the same task across multiple cloud agents in parallel.
 * You want to walk away and check on the agent from a different device.
 * You want the agent to keep working while you start a new conversation locally.
@@ -36,15 +36,15 @@ If applying any change fails in the cloud run, the cloud agent reports what coul
 
 ## Handing off a conversation to the cloud
 
-1. **Open the handoff flow from your active conversation.** With the local conversation focused, trigger handoff with the `&` shortcut or the `/handoff` slash command. Either entry point opens the handoff flow scoped to the current conversation. The `/cloud-agent` slash command always starts a fresh cloud conversation and isn't an entry point for handoff.
-2. **Choose the environment for the cloud run.** Pick the environment whose repositories match the directories your local conversation has been editing. If you don't have a matching environment yet, create one first and add the repos you've been working in.
+1. **Open the handoff flow from your active conversation.** With the local conversation focused, press `&` or run the `/handoff` slash command. Either entry point opens the handoff flow scoped to the current conversation. The `/cloud-agent` slash command always starts a fresh cloud conversation and isn't an entry point for handoff.
+2. **Choose the environment for the cloud run.** Pick the one whose repositories match the directories your local conversation has been editing. If you don't have a matching environment yet, create one and add the repos you've been working in.
 3. **Add a follow-up prompt and submit.** Enter the next message you want the cloud agent to act on.
 
 :::note
 The cloud agent runs with the same model your local conversation was using. Changing the model during handoff isn't supported.
 :::
 
-After submission, the cloud agent applies your workspace snapshot and addresses your follow-up. The local conversation stays untouched — you can keep working in it locally or close it.
+After you submit, the cloud agent applies your workspace snapshot and addresses your follow-up. The local conversation stays untouched — you can keep working in it locally or close it.
 
 To check on the new run, open it from the [Runs page](https://oz.warp.dev/runs) in the Oz web app or the conversation panel.
 
@@ -54,7 +54,7 @@ To check on the new run, open it from the [Runs page](https://oz.warp.dev/runs)
 The most common cause is a repository mismatch between your local checkout and the environment. The workspace snapshot is generated against your local repo's current state; the environment must be on a compatible branch and commit for the changes to apply cleanly. Switch the environment's repo to the branch you were on locally and retry the handoff.
 
 **The cloud agent doesn't see my uncommitted changes.**
-Cloud conversation storage must be enabled for handoff to work. In the Warp app, open **Settings** > **Privacy** and confirm **Store AI conversations in the cloud** is on. Without it, the conversation can't be forked and the run falls back to starting fresh.
+Cloud conversation storage must be enabled for handoff to work. In the Warp app, open **Settings** > **Privacy** and confirm **Store AI conversations in the cloud** is on. Otherwise, the conversation can't be forked and the run falls back to starting fresh.
 
 **The conversation doesn't appear in the cloud run.**
 The source conversation may not have finished syncing to the cloud when you triggered the handoff. Wait a moment and retry. If the problem persists, check the conversation panel to confirm the conversation has a cloud-synced indicator.