# Instrument the service before it ships

Reads the new service and drafts the logs and spans its first incident will need, in your Honeycomb or Axiom setup.

## The prompt

```
I want to do this: payments-v2 ships next week. What instrumentation should it have before launch? Draft it.

## Setup (skip if Polylane is already set up)

Read and follow https://polylane.com/auth.md for non-interactive signup and setup. Start by checking whether I am already signed in; reuse my account and workspace.

If the CLI is missing, bootstrap it without starting the interactive wizard:

curl -fsSL 'https://polylane.com/setup?ref=prompts' | bash -s -- --install-only

Then follow the guide through email verification, workspace selection, source connections, and MCP authentication. Ask me for an email code or OAuth consent only when needed. Verify each step; report pending setup instead of claiming success from installation alone.

## How to work

Over MCP: searchTools lists what this workspace exposes, with each tool's schema; call it first. runTool runs one tool, runCode chains several in one call and returns just the answer. search and execute cover the full Polylane REST API: threads, issues, investigations, autofixes, memories.
From the terminal: the polylane CLI wraps the same API, with structured output and non-interactive flags everywhere.
Reads always work. Write tools appear only if I have opted in, and every write is screened.

## Task: Instrument the service before it ships

Steps:
1. Read the new service's routes and handlers
2. Compare against the conventions your instrumented services already use
3. Find the blind spots: swallowed errors, missing context, no traces
4. Draft the instrumentation in the repo's own style
5. Deliver the changes ready for review before launch

Ground every claim in data you actually pulled: the query, the log line, the change record. If the data is inconclusive, say so. Ask me before anything that writes.
```

## What it replaces

**New services ship with hope instead of telemetry.** Instrumentation is the task that always loses to launch pressure. The gaps surface with the first real incident, when it's too late to add the log line you need.

- The launch checklist with no observability row
- First incident, zero usable logs
- Tracing added after the outage it would have explained

## What the agent does

1. Read the new service's routes and handlers
2. Compare against the conventions your instrumented services already use
3. Find the blind spots: swallowed errors, missing context, no traces
4. Draft the instrumentation in the repo's own style
5. Deliver the changes ready for review before launch

## What you get

**Launch with eyes** The service ships with the telemetry its first incident will need, drafted in your conventions. Day-one debugging starts from data.

Every prompt: https://polylane.com/prompts/

Get started with one command: `curl -fsSL https://polylane.com/setup | bash` installs the CLI, connects your coding agents, and creates the account.