Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@claude-ops/bin/ops-slack-workspaces`:
- Around line 22-26: The current human-output branch that sets ANSI colors (the
if using [[ -t 1 && $JSON_MODE -eq 0 ]]) must detect mobile/SSH sessions and
switch to a compact plain-text mode; add a mobile detection boolean (check
$SSH_CONNECTION, $SSH_CLIENT, $SSH_TTY, $OPS_MOBILE=1, or COLUMNS<80) and when
true set ANSI vars (GREEN/RED/YELLOW/RESET) to empty and set a new flag (e.g.,
COMPACT_MOBILE=1); then update the downstream rendering code referenced around
the human-output path and the sections noted (the output logic around lines
112-167) to, when COMPACT_MOBILE=1, emit short line-based plain text (no
banners, tables, emoji/glyph columns or ANSI) instead of the wide table/banner
formatting while preserving the JSON branch ($JSON_MODE) unchanged.
- Around line 71-72: The indirect expansion using "${!token_env:-}" can trigger
a "bad substitution" if token_env contains characters invalid for shell
identifiers; before performing indirect expansion (where token_env is read to
set ws_token), validate token_env against a POSIX variable-name pattern (e.g.,
start with letter/underscore, followed by letters/digits/underscores). If
validation fails, treat it as a configuration error: log a clear message and
skip expansion or exit with non-zero status; otherwise perform the indirect
expansion. Apply this validation for the token_env use that sets ws_token and
the other identical occurrence later in the file.

In `@claude-ops/bin/ops-unread`:
- Around line 80-83: The example preferences.json uses real-looking workspace
names in the "slack_workspaces" array (the entries with "name": "lifecycle" and
"name": "stagery" and their corresponding "token_env" values); update those
example objects to use neutral placeholders (e.g., "name": "workspace_name" or
"name": "<WORKSPACE>", and token_env values like "SLACK_BOT_TOKEN_<WORKSPACE>"
or "<YOUR_TOKEN_ENV>") so no real org/project identifiers are committed, keeping
the JSON keys "slack_workspaces", "name", "token_env", and "kind" intact.
- Around line 107-110: The script currently uses indirect expansion
"${!token_env}" (resolving into ws_token) without validating token_env, which
causes "invalid variable name" under set -euo pipefail for values like
"SLACK-BOT-TOKEN"; before dereferencing token_env validate it matches a
POSIX/Bash identifier (e.g. regex ^[a-zA-Z_][a-zA-Z0-9_]*$), and if it fails do
not attempt "${!token_env}" — instead emit an error record (write an error
message to stderr / log) and leave ws_token empty or handle the error path;
update the resolution logic surrounding token_env and ws_token to perform this
check before indirect expansion.

In `@claude-ops/skills/ops-comms/SKILL.md`:
- Around line 172-175: The skill currently filters workspaces by an `available`
flag on `slack_workspaces[]`, but that array only contains persisted metadata
and not availability; instead read the derived availability from
`channels.slack.workspaces[]` (as built by claude-ops/bin/ops-unread around
lines 76–137) or resolve each workspace's `token_env` to check presence before
filtering; update the workspace iteration to use `channels.slack.workspaces[]`
(or a resolved-token check) when deciding to call
`mcp__claude_ai_Slack__slack_search_public_and_private` (or do a direct curl for
non-bound workspaces), and keep the existing fallback logic for 0 workspaces /
legacy mode using `SLACK_MCP_ENABLED`.

In `@claude-ops/skills/ops-go/SKILL.md`:
- Around line 206-213: The workflow documents use the MCP tool
mcp__claude_ai_Slack__slack_search_public_and_private but the skill's
allowed-tools list doesn't expose any Slack tools, so /ops:go cannot run the
multi-workspace scan; update the SKILL.md allowed-tools section to include the
Slack MCP entries (e.g., mcp__claude_ai_Slack__slack_search_public_and_private
and any related mcp__claude_ai_Slack__* methods used by the flow) or explicitly
delegate Slack scanning to an existing skill that already lists those Slack
tools—ensure the allowed-tools list and any tool capability descriptions
reference the exact MCP symbols named in the workflow so the runtime can invoke
them.

In `@claude-ops/skills/ops-inbox/SKILL.md`:
- Around line 259-263: The Slack inbox section in SKILL.md references state and
MCP tools this skill doesn't have; change the flow to consume the pre-gathered
channels.slack object produced by bin/ops-unread (use channels.slack as the
source of truth instead of slack_workspaces[]/available/multi_workspace state)
and either add the required Slack MCP tools (mcp__claude_ai_Slack__* entries) to
this skill's allowed-tools or route Slack handling to the existing skill that
already exposes those tools; update the steps that mention
mcp__claude_ai_Slack__*, slack_workspaces[], and SLACK_MCP_ENABLED to instead
describe reading channels.slack and delegating to the tool-equipped skill or
include instructions to add the MCP tools to allowed-tools.

In `@claude-ops/skills/setup/SKILL.md`:
- Around line 1398-1429: The setup flow currently writes slack_workspaces[] to
prefs before the required shell/profile env persistence and Claude MCP
registration are completed; change the wizard in SKILL.md so that the steps run
non-interactively from the wizard (use the Bash tool to export/persist the env
var, add the keychain entry, and perform the Claude MCP registration via the
described commands) and only append to slack_workspaces[] after those commands
return success, or alternatively delay persisting slack_workspaces[] until a
successful MCP registration completes; update references to
bin/ops-slack-workspaces, the prefs key slack_workspaces[], and the MCP
registration step so the code path enforces running the commands
programmatically (background long-running tasks with run_in_background: true)
rather than asking the user to run them manually.
- Around line 1392-1439: The persisted token shape in slack_workspaces[] must
match the auth used by the smoke test (curl with Authorization: Bearer
${TOKEN}); update the persistence logic that writes to slack_workspaces[] and
the SLACK_BOT_TOKEN_<NAME> variable so you either (A) extract and persist a
direct Web API token (xoxb/xoxp/xapp) instead of the browser xoxc token when
building the entry, or (B) persist a structured session object (e.g. store both
xoxc and xoxd as token_session:{xoxc: "...", xoxd: "..."} in slack_workspaces[])
and update the smoke-test and any curl/fallback callers to use both
Authorization: Bearer ${xoxc} and the d=${xoxd} cookie; ensure the jq append
step that writes slack_workspaces[] and the helper bin/ops-slack-workspaces
logic reflect the chosen format and the printed instructions reference the
correct env-var/name semantics (SLACK_BOT_TOKEN_<NAME> for direct tokens or a
session-specific env/key if storing pairs).