---
name: scout
description: Use OpenScout to ask another coding agent for work or a reply, route by project and capability, and follow the returned work handle through CLI or MCP.
---

# Scout

Use Scout when the operator wants another agent to investigate, review, implement,
or reply. Keep the work within the operator's authorized scope. A skill teaches
this workflow; it does not install Scout, configure MCP, or grant access.

This portable skill works with a shell that can run the Scout CLI or a configured
Scout MCP connection. If neither is available, use the
[installation guide](https://openscout.app/install.md) or
[MCP setup guide](https://openscout.app/mcp/). For Slack or A2A, follow that
[transport's guide](https://openscout.app/integrations/) instead of inventing
CLI or MCP access in the client.

## Ask first

Requested work, judgment, investigation, or a reply is an **ask**. Use `scout tell`
(MCP `messages_send`) only for one-way updates with no owned next step. Don't use `send`. To answer an
existing ask, use its supplied reply context rather than launching a new ask.

## Choose the available interface

### CLI

When the project and desired capability are known, route directly. Replace the
example path with the actual project on the Scout execution machine and choose
an installed, supported harness:

```bash
scout ask --project /absolute/path/to/project --harness claude --notify "Review the latest changes and report findings. Do not edit files."
```

Retain the returned handle and observe that same work:

```bash
scout wait <returned-ref>
```

Use `scout runtimes --json` when you need to discover supported execution options.
For an exact runtime, select supported harness/model/effort values and inspect
the invocation's execution resolution before claiming what ran. Do not invent
agent names. A known project plus capability is preferable to a guessed target.

### MCP

Inspect the current Scout tool schemas. If identity or project context is unclear,
call `whoami`. For new work, use `ask` with a known project and supported harness:

```json
{
  "projectPath": "/absolute/path/on/scout-machine",
  "harness": "claude",
  "body": "Review the latest changes and report findings. Do not edit files.",
  "replyMode": "notify"
}
```

Keep the returned invocation/flight handle. Observe it with `invocations_get` or
`invocations_wait`, using the installed tool's input schema. These tools observe
existing work; they do not create another request.

## Continue without duplicating work

- A receipt means the broker accepted the request. Report completion only after
  observing the result and terminal state.
- Preserve the returned ref, flight, conversation, work, or session handle for
  follow-up. A wait timeout does not cancel the work or authorize a duplicate.
- For an exact existing session, use its returned `session:<id>` handle. For a
  fresh project-scoped worker, use project plus capability.
- On missing authentication, provisioning, permissions, or an ambiguous target,
  report the specific blocker. Do not silently switch accounts or runtimes.
- Keep credentials and private task payloads out of public reports.

## Report back

State what was requested, the returned work handle, what result was actually
observed, and any remaining blocker or operator decision. Distinguish accepted,
running, waiting for input, and completed.

## References

- [CLI reference](https://openscout.app/cli)
- [MCP setup and verification](https://openscout.app/mcp/)
- [Client-specific user and agent guides](https://openscout.app/integrations/)
- [Machine-readable integration catalog](https://openscout.app/integrations.json)