Open skills library

Your agent is only as good as the skills it runs.

One step. Copy the prompt, paste it into Claude, say yes to the permissions it asks for. It writes all 7 skills for you.

then just ask, in your own words

Signals2 files

Hiring signals to outbound list

Job posts in. A scored list with the hooks already written, out.

The tell

The expert's tell: read the whole hiring page, not the one posting that matched. A company advertising one salesperson alongside four engineers has an engineering department and solves its own problems. A company advertising one salesperson and nothing else is buying capacity because it has no other lever. Same trigger, two completely different prospects, and only the second one is in the market for operational help.

---
name: hiring-signals
title: Hiring signals to outbound list
description: |
  Use this skill when building an outbound list from hiring activity - a new
  territory, an empty pipeline, a signal-based campaign, or any ask like "who is
  hiring right now", "find me companies to reach out to", "build a target list
  from job postings". Produces a scored, verified list where every row carries
  the hook already written.
category: Signals
tags: [Sales]
---

A company that just posted a go-to-market role has published its intent. This turns
that into a list you can send today.

## The play

1. **Fix the ICP shape before collecting.** Company size band, sector, and the roles
   that count as a buying signal for what you sell. Collection without this returns
   volume and no list.
2. **Collect from the sources your buyers actually post on.** National job boards,
   sector boards, and company career pages. Read the public HTML. Run each source as
   its own process and merge, so one slow source cannot hold the rest.
3. **Reject in three layers, cheapest first.** Mechanical, then shape, then scored.
   Full rubric in `references/scoring-rubric.md`. Most of the work here is rejection,
   and each layer exists so the expensive judgment runs on the smallest set.
4. **Verify every survivor against its source page.** Fetch the URL, confirm the
   company name appears on it. Anything that resolves to a category page rather than
   the posting gets resolved or dropped.
5. **Write the hook per row before the list ships.** One line naming the role posted
   and what it implies about their quarter. A row whose hook cannot be written did
   not belong on the list.
6. **Check the list against the CRM last.** Existing customers, open opportunities
   and anyone in an active sequence come out before a human ever sees it.

## What good looks like

- **The expert's tell: read the whole hiring page, not the one posting that matched.**
  A company advertising one salesperson alongside four engineers has an engineering
  department and solves its own problems. A company advertising one salesperson and
  nothing else is buying capacity because it has no other lever. Same trigger, two
  completely different prospects, and only the second one is in the market for
  operational help.
- **The mediocre version is a list of company names and job titles.** It gets handed
  to a rep who now has to research each row before writing anything, which means the
  list is doing none of the work. Rows arrive hook-first or they arrive useless.
- **Verification is the quality bar, not a nice-to-have.** Any list built with model
  web access contains plausible fabrications. A hallucinated job posting in a first
  line burns a real prospect permanently, and it burns them at exactly the moment you
  claimed to have done your research.
- **Concretely good:** 40 to 60 rows surviving from a few hundred collected, every URL
  resolving to a live posting under 30 days old, every row carrying a hook naming the
  specific role, and a rejection count you can explain layer by layer.
- **A run that returns everything collected is a broken run.** If the gate rejected
  almost nothing, the gate is not wired, and the list is about to cost more in reply
  damage than it returns in meetings.

## Rules

- MUST verify every URL against the live page before the list ships.
- MUST write the hook into the row, not into a separate brief nobody opens.
- MUST check robots.txt per source and read public HTML only.
- NEVER call a board's internal API because it appeared in the network tab.
- NEVER treat a missing model verdict as a score of zero. A company the model omitted
  is unjudged, not unfit. Track omissions, retry them, and report them separately.
- NEVER ship a row whose posting date cannot be established.

# Scoring rubric - the three-layer gate

Run the layers in order. Each one exists so the next, more expensive layer sees a
smaller set. Skipping straight to model judgment costs 10x and scores noise.

## Layer 1 - mechanical (free, removes the most)

| Test | Threshold | Why |
|---|---|---|
| Posting age | 30 days or less | Older than that and the role is filled or frozen. The signal has decayed. |
| Role type | GTM only: sales, marketing, revenue, growth, business development, customer success | An operations or finance hire is a different play with a different hook. |
| Poster identity | Not a staffing agency, not a job aggregator reposting | The agency is not the buyer and cannot be sold to. |
| Role seniority | Any, but record it | A first sales hire and a fifth SDR imply opposite maturity. |

### The inflection trap

Many languages inflect job titles by gender, and the inflected form does not contain
the base form as a substring. A plain substring match on the base title silently
dropped 57 real postings on one full run, every one of them filed as "not a GTM role"
and never surfaced for review.

Normalise titles to a base form before matching, and validate the filter against a
hand-checked sample of 30 postings before trusting a run. This class of bug is silent:
the run completes, the numbers look plausible, and the misses never appear anywhere.

## Layer 2 - shape (free, removes the anti-ICP)

Count every open role on the company's careers page, not just the one that matched.

```
tech_share = engineering roles / total open roles
```

| tech_share | Read | Action |
|---|---|---|
| Under 0.25 | No internal build capacity. Buys outcomes. | Keep, score normally |
| 0.25 to 0.50 | Mixed. Depends on what you sell. | Keep, flag for the human |
| Over 0.50 | Has an engineering department. Builds its own. | Drop unless you sell to engineering |

One posting tells you a role is open. The full page tells you what kind of company it
is, and that is the part that decides whether the outreach lands.

## Layer 3 - scored judgment (costs a model call, runs on survivors only)

Score each survivor 0 to 100 on four axes, weighted:

| Axis | Weight | What a high score means |
|---|---|---|
| ICP fit | 40 | Size, sector and structure match what you actually close |
| Signal strength | 25 | The role posted maps directly to the pain you solve |
| Reachability | 20 | A named decision maker is identifiable |
| Timing | 15 | Posted inside 14 days, or multiple related roles opened at once |

Ship at 60 and above. Between 45 and 60, hold for a human pass. Below 45, drop.

### The missing-verdict trap

When a model returns judgments for a batch, it will sometimes omit rows entirely.
Scoring an omitted row as 0 is indistinguishable from judging it unfit, and it fails
silently in the direction that looks like diligence. On one run this buried two of the
strongest companies in the batch, both of which would have scored above 75.

Reconcile the returned set against the submitted set on every batch. Retry the misses
once. Report anything still missing as unjudged, never as rejected.

---
name: hiring-signals
title: Hiring signals to outbound list
description: |
  Use this skill when building an outbound list from hiring activity - a new
  territory, an empty pipeline, a signal-based campaign, or any ask like "who is
  hiring right now", "find me companies to reach out to", "build a target list
  from job postings". Produces a scored, verified list where every row carries
  the hook already written.
category: Signals
tags: [Sales]
---

A company that just posted a go-to-market role has published its intent. This turns
that into a list you can send today.

## The play

1. **Fix the ICP shape before collecting.** Company size band, sector, and the roles
   that count as a buying signal for what you sell. Collection without this returns
   volume and no list.
2. **Collect from the sources your buyers actually post on.** National job boards,
   sector boards, and company career pages. Read the public HTML. Run each source as
   its own process and merge, so one slow source cannot hold the rest.
3. **Reject in three layers, cheapest first.** Mechanical, then shape, then scored.
   Full rubric in `references/scoring-rubric.md`. Most of the work here is rejection,
   and each layer exists so the expensive judgment runs on the smallest set.
4. **Verify every survivor against its source page.** Fetch the URL, confirm the
   company name appears on it. Anything that resolves to a category page rather than
   the posting gets resolved or dropped.
5. **Write the hook per row before the list ships.** One line naming the role posted
   and what it implies about their quarter. A row whose hook cannot be written did
   not belong on the list.
6. **Check the list against the CRM last.** Existing customers, open opportunities
   and anyone in an active sequence come out before a human ever sees it.

## What good looks like

- **The expert's tell: read the whole hiring page, not the one posting that matched.**
  A company advertising one salesperson alongside four engineers has an engineering
  department and solves its own problems. A company advertising one salesperson and
  nothing else is buying capacity because it has no other lever. Same trigger, two
  completely different prospects, and only the second one is in the market for
  operational help.
- **The mediocre version is a list of company names and job titles.** It gets handed
  to a rep who now has to research each row before writing anything, which means the
  list is doing none of the work. Rows arrive hook-first or they arrive useless.
- **Verification is the quality bar, not a nice-to-have.** Any list built with model
  web access contains plausible fabrications. A hallucinated job posting in a first
  line burns a real prospect permanently, and it burns them at exactly the moment you
  claimed to have done your research.
- **Concretely good:** 40 to 60 rows surviving from a few hundred collected, every URL
  resolving to a live posting under 30 days old, every row carrying a hook naming the
  specific role, and a rejection count you can explain layer by layer.
- **A run that returns everything collected is a broken run.** If the gate rejected
  almost nothing, the gate is not wired, and the list is about to cost more in reply
  damage than it returns in meetings.

## Rules

- MUST verify every URL against the live page before the list ships.
- MUST write the hook into the row, not into a separate brief nobody opens.
- MUST check robots.txt per source and read public HTML only.
- NEVER call a board's internal API because it appeared in the network tab.
- NEVER treat a missing model verdict as a score of zero. A company the model omitted
  is unjudged, not unfit. Track omissions, retry them, and report them separately.
- NEVER ship a row whose posting date cannot be established.

# Scoring rubric - the three-layer gate

Run the layers in order. Each one exists so the next, more expensive layer sees a
smaller set. Skipping straight to model judgment costs 10x and scores noise.

## Layer 1 - mechanical (free, removes the most)

| Test | Threshold | Why |
|---|---|---|
| Posting age | 30 days or less | Older than that and the role is filled or frozen. The signal has decayed. |
| Role type | GTM only: sales, marketing, revenue, growth, business development, customer success | An operations or finance hire is a different play with a different hook. |
| Poster identity | Not a staffing agency, not a job aggregator reposting | The agency is not the buyer and cannot be sold to. |
| Role seniority | Any, but record it | A first sales hire and a fifth SDR imply opposite maturity. |

### The inflection trap

Many languages inflect job titles by gender, and the inflected form does not contain
the base form as a substring. A plain substring match on the base title silently
dropped 57 real postings on one full run, every one of them filed as "not a GTM role"
and never surfaced for review.

Normalise titles to a base form before matching, and validate the filter against a
hand-checked sample of 30 postings before trusting a run. This class of bug is silent:
the run completes, the numbers look plausible, and the misses never appear anywhere.

## Layer 2 - shape (free, removes the anti-ICP)

Count every open role on the company's careers page, not just the one that matched.

```
tech_share = engineering roles / total open roles
```

| tech_share | Read | Action |
|---|---|---|
| Under 0.25 | No internal build capacity. Buys outcomes. | Keep, score normally |
| 0.25 to 0.50 | Mixed. Depends on what you sell. | Keep, flag for the human |
| Over 0.50 | Has an engineering department. Builds its own. | Drop unless you sell to engineering |

One posting tells you a role is open. The full page tells you what kind of company it
is, and that is the part that decides whether the outreach lands.

## Layer 3 - scored judgment (costs a model call, runs on survivors only)

Score each survivor 0 to 100 on four axes, weighted:

| Axis | Weight | What a high score means |
|---|---|---|
| ICP fit | 40 | Size, sector and structure match what you actually close |
| Signal strength | 25 | The role posted maps directly to the pain you solve |
| Reachability | 20 | A named decision maker is identifiable |
| Timing | 15 | Posted inside 14 days, or multiple related roles opened at once |

Ship at 60 and above. Between 45 and 60, hold for a human pass. Below 45, drop.

### The missing-verdict trap

When a model returns judgments for a batch, it will sometimes omit rows entirely.
Scoring an omitted row as 0 is indistinguishable from judging it unfit, and it fails
silently in the direction that looks like diligence. On one run this buried two of the
strongest companies in the batch, both of which would have scored above 75.

Reconcile the returned set against the submitted set on every batch. Retry the misses
once. Report anything still missing as unjudged, never as rejected.

RevOps3 files

CRM hygiene layer

Score the data, queue the decisions, catch the drift nightly.

The tell

The expert's tell: check for records that synced as empty shells. Every internal check passes on a contact with a name, an ID and no content. Row counts look right, dashboards look right, and the interaction history the rep is about to rely on is blank. Comparing length against the source is the only thing that surfaces it, and almost nobody does it.

---
name: crm-hygiene
title: CRM hygiene layer
description: |
  Use this skill when the CRM cannot be trusted - before any personalized outreach,
  or on asks like "score my data quality", "find duplicate contacts", "why are my
  lead statuses wrong", "clean up the CRM", "our pipeline numbers are off". Produces
  a health score, a queue of decisions for a human, and a watchdog that catches drift
  before it reaches a customer.
category: RevOps
tags: [RevOps]
---

Personalized outreach on dirty data is worse than no outreach. This is the layer that
runs underneath everything else in the funnel.

## The play

1. **Score before fixing.** Scan every contact, classify each issue by category and
   severity, and produce a single number. Categories and severities in
   `references/issue-categories.md`. A score makes the argument for the work and gives
   you something to move.
2. **Route findings to a queue, never to an auto-fix.** Issues land where a human
   reviews them. Scanning is read-only. Fixing is a separate, explicit, logged action.
3. **Put one gatekeeper in front of every lifecycle write.** One path creates or
   advances a lead. Nothing else writes lead status, ever. The rules it enforces are
   in `references/state-invariants.md`.
4. **Run a nightly watchdog that reports drift and does not silently repair it.**
   Drift means a writer escaped the gatekeeper. Quietly patching the symptom hides the
   writer, and the writer will do it again tomorrow.
5. **Reconcile against the source, not just against yourself.** For each connected
   system, count what is present, what is missing, and what arrived thin. Thin is the
   one that matters and the one nothing else catches.
6. **Merge duplicates only on a human click**, and repoint every related record when
   the merge runs.

## What good looks like

- **The expert's tell: check for records that synced as empty shells.** Every internal
  check passes on a contact with a name, an ID and no content. Row counts look right,
  dashboards look right, and the interaction history the rep is about to rely on is
  blank. Comparing length against the source is the only thing that surfaces it, and
  almost nobody does it.
- **The mediocre version is a one-time cleanup script.** It runs, the score jumps, and
  six weeks later the data is dirty again because nothing changed about how records
  get written. Hygiene is a standing system or it is theatre.
- **Alert volume is the real quality bar.** A nightly digest of the same 40 known
  issues gets muted inside a week, and the one alert that mattered gets muted with it.
  Alert on new problems only.
- **Concretely good:** a health score above 85, a duplicate queue that clears faster
  than it fills, a watchdog that is silent on a clean night, and a heartbeat per job
  so a job that stops running is itself an alert. A silent cron is not a passing cron.
- **Ambiguity is a queue, not a rule.** Choosing which of two live opportunities on
  one account survives is judgement. Encoding a guess as an automatic rule is how a
  system quietly deletes the wrong one at scale.

## Rules

- MUST make every scanner read-only, and every fixer explicit and logged.
- MUST return an outcome from every gatekeeper call: created, advanced, unchanged,
  vetoed, blocked, archived. Silent no-ops are how trust in the system dies.
- MUST repoint every related record on a merge: interactions, opportunities, notes,
  tags, campaign membership.
- NEVER auto-merge, auto-delete or auto-disqualify without a human click.
- NEVER let the watchdog fix what it found without recording what it changed and why.
- NEVER treat derived fields as writable. Lifecycle stage, pool and status flags are
  projections of one source field and get re-derived, never set by hand.

# Issue categories and the health score

Every finding lands in exactly one category with a fixed severity. Severity drives the
queue order, and the mix drives the score.

| Category | Severity | Definition | Why it costs you |
|---|---|---|---|
| `junk_name` | HIGH | Name is emoji only, a chat identifier, a raw phone number, empty, or "Unknown" | It will be merged into a greeting and sent to a real person |
| `duplicate` | HIGH | Same phone, or same multi-token name, on another record | The same prospect gets the same sequence twice, from two reps |
| `conflict` | HIGH | An unresolved merge conflict | Two versions of the truth, and reps are reading the wrong one |
| `missing_contact_info` | MED | No email, no phone, no social profile | Uncontactable. It inflates every pipeline count it appears in |
| `incomplete` | LOW | Missing company or title | Personalization silently degrades to generic |
| `no_interactions` | LOW | Zero activity on any channel | Either dead weight or a sync that never landed |
| `stale` | LOW | An open opportunity with no activity in 180 days | It is not open, it is abandoned, and it is corrupting the forecast |

## Scoring

```
score = 100 - (HIGH x 3 + MED x 1.5 + LOW x 0.5) / total_records x 100
```

Floor at 0, round to a whole number.

| Score | Read |
|---|---|
| 90 to 100 | Healthy. Personalized outreach is safe |
| 75 to 89 | Usable. Fix HIGH before a campaign |
| 60 to 74 | Do not run personalized outreach yet |
| Under 60 | The CRM is a liability. Stop and fix it |

## Running it

The default run writes nothing: score, counts per category, and five sample records
per category so the numbers are inspectable. Only an explicit live flag writes issues,
and it refreshes the open set while leaving anything already dismissed or resolved
untouched. A scanner that resurrects issues a human deliberately dismissed trains the
human to ignore the queue.

Fix in severity order, not alphabetically, and re-score after each category clears so
the effect of the work is visible.

# State invariants - what the watchdog checks

The gatekeeper enforces these on write. The watchdog verifies them nightly, because a
writer that escaped the gatekeeper will not announce itself.

## What the gatekeeper enforces

- A disqualification is absolute. A record marked not-a-prospect never becomes one
  again through an automation.
- One active opportunity per account. Additional people at that account are contacts
  on it, not parallel opportunities.
- Advance only. An automation moves a record forward through the funnel or leaves it
  alone. It never moves one backwards.
- Derived fields are projections. Lifecycle stage, pool and status flags are computed
  from one source field and re-derived, never written directly.

## The invariants

| # | Invariant | Auto-repair |
|---|---|---|
| I1 | Record has an active opportunity, so its status reads as active | Yes |
| I2 | Record has a won deal, so its status reads as customer | Yes |
| I3 | Status reads active, so an active opportunity or open deal exists | Yes |
| I4 | Pool matches the pool implied by status | Yes |
| I5 | Lifecycle stage matches the stage implied by status | Yes |
| I6 | The active tag exists if and only if an active opportunity exists | Yes |
| I7 | One active opportunity per account | No - human only |
| I8 | Disqualified records hold no opportunity | Yes |
| I9 | A converted record is marked converted | No |
| I10 | The opportunity's account matches the contact's account | No |

## Repair policy

Repair only the mechanical projections. I1 to I6 and I8 are re-derivations: the source
field is authoritative and the projection is simply wrong.

**On I8, the disqualification wins.** A record marked not-a-prospect that somehow grew
an opportunity loses the opportunity, not the disqualification. Someone decided that
record was out, and an automation is not entitled to overturn a human judgement by
side effect.

**I7 stays human-only, permanently.** Deciding which of two live opportunities on one
account survives determines whose commission it is. That is a conversation, not a
rule, and automating it produces exactly one angry rep per run.

Log every repair with what changed and why, so it shows up in an activity feed and can
be reversed by hand. A repair nobody can see is indistinguishable from a bug.

---
name: crm-hygiene
title: CRM hygiene layer
description: |
  Use this skill when the CRM cannot be trusted - before any personalized outreach,
  or on asks like "score my data quality", "find duplicate contacts", "why are my
  lead statuses wrong", "clean up the CRM", "our pipeline numbers are off". Produces
  a health score, a queue of decisions for a human, and a watchdog that catches drift
  before it reaches a customer.
category: RevOps
tags: [RevOps]
---

Personalized outreach on dirty data is worse than no outreach. This is the layer that
runs underneath everything else in the funnel.

## The play

1. **Score before fixing.** Scan every contact, classify each issue by category and
   severity, and produce a single number. Categories and severities in
   `references/issue-categories.md`. A score makes the argument for the work and gives
   you something to move.
2. **Route findings to a queue, never to an auto-fix.** Issues land where a human
   reviews them. Scanning is read-only. Fixing is a separate, explicit, logged action.
3. **Put one gatekeeper in front of every lifecycle write.** One path creates or
   advances a lead. Nothing else writes lead status, ever. The rules it enforces are
   in `references/state-invariants.md`.
4. **Run a nightly watchdog that reports drift and does not silently repair it.**
   Drift means a writer escaped the gatekeeper. Quietly patching the symptom hides the
   writer, and the writer will do it again tomorrow.
5. **Reconcile against the source, not just against yourself.** For each connected
   system, count what is present, what is missing, and what arrived thin. Thin is the
   one that matters and the one nothing else catches.
6. **Merge duplicates only on a human click**, and repoint every related record when
   the merge runs.

## What good looks like

- **The expert's tell: check for records that synced as empty shells.** Every internal
  check passes on a contact with a name, an ID and no content. Row counts look right,
  dashboards look right, and the interaction history the rep is about to rely on is
  blank. Comparing length against the source is the only thing that surfaces it, and
  almost nobody does it.
- **The mediocre version is a one-time cleanup script.** It runs, the score jumps, and
  six weeks later the data is dirty again because nothing changed about how records
  get written. Hygiene is a standing system or it is theatre.
- **Alert volume is the real quality bar.** A nightly digest of the same 40 known
  issues gets muted inside a week, and the one alert that mattered gets muted with it.
  Alert on new problems only.
- **Concretely good:** a health score above 85, a duplicate queue that clears faster
  than it fills, a watchdog that is silent on a clean night, and a heartbeat per job
  so a job that stops running is itself an alert. A silent cron is not a passing cron.
- **Ambiguity is a queue, not a rule.** Choosing which of two live opportunities on
  one account survives is judgement. Encoding a guess as an automatic rule is how a
  system quietly deletes the wrong one at scale.

## Rules

- MUST make every scanner read-only, and every fixer explicit and logged.
- MUST return an outcome from every gatekeeper call: created, advanced, unchanged,
  vetoed, blocked, archived. Silent no-ops are how trust in the system dies.
- MUST repoint every related record on a merge: interactions, opportunities, notes,
  tags, campaign membership.
- NEVER auto-merge, auto-delete or auto-disqualify without a human click.
- NEVER let the watchdog fix what it found without recording what it changed and why.
- NEVER treat derived fields as writable. Lifecycle stage, pool and status flags are
  projections of one source field and get re-derived, never set by hand.

# Issue categories and the health score

Every finding lands in exactly one category with a fixed severity. Severity drives the
queue order, and the mix drives the score.

| Category | Severity | Definition | Why it costs you |
|---|---|---|---|
| `junk_name` | HIGH | Name is emoji only, a chat identifier, a raw phone number, empty, or "Unknown" | It will be merged into a greeting and sent to a real person |
| `duplicate` | HIGH | Same phone, or same multi-token name, on another record | The same prospect gets the same sequence twice, from two reps |
| `conflict` | HIGH | An unresolved merge conflict | Two versions of the truth, and reps are reading the wrong one |
| `missing_contact_info` | MED | No email, no phone, no social profile | Uncontactable. It inflates every pipeline count it appears in |
| `incomplete` | LOW | Missing company or title | Personalization silently degrades to generic |
| `no_interactions` | LOW | Zero activity on any channel | Either dead weight or a sync that never landed |
| `stale` | LOW | An open opportunity with no activity in 180 days | It is not open, it is abandoned, and it is corrupting the forecast |

## Scoring

```
score = 100 - (HIGH x 3 + MED x 1.5 + LOW x 0.5) / total_records x 100
```

Floor at 0, round to a whole number.

| Score | Read |
|---|---|
| 90 to 100 | Healthy. Personalized outreach is safe |
| 75 to 89 | Usable. Fix HIGH before a campaign |
| 60 to 74 | Do not run personalized outreach yet |
| Under 60 | The CRM is a liability. Stop and fix it |

## Running it

The default run writes nothing: score, counts per category, and five sample records
per category so the numbers are inspectable. Only an explicit live flag writes issues,
and it refreshes the open set while leaving anything already dismissed or resolved
untouched. A scanner that resurrects issues a human deliberately dismissed trains the
human to ignore the queue.

Fix in severity order, not alphabetically, and re-score after each category clears so
the effect of the work is visible.

# State invariants - what the watchdog checks

The gatekeeper enforces these on write. The watchdog verifies them nightly, because a
writer that escaped the gatekeeper will not announce itself.

## What the gatekeeper enforces

- A disqualification is absolute. A record marked not-a-prospect never becomes one
  again through an automation.
- One active opportunity per account. Additional people at that account are contacts
  on it, not parallel opportunities.
- Advance only. An automation moves a record forward through the funnel or leaves it
  alone. It never moves one backwards.
- Derived fields are projections. Lifecycle stage, pool and status flags are computed
  from one source field and re-derived, never written directly.

## The invariants

| # | Invariant | Auto-repair |
|---|---|---|
| I1 | Record has an active opportunity, so its status reads as active | Yes |
| I2 | Record has a won deal, so its status reads as customer | Yes |
| I3 | Status reads active, so an active opportunity or open deal exists | Yes |
| I4 | Pool matches the pool implied by status | Yes |
| I5 | Lifecycle stage matches the stage implied by status | Yes |
| I6 | The active tag exists if and only if an active opportunity exists | Yes |
| I7 | One active opportunity per account | No - human only |
| I8 | Disqualified records hold no opportunity | Yes |
| I9 | A converted record is marked converted | No |
| I10 | The opportunity's account matches the contact's account | No |

## Repair policy

Repair only the mechanical projections. I1 to I6 and I8 are re-derivations: the source
field is authoritative and the projection is simply wrong.

**On I8, the disqualification wins.** A record marked not-a-prospect that somehow grew
an opportunity loses the opportunity, not the disqualification. Someone decided that
record was out, and an automation is not entitled to overturn a human judgement by
side effect.

**I7 stays human-only, permanently.** Deciding which of two live opportunities on one
account survives determines whose commission it is. That is a conversation, not a
rule, and automating it produces exactly one angry rep per run.

Log every repair with what changed and why, so it shows up in an activity feed and can
be reversed by hand. A repair nobody can see is indistinguishable from a bug.

Research2 files

Meeting prep brief

Walk in as the best-informed person in the room.

The tell

The expert's tell: mine the commitments, not the facts. What did you promise in writing and not deliver? What did they ask that never got answered? Those two lists determine the first 90 seconds of the call, and neither of them lives in a company profile. They live in the thread and the last transcript.

---
name: meeting-prep
title: Meeting prep brief
description: |
  Use this skill before any external meeting - discovery, demo, renewal, partner
  call. Fires on "prep me", "who am I meeting", "research this account before the
  call", "what do I need to know for tomorrow", or a named upcoming meeting.
  Produces a brief that makes you the best-informed person in the room, built from
  the CRM, the thread history, past call transcripts and public research.
category: Research
tags: [Sales]
---

The brief's job is to make you the best-informed person on the call within two hours'
notice. A company summary is not a brief. Anyone can produce a company summary.

## The play

1. **Resolve the target from the calendar, not from memory.** Take the next event with
   an external attendee. The email domain on the invite is ground truth for the
   company. The public profile is ground truth for the person's name.
2. **Gather in parallel.** CRM history, thread history, past call transcripts, public
   profile and recent posts, and company research. These are independent, so running
   them in sequence wastes the window you have.
3. **Read the last transcript in full before anything else.** What they said in their
   own words outranks everything you will find on the web.
4. **Find the angle.** One specific reason this conversation matters to them this
   quarter, traceable to something they said or something that changed at their
   company.
5. **Write it to the template.** Structure in `references/brief-template.md`. Same
   shape every time, so it can be read in the four minutes before a call.
6. **File it against the account record and link it.** A brief you cannot find 20
   minutes before the call did not exist.

## What good looks like

- **The expert's tell: mine the commitments, not the facts.** What did you promise in
  writing and not deliver? What did they ask that never got answered? Those two lists
  determine the first 90 seconds of the call, and neither of them lives in a company
  profile. They live in the thread and the last transcript.
- **The mediocre version is a research dump.** Funding history, headcount, a summary
  of the website, and no reason for the meeting to happen. It reads as thorough and
  changes nothing about how the call goes.
- **Test the angle by portability.** If the ANGLE section could be pasted into a brief
  for a different company in the same sector, it is not an angle, it is a description.
  Go back to the transcripts and find the sentence only this person said.
- **Concretely good:** one page, readable in four minutes, every claim traceable to a
  source, a named ask for this specific call, and the objection you expect written out
  before you hear it.
- **Names heard out loud are unreliable.** A company heard as one thing in a voice
  note routinely turns out to be spelled nothing like it. Confirm the spelling against
  the invite domain before spending an hour researching a company that is not the one
  you are meeting.

## Rules

- MUST treat research as read-only. Viewing a profile is fine. Connecting, messaging,
  commenting or reacting while researching is not.
- MUST confirm the company from the invite domain before researching.
- MUST cite the source and date on every historical claim in the brief.
- MUST extend an existing brief rather than writing a second one for the same meeting.
  Two briefs disagree, and the reader cannot tell which is current.
- NEVER send anything during prep. Drafts only, and only when drafting was explicitly
  part of the ask.
- NEVER present an inference as history. If the CRM does not say it happened, it goes
  in the open questions section, not the timeline.

# The brief template

One page. Same order every time. The order matters: it runs from what you cannot
change (who they are) to what you control (the ask), so the last thing you read before
walking in is the thing you are trying to do.

```
WHO       Name, role, tenure in that role, how you are connected, how they got here.
          One line on what they talk about publicly.

COMPANY   What they sell, to whom, size, structure. Only what changes how you sell.
          Skip the founding story.

HISTORY   Every prior touch, dated, most recent first. Who initiated. What was
          actually said, quoted where it matters. Cite the source on each line.

OPEN      Commitments you made in writing and have not delivered.
          Questions they asked that were never answered.
          This section is why the brief exists.

ANGLE     The one specific reason this conversation matters to them this quarter,
          traceable to something they said or something that changed.

ASK       The single outcome you want from this call. One sentence.

RISKS     What could go wrong. The objection you expect, phrased the way they will
          phrase it, with your answer.
```

## Section notes

**HISTORY** is where briefs rot. "Discussed pricing in March" is not history, it is a
label. "Said the budget sits with the CFO and would not move before the fiscal year
turns (call, 12 March)" is history, because it tells you what to do next.

**OPEN** outranks every other section. An unanswered question from six weeks ago is
the most expensive thing in the relationship, and it is the thing the other person
remembers most clearly.

**ANGLE** fails the portability test more often than not. Write it, then ask whether
it would survive being pasted into a brief for their closest competitor. If it would,
it is not an angle yet.

**RISKS** is written before you want to hear it. An objection you predicted is a
conversation. The same objection unpredicted is a stall, because you will improvise.

## Length discipline

One page. If HISTORY is running long, cut the oldest touches rather than compressing
the recent ones - a brief that summarises 14 months evenly is less useful than one
that covers the last two touches precisely.

---
name: meeting-prep
title: Meeting prep brief
description: |
  Use this skill before any external meeting - discovery, demo, renewal, partner
  call. Fires on "prep me", "who am I meeting", "research this account before the
  call", "what do I need to know for tomorrow", or a named upcoming meeting.
  Produces a brief that makes you the best-informed person in the room, built from
  the CRM, the thread history, past call transcripts and public research.
category: Research
tags: [Sales]
---

The brief's job is to make you the best-informed person on the call within two hours'
notice. A company summary is not a brief. Anyone can produce a company summary.

## The play

1. **Resolve the target from the calendar, not from memory.** Take the next event with
   an external attendee. The email domain on the invite is ground truth for the
   company. The public profile is ground truth for the person's name.
2. **Gather in parallel.** CRM history, thread history, past call transcripts, public
   profile and recent posts, and company research. These are independent, so running
   them in sequence wastes the window you have.
3. **Read the last transcript in full before anything else.** What they said in their
   own words outranks everything you will find on the web.
4. **Find the angle.** One specific reason this conversation matters to them this
   quarter, traceable to something they said or something that changed at their
   company.
5. **Write it to the template.** Structure in `references/brief-template.md`. Same
   shape every time, so it can be read in the four minutes before a call.
6. **File it against the account record and link it.** A brief you cannot find 20
   minutes before the call did not exist.

## What good looks like

- **The expert's tell: mine the commitments, not the facts.** What did you promise in
  writing and not deliver? What did they ask that never got answered? Those two lists
  determine the first 90 seconds of the call, and neither of them lives in a company
  profile. They live in the thread and the last transcript.
- **The mediocre version is a research dump.** Funding history, headcount, a summary
  of the website, and no reason for the meeting to happen. It reads as thorough and
  changes nothing about how the call goes.
- **Test the angle by portability.** If the ANGLE section could be pasted into a brief
  for a different company in the same sector, it is not an angle, it is a description.
  Go back to the transcripts and find the sentence only this person said.
- **Concretely good:** one page, readable in four minutes, every claim traceable to a
  source, a named ask for this specific call, and the objection you expect written out
  before you hear it.
- **Names heard out loud are unreliable.** A company heard as one thing in a voice
  note routinely turns out to be spelled nothing like it. Confirm the spelling against
  the invite domain before spending an hour researching a company that is not the one
  you are meeting.

## Rules

- MUST treat research as read-only. Viewing a profile is fine. Connecting, messaging,
  commenting or reacting while researching is not.
- MUST confirm the company from the invite domain before researching.
- MUST cite the source and date on every historical claim in the brief.
- MUST extend an existing brief rather than writing a second one for the same meeting.
  Two briefs disagree, and the reader cannot tell which is current.
- NEVER send anything during prep. Drafts only, and only when drafting was explicitly
  part of the ask.
- NEVER present an inference as history. If the CRM does not say it happened, it goes
  in the open questions section, not the timeline.

# The brief template

One page. Same order every time. The order matters: it runs from what you cannot
change (who they are) to what you control (the ask), so the last thing you read before
walking in is the thing you are trying to do.

```
WHO       Name, role, tenure in that role, how you are connected, how they got here.
          One line on what they talk about publicly.

COMPANY   What they sell, to whom, size, structure. Only what changes how you sell.
          Skip the founding story.

HISTORY   Every prior touch, dated, most recent first. Who initiated. What was
          actually said, quoted where it matters. Cite the source on each line.

OPEN      Commitments you made in writing and have not delivered.
          Questions they asked that were never answered.
          This section is why the brief exists.

ANGLE     The one specific reason this conversation matters to them this quarter,
          traceable to something they said or something that changed.

ASK       The single outcome you want from this call. One sentence.

RISKS     What could go wrong. The objection you expect, phrased the way they will
          phrase it, with your answer.
```

## Section notes

**HISTORY** is where briefs rot. "Discussed pricing in March" is not history, it is a
label. "Said the budget sits with the CFO and would not move before the fiscal year
turns (call, 12 March)" is history, because it tells you what to do next.

**OPEN** outranks every other section. An unanswered question from six weeks ago is
the most expensive thing in the relationship, and it is the thing the other person
remembers most clearly.

**ANGLE** fails the portability test more often than not. Write it, then ask whether
it would survive being pasted into a brief for their closest competitor. If it would,
it is not an angle yet.

**RISKS** is written before you want to hear it. An objection you predicted is a
conversation. The same objection unpredicted is a stall, because you will improvise.

## Length discipline

One page. If HISTORY is running long, cut the oldest touches rather than compressing
the recent ones - a brief that summarises 14 months evenly is less useful than one
that covers the last two touches precisely.

Newsletters3 files

Warming newsletter cadence

One call becomes five issues the lead actually reads.

The tell

The expert's tell: it is not addressed to the reader. No greeting, no reference to the call, no second person. It reads like a company magazine that happens to be about their exact problem. The moment it says "as we discussed", it becomes an automated follow-up and the reader files it as one.

---
name: newsletter-cadence
title: Warming newsletter cadence
description: |
  Use this skill after a first meeting that will not close this month - the deal is
  real, the timing is not. Fires on "build a warming cadence for this lead", "keep
  this account warm", "write a nurture sequence", "add another issue", "rewrite this
  issue". Produces a branded 3 to 5 issue newsletter to one lead, sitting as drafts
  until a human approves each one.
category: Newsletters
tags: [Sales, Marketing]
---

One conversation becomes a short newsletter the lead cannot tell from a hand-written
one. Nothing sends without a human click.

## The play

1. **Mine the transcript for pains, in their words.** The pains decide every topic. No
   pains, no cadence, go back to the transcript.
2. **Map one pain per issue and space them to land before the next meeting.** The last
   issue arrives days before you speak again, so the conversation resumes mid-thought
   rather than cold.
3. **Write the copy as data, not as a document.** Each issue is a structured record:
   subject, preheader, title, two paragraphs, one card, a tie line to the next issue,
   one image. The rendered file is an artifact, regenerated, never hand-edited.
4. **Follow the editorial rules exactly.** They are in `references/editorial-rules.md`
   and they are the whole difference between this and a template blast.
5. **Queue everything as a draft, and check it against the gates** in
   `references/qa-gates.md` before a human is asked to look.
6. **A human approves each issue and sends.** Every send writes back to the account
   record, so replies land on the same timeline as everything else.

## What good looks like

- **The expert's tell: it is not addressed to the reader.** No greeting, no reference
  to the call, no second person. It reads like a company magazine that happens to be
  about their exact problem. The moment it says "as we discussed", it becomes an
  automated follow-up and the reader files it as one.
- **Personalization is topic selection and image selection, not merge fields.** Their
  pain decides what the issue is about and what sits on top of it. The body then
  treats that pain as a general phenomenon in their sector. This is what makes it
  forwardable inside their company, and forwarding is the actual goal.
- **The mediocre version is a nurture sequence with the lead's first name in it.**
  Every recipient can tell. The first name is the tell.
- **Concretely good:** two paragraphs, 50 to 65 words total, paragraph one the pain
  stated sharply, paragraph two what gets done about it and the concrete result. Every
  issue ends on a hook or a soft next step. If an issue runs long, it is because the
  pain was not understood well enough to state briefly.
- **Reply rate is the metric.** Opens measure the subject line. Replies measure
  whether the thing was worth writing.

## Rules

- MUST derive every topic from something the lead actually said.
- MUST keep copy in the structured record. Regenerate the rendered file from it.
- MUST leave every issue as a draft until a human approves it.
- MUST reset an approved issue to draft before changing its copy, so approval always
  refers to the content that ships.
- NEVER address the reader, name the call, or use a greeting.
- NEVER send on a schedule without a human in the loop. A cadence that sends itself
  will eventually send issue three to someone who replied to issue two.

# Editorial rules

These are the rules that decide whether the lead reads it as a publication or as
marketing automation. They are stricter than they look, and every one of them exists
because breaking it produced something that read as generated.

## Voice and address

- **No greeting.** The body opens on the pain. The signature is a name and a title.
- **Never address the reader.** No second person aimed at them, no "you mentioned",
  no "as we agreed", no "what came up in our session". These are banned outright.
- **Never reference the meeting** except, optionally, in the closing tie line or the
  call to action. Everywhere else it breaks the publication frame.
- **Write in the register of a trade publication**, not a sales email. The subject is
  the problem, treated seriously, as a phenomenon in their sector.

## Shape

Two paragraphs. 50 to 65 words in total. This is a hard constraint and it is the
constraint that does the most work.

- **Paragraph one: the pain, stated sharply.** A hook question is good. It should be
  uncomfortable to read if you have that problem.
- **Paragraph two: what gets done about it in practice, and the concrete result.**
  Practice, not capability. A number if there is a real one.
- **Lead with the point, then the reason.** Not the other way round.
- **End on a curiosity hook or a soft next step.** Every issue earns the next one.

## Banned language

Hedging kills the register instantly: "we would be happy if you considered", "it might
be worth exploring", "please do not hesitate". Say the thing.

These read as machine-written and get cut on sight: em dashes, the "it's not X, it's
Y" construction, rhetorical triads, "moreover", "it is important to note", "there is
no doubt", "let us dive in", colon-labels inside body text, empty superlatives, and
paragraphs of suspiciously equal length.

## The voice file

Build one before the first issue by sampling real sent mail and existing public copy.
Capture sentence length, punctuation habits, how sentences close, which terms stay in
their original language, and how experience gets used as an argument.

This single file is the highest-leverage artifact in the whole play. Without it, the
output is competent and anonymous, and anonymous is the failure mode.

## Images

One image per issue, chosen for the reader's world first and the issue's topic second.
An arena photo for a sports organisation, a warehouse for a distributor. Then match
the topic on top of that.

Always render the issue and look at the image before it ships. An image URL that
claims to be one thing is regularly another, and nobody catches it by reading code.

# QA gates

Run all of them before a human is asked to review. A human reviewing an issue that
fails a mechanical gate learns that review is your job, not theirs, and starts
approving without reading. That is how an unreviewed issue eventually ships.

## Mechanical gates

| Gate | Pass condition | Failure mode it catches |
|---|---|---|
| Em dashes | Zero across every rendered issue | The single most reliable machine-written tell |
| Personal address | Zero greetings, zero call references, zero second person aimed at the reader | The issue reads as an automated follow-up |
| Word count | Body between 50 and 65 words | Padding, which means the pain was not understood |
| Image present | Exactly one per issue | A broken issue that still renders |
| Queue status | Every issue sits as a draft | Something is set up to send itself |
| Banned phrases | Zero hits from the banned list | Generated register |

## The gate that needs eyes

Render at least one issue and look at it. Not the HTML, the rendered result.

A build that passes every automated check and still ships a broken layout, a wrong
image, or an unstyled fallback is the normal outcome of trusting checks alone. The
image is the usual offender: a URL described as one subject turns out to be another,
and no text-based check will ever catch it.

## Before handing to a human

State the check results explicitly rather than saying it is ready. "Five issues, all
gates pass, image on issue three replaced after review" gives the reviewer somewhere
to start. "Ready for review" gives them nothing and gets a slower, worse review.

## After approval

Approved issues are write-protected. To change copy after approval, reset the issue to
draft and re-seed it, so approval always refers to the exact content that will ship.
Silently editing approved copy means the human approved something that never sent.

---
name: newsletter-cadence
title: Warming newsletter cadence
description: |
  Use this skill after a first meeting that will not close this month - the deal is
  real, the timing is not. Fires on "build a warming cadence for this lead", "keep
  this account warm", "write a nurture sequence", "add another issue", "rewrite this
  issue". Produces a branded 3 to 5 issue newsletter to one lead, sitting as drafts
  until a human approves each one.
category: Newsletters
tags: [Sales, Marketing]
---

One conversation becomes a short newsletter the lead cannot tell from a hand-written
one. Nothing sends without a human click.

## The play

1. **Mine the transcript for pains, in their words.** The pains decide every topic. No
   pains, no cadence, go back to the transcript.
2. **Map one pain per issue and space them to land before the next meeting.** The last
   issue arrives days before you speak again, so the conversation resumes mid-thought
   rather than cold.
3. **Write the copy as data, not as a document.** Each issue is a structured record:
   subject, preheader, title, two paragraphs, one card, a tie line to the next issue,
   one image. The rendered file is an artifact, regenerated, never hand-edited.
4. **Follow the editorial rules exactly.** They are in `references/editorial-rules.md`
   and they are the whole difference between this and a template blast.
5. **Queue everything as a draft, and check it against the gates** in
   `references/qa-gates.md` before a human is asked to look.
6. **A human approves each issue and sends.** Every send writes back to the account
   record, so replies land on the same timeline as everything else.

## What good looks like

- **The expert's tell: it is not addressed to the reader.** No greeting, no reference
  to the call, no second person. It reads like a company magazine that happens to be
  about their exact problem. The moment it says "as we discussed", it becomes an
  automated follow-up and the reader files it as one.
- **Personalization is topic selection and image selection, not merge fields.** Their
  pain decides what the issue is about and what sits on top of it. The body then
  treats that pain as a general phenomenon in their sector. This is what makes it
  forwardable inside their company, and forwarding is the actual goal.
- **The mediocre version is a nurture sequence with the lead's first name in it.**
  Every recipient can tell. The first name is the tell.
- **Concretely good:** two paragraphs, 50 to 65 words total, paragraph one the pain
  stated sharply, paragraph two what gets done about it and the concrete result. Every
  issue ends on a hook or a soft next step. If an issue runs long, it is because the
  pain was not understood well enough to state briefly.
- **Reply rate is the metric.** Opens measure the subject line. Replies measure
  whether the thing was worth writing.

## Rules

- MUST derive every topic from something the lead actually said.
- MUST keep copy in the structured record. Regenerate the rendered file from it.
- MUST leave every issue as a draft until a human approves it.
- MUST reset an approved issue to draft before changing its copy, so approval always
  refers to the content that ships.
- NEVER address the reader, name the call, or use a greeting.
- NEVER send on a schedule without a human in the loop. A cadence that sends itself
  will eventually send issue three to someone who replied to issue two.

# Editorial rules

These are the rules that decide whether the lead reads it as a publication or as
marketing automation. They are stricter than they look, and every one of them exists
because breaking it produced something that read as generated.

## Voice and address

- **No greeting.** The body opens on the pain. The signature is a name and a title.
- **Never address the reader.** No second person aimed at them, no "you mentioned",
  no "as we agreed", no "what came up in our session". These are banned outright.
- **Never reference the meeting** except, optionally, in the closing tie line or the
  call to action. Everywhere else it breaks the publication frame.
- **Write in the register of a trade publication**, not a sales email. The subject is
  the problem, treated seriously, as a phenomenon in their sector.

## Shape

Two paragraphs. 50 to 65 words in total. This is a hard constraint and it is the
constraint that does the most work.

- **Paragraph one: the pain, stated sharply.** A hook question is good. It should be
  uncomfortable to read if you have that problem.
- **Paragraph two: what gets done about it in practice, and the concrete result.**
  Practice, not capability. A number if there is a real one.
- **Lead with the point, then the reason.** Not the other way round.
- **End on a curiosity hook or a soft next step.** Every issue earns the next one.

## Banned language

Hedging kills the register instantly: "we would be happy if you considered", "it might
be worth exploring", "please do not hesitate". Say the thing.

These read as machine-written and get cut on sight: em dashes, the "it's not X, it's
Y" construction, rhetorical triads, "moreover", "it is important to note", "there is
no doubt", "let us dive in", colon-labels inside body text, empty superlatives, and
paragraphs of suspiciously equal length.

## The voice file

Build one before the first issue by sampling real sent mail and existing public copy.
Capture sentence length, punctuation habits, how sentences close, which terms stay in
their original language, and how experience gets used as an argument.

This single file is the highest-leverage artifact in the whole play. Without it, the
output is competent and anonymous, and anonymous is the failure mode.

## Images

One image per issue, chosen for the reader's world first and the issue's topic second.
An arena photo for a sports organisation, a warehouse for a distributor. Then match
the topic on top of that.

Always render the issue and look at the image before it ships. An image URL that
claims to be one thing is regularly another, and nobody catches it by reading code.

# QA gates

Run all of them before a human is asked to review. A human reviewing an issue that
fails a mechanical gate learns that review is your job, not theirs, and starts
approving without reading. That is how an unreviewed issue eventually ships.

## Mechanical gates

| Gate | Pass condition | Failure mode it catches |
|---|---|---|
| Em dashes | Zero across every rendered issue | The single most reliable machine-written tell |
| Personal address | Zero greetings, zero call references, zero second person aimed at the reader | The issue reads as an automated follow-up |
| Word count | Body between 50 and 65 words | Padding, which means the pain was not understood |
| Image present | Exactly one per issue | A broken issue that still renders |
| Queue status | Every issue sits as a draft | Something is set up to send itself |
| Banned phrases | Zero hits from the banned list | Generated register |

## The gate that needs eyes

Render at least one issue and look at it. Not the HTML, the rendered result.

A build that passes every automated check and still ships a broken layout, a wrong
image, or an unstyled fallback is the normal outcome of trusting checks alone. The
image is the usual offender: a URL described as one subject turns out to be another,
and no text-based check will ever catch it.

## Before handing to a human

State the check results explicitly rather than saying it is ready. "Five issues, all
gates pass, image on issue three replaced after review" gives the reviewer somewhere
to start. "Ready for review" gives them nothing and gets a slower, worse review.

## After approval

Approved issues are write-protected. To change copy after approval, reset the issue to
draft and re-seed it, so approval always refers to the exact content that will ship.
Silently editing approved copy means the human approved something that never sent.

Outreach2 files

Approved posts into LinkedIn drafts

Approved posts into real drafts. Never published by a machine.

The tell

The expert's tell: verify the tail of the post, not the head. Truncation always looks fine at the top. A batch that was never read back produces six drafts that all end mid-sentence, and the person publishing them finds out in public.

---
name: linkedin-drafts
title: Approved posts into LinkedIn drafts
description: |
  Use this skill when written content needs to reach LinkedIn without being
  published by a machine. Fires on "put my posts in LinkedIn", "push these to
  drafts", "move the approved content over", "queue my posts for the week".
  Produces real LinkedIn drafts, verified, waiting for a person to press post.
category: Outreach
tags: [Marketing]
---

LinkedIn has no drafts API, so this runs through the browser. The finish line is a
draft in the account, never a published post.

## The play

1. **Take approved items only.** If nothing is approved, stop and say so. Pushing
   drafts of unapproved copy creates work rather than removing it.
2. **Confirm the language set.** Content written in two languages is two separate
   posts with separate reasoning, not one post and its translation. Ask which ones
   before starting.
3. **Open the composer prefilled** with the post body, one post at a time.
4. **Read the composer back before saving.** Long posts get silently truncated by
   prefill. Verify the last line of the post is present, then paste the remainder by
   hand if it is not.
5. **Close the composer and take the save-as-draft option.** The publish control is
   not part of this play at all.
6. **Stop the run on any platform warning.** Checkpoints, captchas and unusual
   activity notices all mean hand back to a human. The full list of what goes wrong
   and how it presents is in `references/failure-modes.md`.
7. **Report one line per item, and leave the status as approved.** A draft is not a
   published post, and marking it as one loses the account's real publishing record.

## What good looks like

- **The expert's tell: verify the tail of the post, not the head.** Truncation
  always looks fine at the top. A batch that was never read back produces six drafts
  that all end mid-sentence, and the person publishing them finds out in public.
- **The mediocre version batches everything for speed.** It saves ten minutes and
  costs an hour of repair, because a failure in step three is invisible until every
  draft carries it.
- **Concretely good:** one post at a time, each read back in full before the next,
  attachments flagged explicitly because they cannot ride the prefill, and a report
  the person can act on without opening LinkedIn to check your work.
- **Keep the pace human even when nothing is complaining.** Slower loads, unexpected
  redirects and a composer that opens empty are the signals that precede a checkpoint.
  Stopping on those costs an afternoon. Ignoring them costs the account.
- **Any automation warning ends the run.** A checkpoint, a captcha, or an unusual
  activity notice means stop and hand back to a human immediately. No content calendar
  is worth a restricted account, and the restriction lands on the person, not on you.

## Rules

- MUST verify the full text in the composer before saving each draft.
- MUST handle one post at a time.
- MUST name any attachment that could not be carried, so it gets added by hand.
- NEVER press publish. Not once, not on a test, not to check the layout.
- NEVER continue past a checkpoint, captcha or automation warning.
- NEVER mark an item as posted. A draft is not a post.

# Failure modes

Every one of these has happened. They are ordered by how expensive they are to
discover late.

## Truncation

Prefilling a composer through a URL has a length limit that nobody documents and that
changes without notice. Past it, the text is cut silently: the composer opens, the
post looks right, and the last two paragraphs are gone.

It always looks correct at the top, which is why reading the first line back proves
nothing. **Verify the final sentence of the post specifically.** If it is missing,
paste the remainder by hand before saving, then verify again.

## The batch trap

Pushing ten posts before checking any of them turns one failure into ten. Because
truncation is systematic rather than random, a batch usually fails identically across
every item, and the discovery happens when someone publishes one in public.

One at a time, verified before the next. The time saved by batching is smaller than
the time spent repairing a single published mistake.

## Checkpoints and automation warnings

A checkpoint, a captcha, an unusual-activity notice, or a sudden re-login demand all
mean the same thing: stop the run and hand back to a human.

Continuing past one risks a restriction on the account, and the restriction lands on
the person whose name is on the profile, not on the automation that caused it. There
is no content calendar worth that trade. Report where the run stopped and which items
remain, so it can be picked up by hand.

## Attachments

Documents, carousels and images cannot ride a prefilled URL. A draft that was supposed
to carry a carousel and does not is worse than no draft, because it looks finished.

Name every item whose attachment could not be carried, in the report, per item. Do not
bury it in a summary line.

## Status drift

Marking an item as posted when it is only drafted corrupts the publishing record. The
next run then skips it, the post never goes out, and the gap is invisible because the
system believes it already shipped.

A draft is not a post. The item's status stays exactly where it was.

## Rate

Even without a warning, keep the pace human. Space the pushes rather than firing them
back to back, and stop for the day if the platform starts behaving differently -
slower loads, unexpected redirects, a composer that opens empty. Those are the early
signals that precede a checkpoint, and stopping on them costs one afternoon instead of
one account.

---
name: linkedin-drafts
title: Approved posts into LinkedIn drafts
description: |
  Use this skill when written content needs to reach LinkedIn without being
  published by a machine. Fires on "put my posts in LinkedIn", "push these to
  drafts", "move the approved content over", "queue my posts for the week".
  Produces real LinkedIn drafts, verified, waiting for a person to press post.
category: Outreach
tags: [Marketing]
---

LinkedIn has no drafts API, so this runs through the browser. The finish line is a
draft in the account, never a published post.

## The play

1. **Take approved items only.** If nothing is approved, stop and say so. Pushing
   drafts of unapproved copy creates work rather than removing it.
2. **Confirm the language set.** Content written in two languages is two separate
   posts with separate reasoning, not one post and its translation. Ask which ones
   before starting.
3. **Open the composer prefilled** with the post body, one post at a time.
4. **Read the composer back before saving.** Long posts get silently truncated by
   prefill. Verify the last line of the post is present, then paste the remainder by
   hand if it is not.
5. **Close the composer and take the save-as-draft option.** The publish control is
   not part of this play at all.
6. **Stop the run on any platform warning.** Checkpoints, captchas and unusual
   activity notices all mean hand back to a human. The full list of what goes wrong
   and how it presents is in `references/failure-modes.md`.
7. **Report one line per item, and leave the status as approved.** A draft is not a
   published post, and marking it as one loses the account's real publishing record.

## What good looks like

- **The expert's tell: verify the tail of the post, not the head.** Truncation
  always looks fine at the top. A batch that was never read back produces six drafts
  that all end mid-sentence, and the person publishing them finds out in public.
- **The mediocre version batches everything for speed.** It saves ten minutes and
  costs an hour of repair, because a failure in step three is invisible until every
  draft carries it.
- **Concretely good:** one post at a time, each read back in full before the next,
  attachments flagged explicitly because they cannot ride the prefill, and a report
  the person can act on without opening LinkedIn to check your work.
- **Keep the pace human even when nothing is complaining.** Slower loads, unexpected
  redirects and a composer that opens empty are the signals that precede a checkpoint.
  Stopping on those costs an afternoon. Ignoring them costs the account.
- **Any automation warning ends the run.** A checkpoint, a captcha, or an unusual
  activity notice means stop and hand back to a human immediately. No content calendar
  is worth a restricted account, and the restriction lands on the person, not on you.

## Rules

- MUST verify the full text in the composer before saving each draft.
- MUST handle one post at a time.
- MUST name any attachment that could not be carried, so it gets added by hand.
- NEVER press publish. Not once, not on a test, not to check the layout.
- NEVER continue past a checkpoint, captcha or automation warning.
- NEVER mark an item as posted. A draft is not a post.

# Failure modes

Every one of these has happened. They are ordered by how expensive they are to
discover late.

## Truncation

Prefilling a composer through a URL has a length limit that nobody documents and that
changes without notice. Past it, the text is cut silently: the composer opens, the
post looks right, and the last two paragraphs are gone.

It always looks correct at the top, which is why reading the first line back proves
nothing. **Verify the final sentence of the post specifically.** If it is missing,
paste the remainder by hand before saving, then verify again.

## The batch trap

Pushing ten posts before checking any of them turns one failure into ten. Because
truncation is systematic rather than random, a batch usually fails identically across
every item, and the discovery happens when someone publishes one in public.

One at a time, verified before the next. The time saved by batching is smaller than
the time spent repairing a single published mistake.

## Checkpoints and automation warnings

A checkpoint, a captcha, an unusual-activity notice, or a sudden re-login demand all
mean the same thing: stop the run and hand back to a human.

Continuing past one risks a restriction on the account, and the restriction lands on
the person whose name is on the profile, not on the automation that caused it. There
is no content calendar worth that trade. Report where the run stopped and which items
remain, so it can be picked up by hand.

## Attachments

Documents, carousels and images cannot ride a prefilled URL. A draft that was supposed
to carry a carousel and does not is worse than no draft, because it looks finished.

Name every item whose attachment could not be carried, in the report, per item. Do not
bury it in a summary line.

## Status drift

Marking an item as posted when it is only drafted corrupts the publishing record. The
next run then skips it, the post never goes out, and the gap is invisible because the
system believes it already shipped.

A draft is not a post. The item's status stays exactly where it was.

## Rate

Even without a warning, keep the pace human. Space the pushes rather than firing them
back to back, and stop for the day if the platform starts behaving differently -
slower loads, unexpected redirects, a composer that opens empty. Those are the early
signals that precede a checkpoint, and stopping on them costs one afternoon instead of
one account.

Research2 files

Multi-document synthesis

Read all of it. Surface the contradictions, not the average.

The tell

The expert's tell: dates are evidence, not metadata. Two sources disagreeing is not a conflict until you know which came later. Sequence resolves most apparent contradictions and turns the rest into real findings.

---
name: doc-synthesis
title: Multi-document synthesis
description: |
  Use this skill when the answer is spread across several sources - call
  transcripts, email threads, proposals, meeting notes, status reports. Fires on
  "read these and tell me what is going on", "catch me up on this account",
  "summarize these", "what did we actually agree", "reconcile these versions".
  Produces a brief where every claim is traceable and the contradictions are the
  headline.
category: Research
tags: [Sales, RevOps]
---

A synthesis is trustworthy only if every claim traces to a source and the sources'
disagreements survive the summary. That is the whole game.

## The play

1. **Inventory the sources first**, with dates, so "all of them" has a definition and
   a missing source is visible.
2. **Read each one fully.** The load-bearing sentence is usually a one-line aside in
   the middle. Skimming is precisely how a synthesis misses it.
3. **Attach a source and a date to every fact you carry forward.** This is what lets
   a reader challenge one line without re-reading everything.
4. **Hunt contradictions actively.** Different numbers, different dates, different
   owners, a decision one source treats as open and another treats as closed.
5. **Separate decided from proposed from open.** Sources blur these constantly and
   the synthesis must not.
6. **Check what is missing from the pile.** A thread that stops mid-negotiation, a
   proposal with no reply on record, a meeting everyone references and nobody
   recorded. Absent sources change the reading and belong in the brief.
7. **Write to the shape** in `references/output-shapes.md`, and keep the conflicts
   section even when it is empty.

## What good looks like

- **The expert's tell: dates are evidence, not metadata.** Two sources disagreeing is
  not a conflict until you know which came later. Sequence resolves most apparent
  contradictions and turns the rest into real findings.
- **The mediocre version averages.** It sees two numbers, picks the middle or the more
  recent without saying so, and produces a clean document that quietly destroyed the
  most important information in the pile.
- **Contradictions are the product, not a caveat.** A reader can summarize their own
  documents. What they cannot do quickly is notice that the proposal says one figure
  and the last call said another. Lead with that.
- **Concretely good:** a reader can challenge any line by opening one named source,
  every conflict shows both values with both sources, and the open questions section
  is specific enough to act on this week.
- **The open questions list usually outranks the summary.** It is the part that
  changes what someone does tomorrow.
- **Length is a quality signal.** A synthesis of eight documents that runs longer than
  two pages has not synthesized anything. If it will not compress, the contradictions
  have not been resolved yet, and resolving them is the work.

## Rules

- MUST cite a source and date on every load-bearing claim.
- MUST show both values when sources conflict, and name which is later.
- MUST state supersession explicitly when a later source overrides an earlier one.
- MUST mark each item as decided, proposed or open, and say where a decision was made.
- NEVER silently pick a side, average two figures, or drop the outlier.
- NEVER present a conclusion the sources do not support because it makes the brief
  read as more finished.

# Output shapes

Default to the account brief. Switch shapes only when the reader asked for something
specific, and keep the conflicts section in all of them.

## Account brief (default)

```
# [Account or topic] - brief
## TL;DR                       3 to 5 sentences. The state of things
## Decisions                   each with source and date
## Open questions & conflicts  both values, both sources, which is later
## Next actions                owner and date where a source names one
## Sources                     every document read, with its date
```

## Deal reconciliation

When the question is "what did we actually commit to", the shape changes: commitments
first, everything else second.

```
## Committed in writing     the exact wording, source, date
## Committed verbally       from transcripts, quoted
## Contradicted             where written and verbal disagree
## Never answered           their questions with no response on record
## Exposure                 what is owed and not delivered
```

The "never answered" section is routinely the most valuable thing produced, and it
appears in no source document. It only exists in the gaps between them.

## Catch-up digest

For "what happened while I was out", order by consequence rather than chronology:

```
## Needs you                decisions blocked on this reader
## Changed                  what moved, with before and after
## Noise                    everything else, one line each
```

## Length discipline

The synthesis is shorter than the sources or it has failed at its only job. If it is
running long, cut the noise section, never the conflicts.

## The sources section

Always include it, even when it feels like padding. It is what makes the brief
auditable, and it exposes the gap that matters most: a source everyone assumed was
read and was not.

---
name: doc-synthesis
title: Multi-document synthesis
description: |
  Use this skill when the answer is spread across several sources - call
  transcripts, email threads, proposals, meeting notes, status reports. Fires on
  "read these and tell me what is going on", "catch me up on this account",
  "summarize these", "what did we actually agree", "reconcile these versions".
  Produces a brief where every claim is traceable and the contradictions are the
  headline.
category: Research
tags: [Sales, RevOps]
---

A synthesis is trustworthy only if every claim traces to a source and the sources'
disagreements survive the summary. That is the whole game.

## The play

1. **Inventory the sources first**, with dates, so "all of them" has a definition and
   a missing source is visible.
2. **Read each one fully.** The load-bearing sentence is usually a one-line aside in
   the middle. Skimming is precisely how a synthesis misses it.
3. **Attach a source and a date to every fact you carry forward.** This is what lets
   a reader challenge one line without re-reading everything.
4. **Hunt contradictions actively.** Different numbers, different dates, different
   owners, a decision one source treats as open and another treats as closed.
5. **Separate decided from proposed from open.** Sources blur these constantly and
   the synthesis must not.
6. **Check what is missing from the pile.** A thread that stops mid-negotiation, a
   proposal with no reply on record, a meeting everyone references and nobody
   recorded. Absent sources change the reading and belong in the brief.
7. **Write to the shape** in `references/output-shapes.md`, and keep the conflicts
   section even when it is empty.

## What good looks like

- **The expert's tell: dates are evidence, not metadata.** Two sources disagreeing is
  not a conflict until you know which came later. Sequence resolves most apparent
  contradictions and turns the rest into real findings.
- **The mediocre version averages.** It sees two numbers, picks the middle or the more
  recent without saying so, and produces a clean document that quietly destroyed the
  most important information in the pile.
- **Contradictions are the product, not a caveat.** A reader can summarize their own
  documents. What they cannot do quickly is notice that the proposal says one figure
  and the last call said another. Lead with that.
- **Concretely good:** a reader can challenge any line by opening one named source,
  every conflict shows both values with both sources, and the open questions section
  is specific enough to act on this week.
- **The open questions list usually outranks the summary.** It is the part that
  changes what someone does tomorrow.
- **Length is a quality signal.** A synthesis of eight documents that runs longer than
  two pages has not synthesized anything. If it will not compress, the contradictions
  have not been resolved yet, and resolving them is the work.

## Rules

- MUST cite a source and date on every load-bearing claim.
- MUST show both values when sources conflict, and name which is later.
- MUST state supersession explicitly when a later source overrides an earlier one.
- MUST mark each item as decided, proposed or open, and say where a decision was made.
- NEVER silently pick a side, average two figures, or drop the outlier.
- NEVER present a conclusion the sources do not support because it makes the brief
  read as more finished.

# Output shapes

Default to the account brief. Switch shapes only when the reader asked for something
specific, and keep the conflicts section in all of them.

## Account brief (default)

```
# [Account or topic] - brief
## TL;DR                       3 to 5 sentences. The state of things
## Decisions                   each with source and date
## Open questions & conflicts  both values, both sources, which is later
## Next actions                owner and date where a source names one
## Sources                     every document read, with its date
```

## Deal reconciliation

When the question is "what did we actually commit to", the shape changes: commitments
first, everything else second.

```
## Committed in writing     the exact wording, source, date
## Committed verbally       from transcripts, quoted
## Contradicted             where written and verbal disagree
## Never answered           their questions with no response on record
## Exposure                 what is owed and not delivered
```

The "never answered" section is routinely the most valuable thing produced, and it
appears in no source document. It only exists in the gaps between them.

## Catch-up digest

For "what happened while I was out", order by consequence rather than chronology:

```
## Needs you                decisions blocked on this reader
## Changed                  what moved, with before and after
## Noise                    everything else, one line each
```

## Length discipline

The synthesis is shorter than the sources or it has failed at its only job. If it is
running long, cut the noise section, never the conflicts.

## The sources section

Always include it, even when it feels like padding. It is what makes the brief
auditable, and it exposes the gap that matters most: a source everyone assumed was
read and was not.

RevOps2 files

Fan out without gaps

Cover every account on the list, and prove that you did.

The tell

The expert's tell: the inventory comes before the delegation, always. If you do not know there are 14 accounts, you cannot notice that 11 came back. Everything else in this play is downstream of that one discipline.

---
name: orchestrate
title: Fan out without gaps
description: |
  Use this skill when work spans many accounts, files, documents or search angles -
  audits, sweeps, migrations, multi-source research. Fires on "audit all of these",
  "go through every account", "check everything in", "review the whole list",
  "across all of our". Produces one synthesized answer with coverage stated
  explicitly, not a pile of partial reports.
category: RevOps
tags: [RevOps, Leadership]
---

Broad work fails two ways: slices get silently skipped, and work runs in sequence that
could have run at once. This prevents both.

## The play

1. **Build the inventory first, with cheap tools.** A list, a query, a directory
   read. Write it down and number it. This list is the coverage contract for
   everything that follows.
2. **Partition by independence.** A good slice can be briefed with a scope and a
   question, and its answer does not change based on what another slice finds.
3. **Brief each worker self-contained.** Exact scope, the specific question, the
   return format, and what to return when the answer is not there. A worker cannot see
   your context, so anything not in the brief does not exist. Partition patterns and
   the four parts of a brief are in `references/briefing-workers.md`.
4. **Launch independent work together.** Staggering it forfeits the entire benefit.
   If B genuinely needs A's output, run a pipeline and say so rather than pretending.
5. **Reconcile results against the inventory.** Every numbered item accounted for.
   Anything that errored or came back vague gets a sharper brief and a retry.
6. **Synthesize into one answer**, ranked by what the reader has to act on.

## What good looks like

- **The expert's tell: the inventory comes before the delegation, always.** If you do
  not know there are 14 accounts, you cannot notice that 11 came back. Everything else
  in this play is downstream of that one discipline.
- **The mediocre version reports what it found and never says what it covered.**
  It reads as complete, and the reader has no way to tell that three accounts errored
  silently and were dropped.
- **Silent truncation is the worst failure mode of fan-out work**, worse than a slow
  run and worse than an error, because it produces confident output that is quietly
  incomplete. Bounds are fine. Unstated bounds are not.
- **Concretely good:** the output states "14 of 14 covered", or names what could not
  be covered and why. Duplicates are merged, findings are ranked by severity, and the
  reader is not handed 14 reports to read.
- **Report coverage in three buckets, never one.** Covered, failed and retried, and
  genuinely uncoverable with the reason. Collapsing those into a single number is how
  a gap disappears.
- **Match the machinery to the job.** A single known lookup needs no fan-out, and a
  14-part audit needs no heroic single pass. Both mistakes cost the same.

## Rules

- MUST write the inventory down before dispatching any work.
- MUST state coverage explicitly in the final output.
- MUST retry a failed or vague slice with a sharper brief before reporting.
- MUST say so out loud when a bound was applied: a cap, a sample, a top-N.
- NEVER report a partial sweep as a complete one.
- NEVER hand back concatenated reports as a synthesis. If the output is just the parts
  stapled together, the fan-out added time and nothing else.

# Briefing workers and reporting coverage

## Partition patterns

Pick the split where slices genuinely do not need each other's results.

| Pattern | Split by | Works when |
|---|---|---|
| By entity | account, company, record | Each answer is independent and comparable |
| By source | CRM, inbox, transcripts, public web | One question, many places to look |
| By dimension | correctness, risk, cost, coverage | One body of material, several lenses |
| By segment | tier, region, product line | The rule changes per segment and you need each read separately |

If two slices keep needing to talk to each other, the partition is wrong. Merge them
into one slice or run them as an ordered pipeline and say which it is.

## The brief

A worker sees its brief and nothing else. Anything left implicit does not exist. Every
brief carries four things:

1. **Scope.** Exactly what to look at, named. Not "the accounts", but which ones.
2. **Question.** One question, answerable. Two questions produce one vague answer.
3. **Return format.** State the shape: "a list of account: issue lines, nothing else".
   Unspecified format means you will spend the synthesis stage parsing prose.
4. **Bound.** What to do when the answer is not there. "Return NONE" beats a worker
   inventing something plausible to avoid an empty response.

The test: could someone with no context produce a useful answer from this brief alone?
If not, the brief is a note to yourself, not an instruction.

## Coverage reporting

Reconcile every returned answer against the numbered inventory before writing
anything. Three buckets, and all three get reported:

| Bucket | Meaning | Action |
|---|---|---|
| Covered | Answered against the question asked | Include in the synthesis |
| Failed | Errored, timed out, or came back vague | Retry once with a sharper brief |
| Uncoverable | Genuinely out of reach - no access, no data | Name it and why, in the output |

The final line of any fan-out states the count: "14 of 14 covered", or "12 of 14
covered, 2 named below and why". A report that never mentions coverage reads as
complete, and the reader has no way to know it was not.

## Bounds must be stated

Any cap, sample, or top-N applied along the way gets said out loud. "Reviewed the 20
largest accounts of 340" is honest and useful. The same work reported as "reviewed the
accounts" is a claim the reader will act on and should not.

## When not to fan out

A single known lookup needs no orchestration. Neither does work where every slice
depends on the previous answer. The overhead of briefing, dispatching and reconciling
is real, and on a small job it costs more than it returns.

---
name: orchestrate
title: Fan out without gaps
description: |
  Use this skill when work spans many accounts, files, documents or search angles -
  audits, sweeps, migrations, multi-source research. Fires on "audit all of these",
  "go through every account", "check everything in", "review the whole list",
  "across all of our". Produces one synthesized answer with coverage stated
  explicitly, not a pile of partial reports.
category: RevOps
tags: [RevOps, Leadership]
---

Broad work fails two ways: slices get silently skipped, and work runs in sequence that
could have run at once. This prevents both.

## The play

1. **Build the inventory first, with cheap tools.** A list, a query, a directory
   read. Write it down and number it. This list is the coverage contract for
   everything that follows.
2. **Partition by independence.** A good slice can be briefed with a scope and a
   question, and its answer does not change based on what another slice finds.
3. **Brief each worker self-contained.** Exact scope, the specific question, the
   return format, and what to return when the answer is not there. A worker cannot see
   your context, so anything not in the brief does not exist. Partition patterns and
   the four parts of a brief are in `references/briefing-workers.md`.
4. **Launch independent work together.** Staggering it forfeits the entire benefit.
   If B genuinely needs A's output, run a pipeline and say so rather than pretending.
5. **Reconcile results against the inventory.** Every numbered item accounted for.
   Anything that errored or came back vague gets a sharper brief and a retry.
6. **Synthesize into one answer**, ranked by what the reader has to act on.

## What good looks like

- **The expert's tell: the inventory comes before the delegation, always.** If you do
  not know there are 14 accounts, you cannot notice that 11 came back. Everything else
  in this play is downstream of that one discipline.
- **The mediocre version reports what it found and never says what it covered.**
  It reads as complete, and the reader has no way to tell that three accounts errored
  silently and were dropped.
- **Silent truncation is the worst failure mode of fan-out work**, worse than a slow
  run and worse than an error, because it produces confident output that is quietly
  incomplete. Bounds are fine. Unstated bounds are not.
- **Concretely good:** the output states "14 of 14 covered", or names what could not
  be covered and why. Duplicates are merged, findings are ranked by severity, and the
  reader is not handed 14 reports to read.
- **Report coverage in three buckets, never one.** Covered, failed and retried, and
  genuinely uncoverable with the reason. Collapsing those into a single number is how
  a gap disappears.
- **Match the machinery to the job.** A single known lookup needs no fan-out, and a
  14-part audit needs no heroic single pass. Both mistakes cost the same.

## Rules

- MUST write the inventory down before dispatching any work.
- MUST state coverage explicitly in the final output.
- MUST retry a failed or vague slice with a sharper brief before reporting.
- MUST say so out loud when a bound was applied: a cap, a sample, a top-N.
- NEVER report a partial sweep as a complete one.
- NEVER hand back concatenated reports as a synthesis. If the output is just the parts
  stapled together, the fan-out added time and nothing else.

# Briefing workers and reporting coverage

## Partition patterns

Pick the split where slices genuinely do not need each other's results.

| Pattern | Split by | Works when |
|---|---|---|
| By entity | account, company, record | Each answer is independent and comparable |
| By source | CRM, inbox, transcripts, public web | One question, many places to look |
| By dimension | correctness, risk, cost, coverage | One body of material, several lenses |
| By segment | tier, region, product line | The rule changes per segment and you need each read separately |

If two slices keep needing to talk to each other, the partition is wrong. Merge them
into one slice or run them as an ordered pipeline and say which it is.

## The brief

A worker sees its brief and nothing else. Anything left implicit does not exist. Every
brief carries four things:

1. **Scope.** Exactly what to look at, named. Not "the accounts", but which ones.
2. **Question.** One question, answerable. Two questions produce one vague answer.
3. **Return format.** State the shape: "a list of account: issue lines, nothing else".
   Unspecified format means you will spend the synthesis stage parsing prose.
4. **Bound.** What to do when the answer is not there. "Return NONE" beats a worker
   inventing something plausible to avoid an empty response.

The test: could someone with no context produce a useful answer from this brief alone?
If not, the brief is a note to yourself, not an instruction.

## Coverage reporting

Reconcile every returned answer against the numbered inventory before writing
anything. Three buckets, and all three get reported:

| Bucket | Meaning | Action |
|---|---|---|
| Covered | Answered against the question asked | Include in the synthesis |
| Failed | Errored, timed out, or came back vague | Retry once with a sharper brief |
| Uncoverable | Genuinely out of reach - no access, no data | Name it and why, in the output |

The final line of any fan-out states the count: "14 of 14 covered", or "12 of 14
covered, 2 named below and why". A report that never mentions coverage reads as
complete, and the reader has no way to know it was not.

## Bounds must be stated

Any cap, sample, or top-N applied along the way gets said out loud. "Reviewed the 20
largest accounts of 340" is honest and useful. The same work reported as "reviewed the
accounts" is a claim the reader will act on and should not.

## When not to fan out

A single known lookup needs no orchestration. Neither does work where every slice
depends on the previous answer. The overhead of briefing, dispatching and reconciling
is real, and on a small job it costs more than it returns.

The prompt

This is what gets copied.

Claude fetches the files, writes them into your skills folder, and reports what it installed. Nothing else to set up.

Install the Orchestra-labs GTM Skills library for me.
The manifest is at https://orchestra-labs.com/skills/index.json
Fetch every file it lists and write them under ~/.claude/skills/, one folder
per skill, keeping SKILL.md at the top and references/ underneath.
Then list what you installed and when each skill will fire.

One skill only? Hit Install on its card. No terminal? Files gives you the full text, each one tagged with its path.

What a skill is

A method, not a prompt.

Markdown with a name and a description. The agent reads the description and decides when it applies. Four things make one worth installing.

The play: The procedure, in plain GTM verbs. Runs on any stack.
What good looks like: What the best operator notices first. What the mediocre version looks like.

Rules: Hard MUST and NEVER lines. The ones that cost something.
References: Rubrics with real numbers, templates, traps.

Want these running on your systems?

A skill is the method. Wiring it into your CRM, inbox and calendar is the work. Bring the messiest part of your funnel.

Book a call →