> ## Documentation Index
> Fetch the complete documentation index at: https://docs.findtempo.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Writing good instructions

> The difference between a signal that works and one that returns noise.

A signal's extraction instructions are its entire configuration. There are no keywords to tune. Getting the instructions right is the whole job.

The pattern that works has three parts: a **description** that draws a boundary, **positive examples**, and **negative examples**.

## The shape

```text wrap theme={null}
Description
Identifies [the specific thing], often expressed as [how people actually phrase it].
This signal tracks explicit statements from [whose statements count] — such as
[roles] — expressing [the specific condition]. It excludes [the near-misses that
should not match].

Positive Examples
- In a technical requirements document, the lead developer specifies: "[quote]"
- During a demo, the prospect's VP of Product states: "[quote]"
- In an email thread, the customer's project manager writes: "[quote]"

Negative Examples
- A seller suggests that [the thing] could be possible.
- The prospect asks for [an adjacent but different thing].
- An internal message speculating that the client might eventually want [the thing].
```

## Why negative examples matter most

Positive examples teach the signal what to catch. Negative examples teach it what to *stop* catching — and that's where noisy signals come from.

Three failure modes account for most of it:

**Seller statements matching instead of buyer statements.** Your rep speculating "they'll probably need a security review" is not the customer requiring one. Say so explicitly.

**Adjacent topics matching.** A signal for "custom UI requirements" will happily match someone asking for your design system docs unless you rule it out.

**Hypotheticals matching.** "We might want this someday" and "we need this to move forward" read similarly to a model and mean opposite things commercially.

## Be specific about whose words count

The single highest-leverage sentence in most instructions names the speaker:

> This signal tracks explicit statements from buyer-side stakeholders — such as product managers, designers, or technical leads.

Without it, you'll capture your own team's internal chatter alongside genuine customer signal.

## Scope the document types deliberately

Instructions and document types work together. A signal about formal requirements probably belongs on `document`, `email`, and `transcript` — not `brain-dump`, where people think out loud.

Narrowing document types is also the cheapest way to cut noise without touching the instructions at all.

## Iterate against the preview

Draft, preview, read the misses, refine, preview again. The preview runs against real artifacts, so it tells you what the signal actually does rather than what you meant.

Two questions to ask of every preview:

1. **What did it catch that it shouldn't have?** Each of those is a missing negative example.
2. **What did it miss?** Each of those is either a missing positive example or a document type you didn't include.

## Limits

| Constraint         | Value                        |
| ------------------ | ---------------------------- |
| Instruction length | Up to 20,000 characters      |
| Signal name        | Up to 255 characters         |
| Document types     | 1–9, from the supported list |

Instructions can be long. Use the room — a signal with six well-chosen examples will outperform one with a single sentence every time.