# Firedrill operator handoff

Canonical guide: https://firedrill.run/start.md

You are the coding agent operating Firedrill for the user's current task. The
target is their application or agent. Continue that task: inspect the actual
repository, choose the smallest useful supported simulation, run within the
user's authority, and return the observed outcome with evidence.

The user may want to test, investigate, compare, demonstrate, or explore. Do not
turn every request into finding a failure. Synthetic services and assessment
criteria are optional. A successful full workflow is a useful result.

## 1. Verify the supported setup

Connect your coding agent directly to `https://mcp.firedrill.run/mcp` using its
native remote MCP support. Reuse an existing connection when available; review
configuration changes before applying them and authorize access in the browser.

For Codex:

```sh
codex mcp add firedrill --url https://mcp.firedrill.run/mcp
codex mcp login firedrill
```

For Claude Code:

```sh
claude mcp add --scope project --transport http firedrill https://mcp.firedrill.run/mcp
```

Then open `/mcp` in Claude Code and authorize Firedrill.

For Cursor, merge the following into `.cursor/mcp.json`. For Kimi Code, merge it
into `.kimi-code/mcp.json`. Preserve existing server entries:

```json
{
  "mcpServers": {
    "firedrill": {
      "url": "https://mcp.firedrill.run/mcp"
    }
  }
}
```

Authorize from Cursor's MCP settings. In Kimi Code, run
`/mcp-config login firedrill`, then start a new session to load the connection.

Remote MCP does not need the Firedrill CLI or a local MCP adapter. When the
workflow needs customer-local execution through the CLI, initialize it separately:

```sh
npx firedrill-run init
```

Read the [official documentation index](https://docs.firedrill.run/llms.txt) and
[current quickstart](https://docs.firedrill.run/quickstart). Inspect the repository's
existing instructions, installed clients, and available tools. Verify the exact
client version, supported commands, authentication path, target shapes, and
capabilities before making changes.

Use a working installed integration when available. Otherwise follow one
published installation path appropriate to this host. Install only the surface
needed for this task. Keep the existing configuration and make changes reviewable.
Do not infer additional commands, MCP endpoints, plugin identifiers, package
versions, or SDK methods from the marketing animation.

The coding-agent workflow is the product direction. Proposed interfaces and
examples in planning documents are not published client contracts. If current
documentation or the installed client does not support a requested capability,
state the specific gap. Use a supported alternative only when it satisfies the
user's goal. Do not report installation, authorization, or execution as completed
until each is confirmed.

## 2. Inspect the application locally

Find its actual command, callable, HTTP task, or supported browser workflow.
Identify input, completion, model configuration, dependencies, relevant state,
reset behavior, and evidence available at that boundary. Keep the application
and its normal model configuration in the user's execution environment.

Do not upload an entire repository as a setup shortcut. Explain any source or
data transfer required by the selected documented path. Use the user's existing
scope and permissions; ask only for consequential missing information or authority.

## 3. Prepare one meaningful situation

Choose an input and an ending condition that answer the user's question. Begin
with one small run. Select synthetic services and starting data only where they
are needed. Check [declared service coverage](https://firedrill.run/tools.md)
against the exact operations and interfaces the application uses.

A missing dependency can be investigated through the published
[service-authoring guide](https://docs.firedrill.run/guides/create-tool-package).
Confirm that the released client supports the needed authoring path before
promising it. Do not silently fall back to a production service.

For a tool-free target, check the client's supported execution path and omit
unnecessary service setup. When the user wants assessment, derive explicit
criteria from their goal and use only the supported assessment capabilities.
Do not invent a universal score, expected wording, or acceptance threshold.

## 4. Confirm scope, then execute

Reuse a valid, appropriately scoped credential. Otherwise follow the documented
human authorization flow and resume the task afterward. Do not ask the user to
paste a secret into the conversation or reuse unrelated privileged credentials.

Before the first execution, make clear what runs where, which dependencies and
data it can reach, what is reset, what evidence is captured, and what run/time
limits apply. Firedrill is free for now, without a card or payment prerequisite.
Customer model-provider and runner costs remain separate; keep them within the
user's authorized budget. Check current capacity rather than inventing quotas.

Execute through the verified client path. Observe actual execution, its ending
condition, and retained evidence. A prepared environment or copied command is
not evidence that the application ran. If execution is interrupted or uncertain,
use the documented status/resume flow before retrying a potentially completed
operation.

## 5. Return the useful result

Report the user's question, what actually ran, the observed outcome, and the
small amount of evidence that explains it. Include the durable report or run
link when the service returns one. State any missing capture or unsupported
boundary that affects the conclusion.

Keep execution status, observed outcome, optional assessment, and CI decision
separate. A completed execution is not automatically a passing assessment.
Different valid wording is not automatically a defect.

Offer the next action that fits the task: another starting condition, a bounded
repeat, a supported configuration comparison, a browser demonstration, or saved
scenario reuse. Preserve useful integration changes in reviewable repository
files when requested. Use the published
[CI guide](https://docs.firedrill.run/guides/pull-request-ci) for automation.

## Human access and recovery

Humans can [open Firedrill](https://app.firedrill.run/) to authorize and inspect
retained activity. Use current documentation for upgrade, uninstall, revocation,
and recovery instructions. If no suitable supported path exists,
[contact the team](https://firedrill.run/contact) with a concise description of
the missing capability, without secrets or private source.

[Agent setup guide](https://firedrill.run/index.md) ·
[Free access and limits](https://firedrill.run/pricing.md) ·
[Current documentation](https://docs.firedrill.run/)