Plays
A play is an advisory order of steps toward one outcome.
A play is a proven order of steps toward one outcome. It is advisory: it names ordered capability ids, but it does not install a system, run a capability, or spend credits by itself.
Choose a play by its stage and the workspace need it describes. A blueprint is installable, and a reply playbook guides Inbox replies.
Choose a play from the catalog
| Play | Catalog id | Stage | Use it when |
|---|---|---|---|
| Intent to outreach | intent-to-outreach | Any time | Use when the ask names an intent signal (hiring, posting, engagement, funding, tech, or job change) and the motion is signal source, then people follow-up, then qualification, then sequence enroll. |
| Run a 50-lead outbound pilot | outbound-pilot-50 | Week 1 | Use when you can state titles, segment, and geography in one sentence and you want a reviewed outbound pilot this week, starting at 25 leads and stopping at 50. |
| Warm network first | post-engagers-to-warm-sequence | Week 1 | Use when watched profiles post at least weekly, the ICP page is filled, and you want engagers captured, qualified, and only the qualified slice put into a capped warm sequence. |
| Capture a competitor engaged audience | competitor-audience-capture | Any time | Use when one or more public LinkedIn profiles repeatedly attract the founders, revenue leaders, or practitioners you sell to, and you want that audience captured and qualified before any outreach. |
| Turn an ICP into a scored account map | icp-to-account-map | Any time | Use when you can state segment, geography, size, and who is excluded, and you want one sourced, scored account list reused by later motions. |
| A daily ranked queue of warm leads | daily-warm-lead-queue | Any time | Use when at least one warm signal source is already armed and delivering, the ICP can be stated in one sentence, and you want one morning queue instead of separate feeds. |
| First win | first-win | Day 1 | Use in a new workspace to confirm workspace knowledge and produce one small scored worksheet. |
| Founder posting system | founder-posting-system | Week 1 | Use when workspace knowledge includes a Tone of Voice page and founder posts need a reviewable cadence. |
| Reply to meeting | reply-to-meeting | Ongoing | Use when a live sequence has unanswered inbox threads that need a response toward a call. |
| Visibility sprint | visibility-sprint | Month 1 | Use when a site and Search Console are available for a month of visibility work. |
| Speed to lead | speed-to-lead | Month 1 | Use when a trigger source should move qualified rows through a workflow. |
| Weekly review | weekly-review | Weekly | Use each week to review live GTM motions before choosing one change per motion. |
| Research hiring signals | signal-hiring | Any time | Use when hiring for a target role is an account signal. |
| Research hiring companies by size | hiring-companies-by-size | Any time | Use when company size and open roles identify accounts for people research. |
| Qualify post engagers | signal-engaged-person-posts | Any time | Use when selected LinkedIn profiles attract ICP engagement. |
| Review multichannel drafts | multichannel-linkedin-email | Any time | Use when LinkedIn and email copy needs review together. |
| Build an account-based list | cold-company-employees | Any time | Use when named target accounts need decision maker research. |
| Set up cold email infrastructure | email-infra-setup | Day 1 | Use before cold email when no two warmed mailboxes exist on a separate sending domain. |
| Migrate one Clay table | migrate-from-clay | Week 1 | Use when moving a single Clay people or company table into a Dreamstate worksheet. |
| Prioritize identified website visitors | website-visitor-outreach | Ongoing | Use when RB2B website visits are provisioned as a push-only source and visitors need CRM context before outreach. |
| 30-day GTM review | day-30-review | Month 1 | Use after 30 days of activity to decide whether to scale, change, or stop each live GTM motion. |
| Launch a client workspace | client-workspace-launch | Day 1 | Use when an agency operator needs a separate client workspace before installing client GTM plays. |
The catalog is the source for the ordered steps. Read the workspace state first, then choose a play whose stage and needs fit what is actually present.
Run the steps deliberately
After choosing a play, inspect the exact capability schema for each step before running it. Check the result in the app after every state-changing step. A play does not grant authority, so credits, modes, and each capability contract still apply.
Do not confuse it with workflow play list
workflow.plays_list is a read of workflow subjects, growth experiments, and campaigns. It is not the play catalog and should not be used to choose an advisory catalog play.
workflow.plays_list has a similar name but reads running workflow subjects, growth experiments, and campaigns. It is not the advisory play catalog and does not select catalog steps.
If a play’s stage, needs, or produces do not match current workspace facts, do not force it. Read the catalog again, choose another play, or use a blueprint or recipe when the requested outcome is an installable system or fixed worksheet kit.
If a capability refuses a play step, report its typed failure and repair the prerequisite identified by that contract. Do not change a play’s ordered ids or claim that its advisory plan performed an action.
Read the catalog before running
The blueprint catalog is the authoritative play catalog. Each play has an id, ordered capability steps, a stage, needs, produces, skill ids, and a leading metric where the catalog supplies one.
Stages distinguish when a play fits: day_1, week_1, month_1, ongoing, or weekly. Choose the stage from actual workspace state rather than treating every play as a required setup sequence.
first-win is a day_1 play. Its ordered work covers Context, a sourcing plan, a workbook, a worksheet, a row source with sampled run, an evidence column, and a score.
post-engagers-to-warm-sequence is the catalog play titled Warm network first. It is intended for the week_1 stage and connects workbook work with a sequence only after real workspace evidence is available.
outbound-pilot-50 is titled Run a 50-lead outbound pilot. It is a week_1 play and should be treated as an ordered plan, not as an instruction to send or enroll a person.
founder-posting-system is a week_1 play. Its social steps draft and schedule content only; the catalog decision says these steps never publish content.
reply-to-meeting is an ongoing play. Its steps read an existing Inbox conversation, classify it, and draft a response; drafting does not send a message to a person.
visibility-sprint is a month_1 play. It uses visibility baseline reads and one writing save, which keeps its outcome grounded in measured evidence and documented business knowledge.
speed-to-lead is a month_1 play. It uses workflow creation, linting or validation, and activation preview rather than presenting a workflow as a hidden running automation.
weekly-review is a weekly, read-only play. It uses runs, sequence analytics, worksheet qualification, and the credit ledger to review current operating evidence.
Execute each step as a contract
A named skill teaches the practice for a play but grants no capability. Architect uses a skill as guidance and still searches, fetches, and follows the exact schema for every capability step.
A play capability id must be known to the catalog. Before running it, use canonical discovery to search, get the exact contract, and inspect whether the returned contract is already runnable in the current turn.
Every mutating step must supply a supported mode. smoke_test inspects schema and policy, dry_run previews against real workspace state without business writes or provider spend, and live executes the requested work.
A play itself has no credit effect because it does not run work. Each capability step has its own cost policy and credit class, and paid live work can require a quote and max_credits ceiling.
Publishing a sequence and enrolling people do not send messages. A sequence is drafted, validated, published, enrolled, started, delivered, and replied through separate states; sending begins only on an explicit start.
A missing LinkedIn or email connection can block running or sending a step, but it does not block building the workbook, draft, or sequence structure described by a play.
After a state-changing play step, inspect the resulting workbook, document, sequence, workflow, or draft in the app. JSON ids are the source of truth, while a web_url can take the user to the exact state-bearing object.
A play can make a complex goal legible, but it does not compress product controls. Treat each ordered step as its own capability request with its own schema, state result, provider conditions, and credit policy.
When it goes wrong
Start with the play’s real catalog entry and the workspace’s real state. If a plan cannot satisfy a prerequisite, stop at the capability failure, correct that prerequisite or select a better-fitting catalog entry, then re-check the app state before continuing. A play is advisory even when every step is valid.
Record the returned object id, its state, and any web_url after a successful write. This makes a later weekly review able to distinguish an installed object, a draft, a validated plan, and work that actually ran.