README.md already lists Hermes Agent alongside OpenClaw as a supported
external harness for driving CAO via the cao-session-management skill,
but external-tool-integration.md only walked through OpenClaw. Add
Hermes target paths to Options A and C so the doc matches the README's
supported-harness list.

- Option A: add commented Hermes TARGET_SKILLS path (~/.hermes/skills/cli-agent-orchestrator)
- Option C: add Hermes-specific skill_manage invocation and note the
  copy-vs-symlink staleness tradeoff
- Intro: name both OpenClaw and Hermes Agent as worked examples

Verified end-to-end on Hermes: launched code_supervisor + developer +
reviewer via cao launch --headless --yolo on the kiro_cli provider and
produced a working hello.py.

…to cao-session-management

Agents loading the skill cold currently have to assemble a working
'cao launch' from rules scattered through the doc, and silently assume
two prerequisites that fail confusingly when missing:

- cao-server must be running at localhost:9889
- the target agent profile must already be installed via cao install

Add three additive sections before 'Launching a Session':

1. **Prerequisites** — explicit cao-server health check (curl one-liner)
   and a reminder that profiles must be pre-installed.
2. **Discovering Available Profiles** — table of where to look depending
   on provider (kiro-cli agent list, agent-store/, README built-ins).
3. **Quick Example** — copy-pasteable end-to-end supervisor launch on
   the default kiro_cli provider, plus status/shutdown commands.

No existing content removed; these are anchors a first-time agent can
grab onto before reading the rules section.

Verified against the skill end-to-end on Hermes Agent: launched
code_supervisor + developer + reviewer headlessly and produced a
working hello.py in 2m 38s.

The previous skill update leaned too heavily on kiro_cli, but profiles
in CAO are provider-agnostic — 'cao install' is the canonical install
path for any provider, and ~/.aws/cli-agent-orchestrator/agent-store/
is the source of truth for what's installed locally. Workers inherit
the launching terminal's provider unless pinned via frontmatter
(README §Cross-Provider Orchestration).

Changes:
- Discovering Available Profiles: lead with the provider-agnostic
  agent-store/ listing and built-in install commands; demote
  'kiro-cli agent list' to a provider-specific note (CAO mirrors
  profiles into ~/.kiro/agents/, which is why it works for kiro_cli).
- Quick Example: keep kiro_cli as the default but enumerate every
  supported provider for --provider, and add a commented cross-provider
  variant so claude_code / codex / gemini_cli / kimi_cli / copilot_cli /
  opencode_cli / q_cli users see themselves in the doc.
- Launching rule: replace the kiro-only --agents discovery hint with a
  cross-link to the new section.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

Per Copilot review on PR #253: `cao install <built-in>` writes to
`agent-context/`, not `agent-store/`. The latter only holds custom
local profile files. The HTTP endpoint `/agents/profiles` is the
canonical, provider-agnostic way to see all installed profiles with
`source` labels (built-in vs local).

- Promote `curl /agents/profiles` as the recommended check
- Split filesystem rows into agent-store (local) vs agent-context (built-ins)
- Add explanatory note below the table

Per @anilkmr-a2z review on PR #253: the Quick Example should
foreground that it runs against an already-configured CAO host;
`cao install` belongs to one-time setup, not to every launch.

- Add note above the code block stating the example assumes a
  configured CAO setup and that users can skip to `cao launch` on
  an already-configured host.
- Re-frame the install lines as Optional first-time setup rather
  than mandatory pre-launch steps.

Per Copilot review on PR #253: the previous wording overstated the
endpoint's behavior. `list_agent_profiles()` actually scans three
sources (built-in packaged store, local agent-store, provider
directories including agent-context) and de-duplicates by profile
name (built-in wins), rather than "merging" two specific dirs.

- Reword the table row to "all available profiles across built-in
  store + local store + provider directories"
- Reword the explanatory paragraph to describe the three-source scan
  and dedup behavior accurately