fix(ci): put the command word in the Claude trigger phrase so /focus reaches the model

[theCodeDrift]

@claude /focus on #437 failed its verify step (run 36932898300). Claude never ran: the action step reported success after 126 ms with empty modelUsage. For comparison, a working /review run took 460 s.

Cause

track_progress: true forces claude-code-action into tag mode. Tag mode takes everything after trigger_phrase in the comment and sends it to the CLI as a separate user-message block, and the CLI runs that block as a slash command when it starts with /. Under the default @claude, the forwarded block was /focus, so the session ended without a model call.

/review only worked because /review is a Claude Code built-in. Each review therefore also ran the built-in review command on top of our prompt.

Fix

• trigger_phrase: "@claude /review" and "@claude /focus". Only the text after the command word is forwarded, as plain text. That text is a maintainer's guidance, all, or 5.
• The review header (and the matching bullet in the focus header) now says how guidance reaches the model, instead of claiming the body is never forwarded.
• The 👀 note now names the right source. The reaction comes from the Claude GitHub App on any @claude mention, before the workflow starts, not from the action.

Verifying

issue_comment workflows load from main, so this can only be tested after merge, by commenting @claude /focus on an open PR.

[theCodeDrift]

@claude /review

[claude]

Claude finished @theCodeDrift's task in 4m 5s —— View job

---

Review mode

Review mode: incremental — read 0 prior review thread(s) before reviewing. .prior-review.json has empty reviewThreads and reviews arrays; its single comments entry is this invocation's own trigger comment (@claude /review), not a prior finding. Treating this as a first, full review of the diff.

Summary

This PR's only functional change is adding one line to each workflow:

• .github/workflows/claude-code-focus-on-demand.yml: trigger_phrase: "@claude /focus"
• .github/workflows/claude-code-review-on-demand.yml: trigger_phrase: "@claude /review"

Everything else is comment/documentation rewording to match the corrected behavior. I traced the mechanism described in the PR body against the diff and the surrounding (unchanged) code:

• The if: gates in both workflows already require the literal substrings @claude /review / @claude /focus (unchanged by this PR), so every comment that reaches the action already contains the command word. Setting trigger_phrase to match means tag mode now forwards only the text after the command word as a plain-text user message, instead of forwarding /review//focus themselves as a leading slash command. That lines up with the root cause described in the PR (CLI treats a forwarded block starting with / as a slash command, and /focus isn't one, so the session ended with no model call).
• The digit-extraction regex in claude-code-focus-on-demand.yml's "Prepare focus context" step and the case pattern in claude-code-review-on-demand.yml's "Prepare review context" step are untouched and still operate on $COMMENT_BODY via env:, not on the action's forwarded text, so there's no double-interpretation conflict between the two mechanisms.
• I grepped the rest of .github/workflows and the only two files mentioning @claude/trigger_phrase are these two, so there's no other workflow that could double-fire or rely on the old implicit default trigger_phrase: "@claude".
• I checked for stale leftover documentation elsewhere (the old "body is TESTED, never forwarded" claim, "no free text reaches the prompt", etc.) and found no remaining references outside this diff — both headers and both inline comments were updated consistently, and the new copy accurately reflects that the body was already being forwarded before this fix (just with the command word still attached), not a new hole introduced by this change.
• Indentation/placement of the new trigger_phrase: keys under each step's with: block is correct and at the same level as sibling keys (track_progress, include_fix_links), so this doesn't introduce a YAML structural error.

I didn't find a correctness, security, or clarity issue in the diff. The one caveat — that issue_comment-triggered workflows always run from main, so this fix can't be exercised until after merge — is already called out by the author in the PR body, so I'm not raising it as a separate finding.

No inline comments posted; nothing new to flag.