> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reply.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Skill catalog
> All 18 Reply skills by pack — what each one does, when it triggers, its maturity, and the skills it builds on.
Every skill in [reply-skills](https://github.com/reply-team/reply-skills), grouped by the pack that
ships it. Install once and you get the whole pack — see [Install](/skills/overview#install).
Each skill's own frontmatter is the source of truth, and
[`INDEX.md`](https://github.com/reply-team/reply-skills/blob/main/INDEX.md) in the repo is generated
from it on every change. Treat the maturity levels below as a snapshot; `INDEX.md` is always current.
**Maturity levels:** `draft` — structurally complete, content plausible · `reviewed` — a maintainer or
domain expert signed off · `validated` — real executions confirmed the guidance · `production` —
safe to follow blindly.
## `ai-sdr-core` — 9 skills
Vendor-neutral SDR expertise: the business-operation contract, outbound strategy and playbooks, and
the guardrails that keep automated outreach safe. **The base pack** — every other pack builds on it,
and it carries no dependencies of its own.
### sdr-operations
*The vendor-neutral contract of atomic SDR business operations.*
Names each operation an SDR actually performs — add a contact, enrol it into a sequence, pause, reply,
classify a conversation, read engagement — in practitioner language with no provider detail. Every
other skill plans against these names, which is what lets a different provider adapter drop in without
rewriting the strategy layer. Ships an `references/operation-catalog.md` with the full operation list,
each one's effect, reversibility, and approval level.
Triggers when planning any outbound work, when writing a plan something else must execute, or before
reaching for a provider-specific execution skill.
**Category** operations · **Maturity** `draft` · **Recommends** `approval-boundaries`, `campaign-planning`
Changing an operation's effect, reversibility, or approval level here is a breaking change — every
guardrail downstream reads those.
### campaign-planning
*Turn a vague outbound goal into an executable plan.*
Clarifies the objective until success is observable, surfaces the constraints that shape it, composes
the work from known operations and playbooks, and decides the checkpoints. This is the entry point
when someone states a business outcome rather than an action.
Triggers on a business goal — book meetings, launch a campaign, grow pipeline — rather than a single
concrete request.
**Category** strategy · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `audience-building`, `campaign-launch`, `inbox-triage`, `performance-analysis`, `sending-guardrails`, `durable-work`
### audience-building
*Turn raw prospect data into a clean, deliberately-shaped audience.*
Decides who belongs, maps and sanity-checks the incoming fields, chooses a duplicate policy, and
organises people into named lists. Handles the messy-data questions explicitly rather than importing
whatever arrives.
Triggers when the user wants to import contacts, build or extend a list, define a segment, or asks
what to do about duplicates.
**Category** strategy · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `campaign-launch`, `sending-guardrails`, `approval-boundaries`
**Guide** [Import and clean contacts](/guides/import-contacts)
### campaign-launch
*Prepare and launch a sequence with every precondition checked and the send explicitly approved.*
Covers sending capability, step content, schedule, enrolment, and the go-live gate. Nothing starts
until the user has approved what will actually be sent.
Triggers when the user wants to create or start a sequence, launch a campaign, add contacts to a
sequence, or begin sending.
**Category** strategy · **Maturity** `draft` · **Depends on** `sdr-operations`, `approval-boundaries` · **Recommends** `audience-building`, `sending-guardrails`, `linkedin-guardrails`, `performance-analysis`
**Guide** [Launch multichannel outreach](/guides/launch-outreach)
### inbox-triage
*Work the inbound replies — surface what matters, draft together, send only what was approved.*
Orders conversations by what deserves attention first, gives compact thread context, drafts responses
with the user, sends only explicitly approved text, and records each conversation's outcome.
Triggers when the user asks about replies, inbox triage, responding to prospects, or finding the
interested leads.
**Category** strategy · **Maturity** `draft` · **Depends on** `sdr-operations`, `approval-boundaries` · **Recommends** `performance-analysis`, `campaign-launch`
**Guide** [Convert replies into meetings](/guides/convert-replies-to-meetings)
### performance-analysis
*An honest read on outreach performance, with a diagnosis that separates the causes.*
Account and per-campaign figures over a stated window, then a diagnosis that distinguishes
deliverability from copy from targeting — followed by one or two high-impact recommendations rather
than a list of everything observable.
Triggers when the user asks how campaigns are performing, what is underperforming, what to fix or
pause, or wants outreach analytics.
**Category** strategy · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `sending-guardrails`, `campaign-launch`, `inbox-triage`, `approval-boundaries`
**Guides** [Decide what to scale or fix](/guides/analyze-performance) · [Improve sequences every cycle](/guides/improve-sequences)
### approval-boundaries
*Where an agent must stop and ask — and the one case where acting first is correct.*
Defines what a valid confirmation looks like, when an earlier approval still applies, and how bulk
writes, sending to real people, unattended runs, retries, and anomaly stop-rules are gated. Every
other skill defers to this one rather than restating the rules, so they cannot drift.
Triggers before any operation touching a real prospect, when deciding whether an approval still
applies, or when configuring an agent to run unattended.
**Category** protection · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `sending-guardrails`, `linkedin-guardrails`
**See also** [Agent safety rules](/agents/safety)
### sending-guardrails
*Protect sender reputation and inbox placement.*
Domain authentication, warm-up, volume pacing, bounce interpretation, and recovery when deliverability
degrades.
Triggers before launching significant email volume, when bounce rates rise, when replies collapse, or
when a sending account or domain is new.
**Category** protection · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `campaign-launch`, `performance-analysis`, `approval-boundaries`
Ships as an honest skeleton with `TODO(expert)` markers — the structure and safety posture are
final; the specific thresholds await expert validation.
### linkedin-guardrails
*Keep social accounts safe under automation.*
Invitation pacing, messaging cadence, daily limits, and recovery when the platform flags activity.
Triggers before any LinkedIn outreach volume, when configuring account limits, or when an account
shows a warning.
**Category** protection · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `campaign-launch`, `approval-boundaries`
Also an honest skeleton with `TODO(expert)` markers.
## `reply-adapter` — 5 skills
Executes the core operation contract against Reply.io — the endpoints, auth, call ordering, and error
translation that turn a planned operation into a real one. **Requires `ai-sdr-core`** and a Reply.io
account.
### reply-cli
*Operate Reply.io from the terminal with the `reply` CLI.*
Sign in via OAuth or an API key, manage profiles and team context, and call any v3 endpoint through
`reply api`. This is the skill the others lean on when they need commands actually executed.
Triggers when executing any Reply.io operation from a shell, setting up authentication, or when
another Reply skill needs commands run.
**Category** execution · **Maturity** `reviewed` · **Recommends** `reply-api`, `reply-auth`, `reply-operations-mapping`
**Docs** [Reply CLI](/cli/overview) · [Using the CLI from agents](/cli/agents)
### reply-api
*Work with Reply.io API v3 correctly.*
Discover endpoints through the machine-readable docs, respect scopes and rate limits, and handle
`problem+json` errors and background jobs. Reading this before choosing an endpoint is what stops an
agent inventing paths.
Triggers before calling any non-trivial v3 endpoint, when choosing an endpoint for a task, or when a
call fails and needs interpretation.
**Category** execution · **Maturity** `reviewed` · **Depends on** `reply-cli` · **Recommends** `reply-auth`, `reply-operations-mapping`
**Docs** [API introduction](/api-reference/introduction) · [Rate limits](/api-reference/rate-limits) · [Machine-readable](/agents/machine-readable)
### reply-auth
*Reply.io credentials in depth.*
API key types (personal, Team, Organization), the `domain:verb` scopes model, acting-user headers, and
the team/organization resolution errors — `TEAM_REQUIRED`, `USER_REQUIRED` and friends.
Triggers when choosing or creating a key for an agent, resolving `401`/`403` errors, or working across
multiple teams.
**Category** execution · **Maturity** `reviewed` · **Recommends** `reply-cli`, `reply-mcp`, `approval-boundaries`
**Docs** [Authentication](/api-reference/authentication)
### reply-mcp
*Connect Reply.io to an MCP-compatible client, and know when to prefer it.*
Wiring `mcp.reply.io` into Claude, ChatGPT, Codex, or Cursor, choosing the right auth for the client,
and deciding when MCP tools beat CLI commands.
Triggers when setting up the Reply MCP connection or choosing between MCP and CLI execution.
**Category** execution · **Maturity** `reviewed` · **Recommends** `reply-cli`, `reply-auth`
**Docs** [Reply MCP](/mcp/overview) · [Connect](/mcp/connect)
### reply-operations-mapping
*The join table: each vendor-neutral operation → its Reply.io execution.*
For every operation named in `sdr-operations`, which v3 endpoint group and doc page serves it, which
scope it needs, what order composite work must run in, and how Reply's errors translate back into
operation outcomes.
Triggers when a plan names an operation and it has to actually run against Reply, or when a Reply
response needs interpreting in business terms.
**Category** execution · **Maturity** `draft` · **Depends on** `reply-api`, `reply-cli`, `sdr-operations` · **Recommends** `reply-auth`, `reply-mcp`
**Covers** contacts · contact lists · sequences · sequence steps · sequence contacts · inbox · reports · email accounts · LinkedIn accounts · schedules · background jobs
## `agentic-runtime` — 4 skills
Durable multi-session work in a plain-markdown workspace the user owns. **Requires `ai-sdr-core`.**
Optional — skip it if your orchestrator already provides durable work.
### durable-work
*How long-running work survives a session ending.*
Goals, plans, work items, checkpoints, approval pauses, recovery, and resumption — all kept as plain
markdown the user can read and edit. Ships `references/workspace-spec.md` plus `templates/plan.md` and
`templates/work-item.md` so the shapes are concrete rather than described.
Triggers when work spans more than one session, when resuming work something else started, or when a
plan needs persisting rather than holding in conversation.
**Category** runtime · **Maturity** `draft` · **Depends on** `sdr-operations` · **Recommends** `execution-reporting`, `user-memory`, `campaign-planning`, `approval-boundaries`
### execution-reporting
*Write execution reports that become organisational memory.*
Structure, evidence, honest deviations, and feeding results back into the next planning pass. Ships
`templates/report.md`.
Triggers after completing meaningful execution, at a plan checkpoint, or when closing a work item.
**Category** runtime · **Maturity** `draft` · **Depends on** `durable-work` · **Recommends** `user-memory`, `performance-analysis`
### orchestrator-integration
*How durable work is driven when nobody is watching.*
Which orchestrator owns scheduling and resumption, how to stop two of them fighting over the same
workspace, and what changes when a run is unattended.
Triggers when setting up background or recurring outbound work, or when more than one orchestration
runtime is available.
**Category** runtime · **Maturity** `draft` · **Depends on** `durable-work` · **Recommends** `approval-boundaries`, `execution-reporting`
**Guide** [Automate outbound end-to-end](/guides/automate-outbound)
### user-memory
*How agents store and reuse knowledge about the user.*
Preferences, ICP definitions, playbooks, and other durable context, kept in the workspace so a fresh
session does not have to ask again.
Triggers when learning something about the user worth keeping — tone, constraints, ICP — or before
drafting content that should reflect their preferences.
**Category** user-knowledge · **Maturity** `draft` · **Depends on** `durable-work` · **Recommends** `inbox-triage`, `campaign-planning`, `audience-building`
## Related
* [Install and manage the packs](/skills/overview)
* [Choose your interface](/agents/choose-your-interface) — Skills vs MCP vs CLI vs API
* [Agent safety rules](/agents/safety)
* [`INDEX.md`](https://github.com/reply-team/reply-skills/blob/main/INDEX.md) — the generated, always-current catalog
* [`docs/skill-contract.md`](https://github.com/reply-team/reply-skills/blob/main/docs/skill-contract.md) — the contract every skill follows