@trydreamstate/cli 1.2.0 → 1.3.0

package/agent-plugin/plugins/dreamstate/skills/linkedin-warm-signals/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: linkedin-warm-signals
+description: "Warm people come from worksheet sources such as post engagers, followers, profile viewers and website visits. Judge worksheet rows against Required criteria, then build a capped warm sequence while protecting sender account. Use when user wants leads from LinkedIn presence or network-first motion. Does not cover cold lists from search (list-building does), writing posts (social does) or replying in existing threads (inbox-replies does)."
+---
+
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run` (`dry_run` first for anything that writes, spends credits or reaches a person). If the server asks you to sign in, approve it in the browser.
+
+# LinkedIn Warm Signals
+
+## Boundary
+
+- Owns: judging warm-source rows and warm send caps.
+- Sequence mechanics, copy, and pacing: [`outreach`].
+- Cold lists from search sources: [`list-building`].
+- The `sequence` pack lists the tools and their exact inputs.
+
+People who already engaged are the warmest audience a business has. Capture the signal into a worksheet, keep only the ones who fit, and reach them with a message that names the signal honestly, at a pace the account can sustain.
+
+## Backing packs
+
+The tables pack backs the signal worksheet: its source and criterion columns. The sequence pack backs the warm sequence and LinkedIn engagement actions. The integrations pack holds the LinkedIn account connection and signal source configuration. Public comments on posts are observations in the visibility pack.
+
+## The invariant
+
+Signals land in a workbook worksheet as a row source, with criterion columns marked Required or Nice to have, like any list. Outreach goes through a sequence of LinkedIn message and email steps, paced by its caps and sending hours. Account safety is a rule, not a suggestion.
+
+## Practice
+
+1. **Read context.** Ideal Customer and Tone of Voice in Company Context. Confirm which LinkedIn account is connected.
+2. **Pick one signal.**
+   - Engagers on the account's own posts: highest intent, reference the post.
+   - Profile viewers and new followers: warm but softer; lead with relevance.
+   - Engagers on a competitor or peer post: public research, on its own worksheet.
+   - Sort pasted LinkedIn URLs first: person profiles (/in/) and company pages (/company/) are different sources. Build one source per kind on its own worksheet and say which went where.
+3. **Build the worksheet** (list-building skill). One signal source per worksheet. Columns: the signal (which post, what they said), an AI fit judgment against the ICP with the supporting quote as a Required criterion column, then contact data gated on the Required criteria.
+4. **Run a sample and read the rows.** Exclude the author's team, existing customers and open conversations with a Required criterion column and run conditions, not by hand.
+5. **Draft the warm sequence** (outreach skill). The first LinkedIn message names the real signal in one line, adds one relevant point, and asks a light question. Three steps or fewer; warm people do not need a long cadence.
+6. **Show and start.** Show the final copy of each step, audience count, sender and expected pace in days, then enroll and start.
+7. **Recurring, if asked.** A workflow adds new signal rows on a schedule and enrolls those that pass every Required criterion.
+
+Search the tool for each task. The search returns runnable schemas for its top hits; read any other ids together in one tools_get, then run.
+
+## Safe limits
+
+- Connected accounts read what they own: their posts, network and inbox. Third-party profiles and competitor posts are researched with tools that do not act through the account, and those cost credits. Routing third-party research through the account to save credits is how accounts get restricted.
+- Reads are metered like sends. Use a bounded window, not the whole network or inbox.
+- One person, one sender. Never touch the same person from two accounts or two sequences.
+- A capped cell or delayed send is pacing, not a failure.
+- A reply, decline or unsubscribe stops that person on every channel.
+
+## Guardrails
+
+- Name public engagement only; never write as if you watched someone.
+- Quote the captured comment or leave it out. Never invent what someone said.
+- Credits are the consent: show the estimate for paid research and contact data, then run.
+
+## What to return
+
+- Signal, window, worksheet link, rows captured, qualified count with example reasons.
+- Warm sequence steps with final copy, sender, cap and expected pace.
+- State proven (built, enrolled, started), credits charged, accounts to connect.
+
+## Check it works
+
+Done means checked, not built. Before you report, read back everything you made or changed, and run, test or preview it where that is offered; publish or send only when the user asked. An empty, failed or wrong result means an input or setting is wrong: find which from the error or the output, correct it and check again, until it is right or a real blocker stops it. Report what you checked and what it showed.

package/agent-plugin/plugins/dreamstate/skills/list-building/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: list-building
+description: "Build a workbook of companies or people: as few sources as possible, people at companies through the employees enrichment fanned out to a second worksheet, one column per criterion marked Required or Nice to have, run conditions that skip rows already failing, an optional score, sample then scale, and honest coverage."
+---
+
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run` (`dry_run` first for anything that writes, spends credits or reaches a person). If the server asks you to sign in, approve it in the browser.
+
+# Workbook building
+
+## Boundary
+
+Owns: sources, columns, criteria, and building qualified lists.
+- Multi-step outreach sequences: [`outreach`].
+- Existing worksheet structure and values: [`worksheet-tidy`].
+- Durable customer and company records: [`crm`].
+- Warm sources: [`linkedin-warm-signals`].
+- Explaining cell values and failed runs: [`diagnostics`].
+The `tables` pack lists the tools and their exact inputs. When user says delete, permanently delete named workbook, worksheet, template, automation, contact, row, or column after showing removal impact and receiving explicit approval. When user says archive, archive only. Never say permanent deletion is unavailable.
+
+<!-- architect-operation-contract
+{"required_capability_ids":[]}
+-->
+
+
+A list is worth contacting when every row would recognise itself in the reason you contact it. Find the smallest set where that is true, prove it on each row, and stop.
+
+## Rows and qualified rows
+
+- One workbook per list; each worksheet holds one kind of row and at most one live source. Everything else is a column.
+- A row is a raw entry from the source. A qualified row passes every Required criterion.
+- Track every criterion the user named, even when the source already filtered on it, and mark it Required or Nice to have. A criterion is a condition, not a column: put it at the cheapest place that decides it (a source filter, a run condition on a value already on the row, or a condition in the fit score). Its result is pass, fail or unsure. Missing data is unsure, never a fail.
+- Keep disqualified rows: they are paid for. Views decide what to show.
+- Exclude competitors by default: rows at a competitor company (named in request or Company Context) and competitor companies themselves fail a Required criterion, applied in first paid column run condition. Say that you excluded them and which. When exclusion is required and Company Context plus request contain no competitor values, ask once for competitor names before any paid sample. Do not source approximate list, create paid rows, or substitute keyword exclusion.
+
+## Blueprint or build
+
+Before building, see if a blueprint does exactly what you need: its source is the right source for the hardest criterion and its columns are the chain you would build. If one does, install it, then configure its columns. If not, build your own workbook. Never install a near miss to have something to start from.
+
+When calling `workspace.blueprints.recommend`, pass `required_filters` for every user-stated hard constraint, using its closed filter enum. Read `unmet_required_filters`; do not install a recommendation that cannot apply every Required filter.
+
+For people engaging with competitor company posts, `signal-engaged-company-posts` exact match. Prefer it. It sets `max_posts_per_company=2`, `max_engagers_per_post=25`, `sample_size=25`, then excludes employees of selected companies in first paid qualification. Attach the company engager source directly only when a custom workbook is needed: send `company_urls` as literal string array, keep same caps, add employee-exclusion qualification before outreach.
+
+## Free preview before build, complete chain before paid sample
+
+Use the zero-credit source preview before workbook creation when the source permits a provider preview. Pass `definition_id`, typed `filters`, and `limit` directly. It returns named sample rows, writes no worksheet, and charges zero credits. Do not attach source or run it live merely to see first LinkedIn people rows.
+
+Before first paid source run, configure every run condition, Required qualification column, AI fit-score column, and requested work-email preview column. Adding/configuring columns is free. First paid sample must land into chain already able to qualify source rows and gate later spend. Read every configured column back before source run. A source-run warning `qualification_columns_missing` means stop and configure the chain before spending.
+
+## Configure every column before paid source runs
+
+A column is configuration plus a run condition, set together when the column is created or configured, never added bare and fixed later. A source works the same way: its configuration is its filters. Every source and column schema shows its full configuration and run condition; set them there, before the first run.
+
+- **Configuration:** the inputs that make it answer this request (source filters, titles, locations, prompt referencing `{{column}}` values and the user's criteria).
+- **Run condition** (the column's run if setting): a filter on spend. It decides row by row whether the column runs. A view filter only hides rows and saves nothing.
+
+Filter as early as possible. Put each criterion at the first place that can filter it:
+1. The source filter, when the source has one for it (location, keywords, date posted). Source filters change what is fetched, so failing rows never arrive.
+2. Otherwise, the run condition of the first column that produces the value, so every later paid column skips the row.
+3. Only judgment the data cannot express goes into a scoring column.
+Never leave a criterion source can filter to later column or score. Use source own filter fields: similar input elsewhere (scoring column size setting) filters nothing at source. Before first paid source run, read source back to confirm every filter is on it. Change source filters only before first paid run. Criterion source cannot fetch on goes into run condition of first paid column, on source row value, for example company headcount `gte` 50 and `lte` 200.
+- Show source values with a formula referencing the source field. Never type a value into a column unless the user asks for a fixed value.
+
+Run conditions as filters:
+- Every column that costs credits or calls a provider has one.
+- It names the fields that must hold first, with `is_set`, and excludes rows an earlier criterion failed: `eq`, `neq`, `in`, `not_in`, `contains`, `not_contains`, `gt`, `gte`, `lt`, `lte` on that column's value.
+- Chain them: each paid column's condition includes every earlier Required criterion it depends on, so a disqualified row stops costing anything.
+- Exclude rows that failed, not rows that are still unsure, unless the column is only worth running on qualified rows (contact data, emails): those require a pass.
+- Order columns cheapest and most selective first: free formulas and exact fields, then enrichments, then judgment columns, then contact data.
+- Read the column back after saving and confirm the condition is there.
+
+Disqualifiers and the fit score:
+- A disqualifier the row already decides is a run condition, never a new column. Role or headline keywords: one `not_contains` condition per word (student, intern, university) on the title or headline. Competitors: company name `not_in` the competitor names from Company Context. Size and dates: numeric ranges. Put them on the first paid column and on the enrollment gate.
+- To add or change exclusions on an existing worksheet, edit the run conditions of its existing columns. Do not add columns for them.
+- The AI fit score is one score column whose rubric lists every criterion as Required or Nice to have, with the row's signals (engagement, hiring, recency, role) as evidence. A Required fail scores 0; missing data is unsure. Enroll only rows at or above the threshold the user set.
+- Add an AI or research column only for judgment the row cannot express (what a company actually sells, whether a post is a real complaint), never for something a keyword or a list match decides.
+
+## Loop
+
+1. **Discover.** From the request, the conversation and saved context: what the list is for, what qualifies and disqualifies a row, Required versus Nice to have, and the narrow or broad reading of vague terms. Ask only what is still missing. When you need values (URLs, names, numbers), ask for the values themselves as a free-text answer; options are possible answers, never ways of answering. Never ask how many up front.
+2. **Blueprint or build.** Use a blueprint only if it does exactly what you need; otherwise build your own.
+3. **Hardest criterion first.** Select source that natively owns every Required company fact before convenient connected-account search. Search resolved executable definitions for ready people-source definitions and their exact input contracts. Select the returned hard-firmographic people source when it owns person location, company size, and industry, then attach that source. If no resolved people source owns hard company facts, source companies first with the resolved company search using exact company size and industry, then fan out people from qualified companies. The resolved LinkedIn people search owns role and LinkedIn facets but does not declare company headcount. Never replace missing size or industry with `SaaS` keyword. Use LinkedIn source only when declared facets cover every Required pre-spend fact, or after company-first qualification. If LinkedIn provider contract later exposes company headcount, use declared facet; never claim it exists before contract says so.
+4. **Free source preview, then configure chain.** Call the zero-credit source preview first when available. Read named rows against every criterion. Aim for more than half right at source. If source can filter failing criterion, fix input and preview again; if it returns nothing, find over-narrow input. If source cannot express hardest criterion, switch source now, before workbook attachment or spend. After free preview, build complete Required qualification, 0 to 100 fit-score, and work-email preview chain with run conditions.
+5. **Paid sample only after chain exists.** Run bounded paid source sample, then run configured chain on sample and read cells. Fix and rerun until correct. Follow every run to end.
+6. **Audit.** Report qualified of total and cost per qualified row. Under about 30 percent qualified, name the Required criterion failing most and propose one change; under about 10 percent, propose a different source. Then ask how far to grow the list.
+7. **Scale the same source** in bounded batches toward the target, running paid columns only on rows their conditions admit. Only qualified rows count. Call a source exhausted only when a run returned fewer rows than it asked for.
+
+To grow an existing list, rerun its source with a higher target and widen only with levers that keep every Required criterion; report near matches separately.
+
+## Verification
+
+- Filters are exact when the source owns the fact, approximate when they rest on labels or keywords. Verify approximate ones per row; never re-check exact ones.
+- A Required role from a search index can be stale: confirm it before a paid step. A dated requirement needs a dated field.
+- Judge by meaning: a plain equivalent of a role passes. Fail a row only on evidence that contradicts a criterion.
+
+## Gates
+
+- A paid run's ceiling is its preview's maximum; credits within it are already consented.
+- A refusal names what to fix: fix that input and retry, three times at most, then report it.
+- A missing account blocks running, never building: build everything and say what to connect.
+- Never invent a count. Never delete rows unless the user asks.
+- Keep email, LinkedIn URL and company domain columns on people rows so do-not-contact matching works.
+
+## Done
+
+Report the workbook link, sample size, qualified count against the target, qualification rate, credits charged, accounts to connect, and next steps. If this document disagrees with a tool result, the tool is right.

package/agent-plugin/plugins/dreamstate/skills/list-building/column-authoring.md

@@ -0,0 +1,37 @@
+# Designing columns
+
+A column answers one question about a row: what value it holds, what produces it, and which rows are worth spending on. Decide all three when you add it.
+
+## Add a column
+
+- Find enrichments with the findable catalog for this worksheet; choose by the data you need, never by provider. Use the returned add call unchanged: its input bindings name existing column keys only.
+- Reference source fields and columns exactly as the worksheet returns them after the source lands: `{{column_key}}` or `{{column_key.field}}`. Never guess a field name or add a copy column to reach one.
+- Send a declared output only for definitions that let you declare it; fixed-output enrichments return their own fields.
+- Save the run condition with the column (see the skill). Read the column back and confirm it.
+- Adding a column costs nothing. Run it on one row with a credit ceiling, read the cell, then run the rest with `max_rows` set, continuing while more rows remain.
+- A refused column names the input to fix: fix it rather than switching to another kind of column.
+
+## Criterion columns
+
+- When a keyword or list match on an existing value decides the criterion, it is a run condition, not a column. Use a formula only to show a value; an AI or research column only when the criterion needs judgment or outside evidence, and its result carries a one-line reason.
+- Prompts reference row columns and the user's criteria, never sample companies, people or values.
+- The fit score is where criteria meet: its rubric names each criterion as Required or Nice to have and uses the row's signals as evidence. Contact data never proves anything else.
+- A blueprint's AI fit score arrives with an empty instruction: it holds the row fields as context but no rubric, so it does not run until one is written. Before running it, read the workspace Company Context and ideal customer, write a short rubric naming who scores high and who scores low for this offer, end with "Return only an integer from 0 to 100.", and keep the row field lines below it. If there is no Company Context yet, ask the user who they sell to rather than inventing a generic profile.
+
+## Formulas
+
+Read the formula definition's `expression` description first: it lists every helper, operator and limit. Regex and URL parsers do not exist.
+
+```text
+UPPER({{company_name}})
+{{company_profile.employee_count}} >= 50 ? 'target' : 'small'
+LAST({{company_linkedin_url}}, '/')
+```
+
+## Changing a column
+
+Read its current state before changing it, so an edit never overwrites a newer change.
+
+## Clay CSV rebuilds
+
+CSV values are baseline evidence, not recovered Clay configuration. Ask once for missing Clay prompt, formula, waterfall, and HTTP/tool settings. If user lacks them, read headers and values, then supply only catalog-backed inferred equivalents: enrichment, AI/research prompt marked `# approximated, original Claygent prompt not recovered`, formula reference, provider waterfall in supported catalog order, or native tool mapping. Mark inferred plans approximate. Create columns disabled, preserve raw Clay column, request `tables.table_runs.preview_cost` for each rebuilt column. Never invent provider names, tool ids, or capability ids. No catalog equivalent means keep raw column and report reason.

package/agent-plugin/plugins/dreamstate/skills/list-building/readback.md

@@ -0,0 +1,15 @@
+# Reading the worksheet back
+
+A write is a request. The read back is the evidence. Nothing is reported as landed, enriched, judged or scored until it has been read off the worksheet after the run finished.
+
+Read rows, not counts. One page read of the rows with the columns you need is the read back; opening a single cell's detail is for diagnosing that cell (its run, provenance or error), never a way to read rows one at a time.
+
+A count that is still being computed is unknown, not zero, and a completion claim made on it has no evidence behind it. When the number matters, ask for the exact count.
+
+Every cell says where its value came from and what state it is in. Empty and failed are different answers and are reported separately; neither is zero. A missing provider answer is unknown, and so is a Required column with no data. Neither is false, and neither may be filled in from a similar row.
+
+Let columns settle cells. Setting cell values by hand bypasses the evidence trail and is worth avoiding when a column run can do it.
+
+## What a completion report needs
+
+The source run finished, landed and duplicate counts known, every enrichment run finished, then a worksheet page actually read. A queued source, a missing duplicate count, an unfinished enrichment or a page requested but never looked at is incomplete evidence.

package/agent-plugin/plugins/dreamstate/skills/list-building/sourcing.md

@@ -0,0 +1,31 @@
+# Sourcing rows
+
+## Attaching a source
+
+- A worksheet has one source. Attaching it is building: it saves even when an account is still missing; the run says what to connect.
+- Bind the source's declared inputs with values from the request, in the form each input declares. Never an empty binding.
+- When the user gives a LinkedIn people-search URL, attach `provider.linkedin.people.search_by_url` with that exact URL as `raw_search_url`. It runs the search the user built and saw. Never take the URL apart into filters for `provider.linkedin.people.search`: ids lose their names and the rows drift from what the user saw.
+- LinkedIn keyword search applies AND before OR. Group every OR inside parentheses (`("founder" OR "co-founder") AND "she/her"`). When a URL's keywords mix AND and OR without parentheses, say how LinkedIn will read them before the sample spends credits.
+- Prefer source whose declared filters apply every Required criterion before provider spend. Resolve candidate source definitions through `tables.executable_definitions.list_resolved`; select ready hard-firmographic people source declaring `company_size` and `industry`. Connected `provider.linkedin.people.search` does not declare company headcount. For required headcount plus industry, use resolved hard-firmographic people source, or company-first `source.company_search` then qualified-company people fan-out. Keywords such as `SaaS` never satisfy company-industry or headcount criteria.
+- Attach dry run returns `binding_preview.binding`: exact normalized binding live accepts. Use returned refs unchanged. Human LinkedIn location labels resolve during attach dry run to `{id,label}` refs; do not perform separate taxonomy lookup when dry run supplies resolved ids.
+- Do not pass `columns` on attach unless a field should be its own column. Attach creates only the source column. `available_output_paths` lists every field. `field_guidance` names a few relevant `{{source_column_key.field}}` references. Add a formula column later only for a field you choose.
+- To continue a list, run the same source again. Changing its inputs starts it over.
+- Enrich rows you already have; never add a second source for them. Fan out only when an enrichment returns a nested list per row and the user wants those items as rows.
+
+## Filter values
+
+- Use the real options a filter offers for places, industries, companies, titles and schools. A guessed value returns wrong rows that look right: read the rows.
+- A filter the source drops is not applied: keep that criterion as a column with a run condition.
+- Several roles are several title values, never one joined string.
+- Hiring signals: the role being hired filters the companies; the titles of people to contact go into the employee lookup. The place goes in job location, not headquarters, unless the user asked where companies are based.
+- Hiring at companies of a size: when the size band is the narrow part and the role is common, source companies with the size filter, add the open jobs column on each company, and run the employee lookup only on companies with at least one open job. When the role is rare, start from the hiring source and put size in the run condition of the first paid column. Say which path you chose and why.
+- Company size, seniority and employment type: use the source's input when it has one; otherwise add the column and a condition, and say which.
+- Recruiting and staffing firms post for clients. When the sample shows them, add one judgment column for the actual employer and whether the poster is a recruiter.
+
+## Targets and credits
+
+- Use the request's target. When none is given, free-preview first, then run attached source with `max_rows:25` and matching `max_credits`; ask how far to grow after reading those 25 rows.
+- Over-provision about 1.4 times the target when later criteria drop rows.
+- `tables.sourcing.preview` accepts source definition plus filters directly. For LinkedIn people search, it returns up to ten named provider rows free, with no workbook, source attachment, or credits. Use it before paid sample. Preview maximum is ceiling; what was charged is read from finished run. Counts before run finishes are unknown, not zero.
+- Run an enrichment on a few rows, read them, then continue the remaining rows instead of rerunning the sample.
+- A cell blocked by a daily limit is the workspace's pacing cap, not a defect.

package/agent-plugin/plugins/dreamstate/skills/outreach/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: outreach
+description: "Build a multi-channel sequence and enroll a workbook into it: preview one real message first, fixed scaffold with small personalized slots, channel steps with the wait inside each step, column filters decide who enrolls, paced sends."
+---
+
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run` (`dry_run` first for anything that writes, spends credits or reaches a person). If the server asks you to sign in, approve it in the browser.
+
+# Sequence building
+
+## Boundary
+
+Owns: new conversations, multi-step outreach sequences, and enrollment.
+- Existing-thread replies: [`inbox-replies`].
+- Building and qualifying who to contact: [`list-building`].
+- Warm-source rows and send caps: [`linkedin-warm-signals`].
+- Automations that are not outreach sequences: [`workflows`].
+- Explaining why a sequence has not sent: [`diagnostics`].
+The `sequence` pack lists the tools and their exact inputs.
+
+How to build a multi-channel sequence and enroll a workbook into it. The sequence pack lists the tools and their exact inputs; finding and qualifying the people belongs to the workbook building skill.
+
+## Delete and archive
+
+When user says delete, delete permanently. Show impact first unless user already asked to delete. Archive only when user says archive. Never say hard deletion is unavailable.
+
+## Before writing
+
+- Build a new sequence for each request. "Enroll in a sequence" means a new one. Use or edit an existing sequence only when the user names it or asks to change it; never ask the user to pick an existing sequence.
+- Read the ideal customer profile, the product and offer pages, and the message writing notes before asking anything. The value proposition comes from those pages; ask for it only when none of them states it. Ask one question only when a required fact is missing, then build.
+- Before writing any sequence copy, load the knowledge skill and read saved Company Context pages that govern it: Product Information and Offer for claims, Ideal Customer for audience fit, and Tone of Voice for register. Name pages used. Pass returned document ids as `context_document_ids` and returned revision ids as `context_revision_ids` on the create-from-worksheet call, so the draft receipt proves exact context lineage. Never reuse another workspace's product copy. If Company Context has no applicable page, say so and ask for the missing fact before writing prose.
+- The kind of sequence is a required fact. Unless the request already says it, read selected saved view's structural channel reachability, then ask once, in one question, which reachable channel and goal (a reply, a meeting, a demo). Offer only channels with reachable rows and recommend channel most rows support.
+- Use only channels the rows can be reached on. A channel step needs the field it sends to; when that field is missing, find it first with an enrichment.
+
+## Copy
+
+- Every message carries the signal that found this lead, read from the worksheet column that holds it. Bring a signal that lives on a linked row onto the enrolled worksheet with a lookup column. When no column holds a usable signal, add one that writes it first.
+- The signal is about them, never about how you found them.
+- Fixed scaffold, small slots: greeting, pitch, call to action and sign-off are the same for everyone; only the slots change. Write the scaffold so every value reads correctly, and never invent a fact to fill a slot.
+- Greet by first name. The enrolled worksheet's columns are the variables, so add a first name column when it is missing.
+- Every sending step that uses row variables carries its own fallback copy, written first, that reads well with every variable empty. Never publish a step without it.
+- Follow-ups give a new reason to reply, never a "just following up". Keep them linear: a reply ends the lead's run by itself, so never add steps that check for one.
+- Preview at least three real rows, one with thin evidence. Read each like the recipient and fix the scaffold, not one lead. Grade and tighten with message-copy.md.
+
+## Steps
+
+When asked what sequences you can build or which templates exist, list the sequence blueprints and the available step types and answer from those; never answer from memory.
+
+Use a sequence blueprint when one does exactly what you need (its channels and steps match the request); otherwise build your own sequence. A sequence does not need a worksheet: create it on its own and set its enrollment source or trigger later.
+
+When the user asks to enroll a list:
+
+0. Read the workbook's worksheets and enroll the people worksheet (its Qualified view), even when another worksheet is open. Only when no worksheet holds people, fan out the person records first.
+
+1. Read selected saved view's channel reachability, then ask which kind of sequence (see Before writing), offering only channels with reachable rows: LinkedIn (connect, then message) when LinkedIn rows exist, email when verified work-email rows exist, both only when both counts are nonzero. Recommend channel most rows support.
+2. List the sequence blueprints before creating anything, and install the one that matches that channel mix, if one does, giving it the worksheet column that holds the signal (add the lookup first when the signal lives on a linked worksheet), with the list's Qualified view as its enrollment source; otherwise build the steps yourself. It lands as a draft that never sends, with the steps, waits and AI writing already set.
+3. Write each step's copy for this request with the row's columns as variables (first name, the signal column, a short AI variable column when the raw value is long), following message-copy.md. A message whose only variable is the first name has no signal: when the signal lives on another worksheet (such as the company's open role), add the lookup column first. Keep the blueprint's follow-up steps unless the user asked for one message. Preview real rows and fix the scaffold.
+4. Validate, enroll from the Qualified view and report. Never start it unless the user says start. When the Qualified view is empty, still build and validate the sequence bound to that view, preview its copy on a few worksheet rows, and say that rows enroll as they qualify and what would qualify them; never enroll a wider view in its place unless the user asks for it.
+
+- Read each step's schema for what it already does, such as connecting or waiting before it sends, and never add a separate step for what it handles.
+- Validate after every change. Never call a sequence ready until validation is clean and the saved sequence shows every requested step.
+
+## Audience
+
+- The workbook is the audience. Filter enrollment on qualified rows (every Required criterion column passes) and on the columns the copy needs being set. Match role families, never one exact title. Without criterion columns, add them from the ideal customer profile, run them, read them, then filter.
+- A sequence can have unlimited ordered workbook audiences. Add first workbook, worksheet/tab, and saved view, then set that audience's filter, email and LinkedIn URL identity columns, daily enrollment cap, and priority sort. Add another workbook only when it needs its own audience settings. Earlier audience wins when same person appears in more than one audience.
+- Keep filters, identity mapping, cap, and priority inside each audience. Never apply one global filter or sort across several workbooks. Use a workflow source only when entry needs logic a workbook audience cannot express.
+- When several people from one company are enrolled, turn on company pause on reply.
+
+## State
+
+- Building never waits on connections or rows. Build, preview, validate and bind anyway, then say what to connect or what will make rows land.
+- Publishing and enrolling never send. After enrolling, leave the sequence published and never started unless the user explicitly says start; that is paused. Staged contacts on an unstarted sequence are success.
+- Drafted, validated, published, enrolled, started, delivered and replied are separate facts; report only what the last result proves. After an unknown outcome, read state before retrying, and never enroll or send twice.
+
+## Done
+
+Read back everything you built; an empty or wrong result means an input or setting is wrong, so fix it and check again. Report the sequence link, its steps and channels, the enrollment filter, enrolled and held back counts, and that nothing was sent.

package/agent-plugin/plugins/dreamstate/skills/outreach/channels.md

@@ -0,0 +1,5 @@
+# Channels
+
+LinkedIn messages and emails for the same people belong in one sequence, one view and one launch. All channels share one contact history, so a reply, bounce or unsubscribe on one channel stops the others.
+
+Never use one channel to route around a stop, a suppression, a blocked sender or a decline on another. An existing conversation is answered in that conversation, not by adding a sequence step.

package/agent-plugin/plugins/dreamstate/skills/outreach/deliverability-and-caps.md

@@ -0,0 +1,17 @@
+# Deliverability
+
+Drafting, previewing and validating work without any sender connected. A missing email or LinkedIn account blocks sending only. Never switch channel to hide that.
+
+Senders default to every healthy LinkedIn account and every connected mailbox, pooled, so volume spreads across them. Pick a single account only when the user names one.
+
+Before starting, look at sender health, sending hours, cooldowns, daily caps, suppressions and remaining headroom, and set expectations: sends spread over days, not minutes. Protecting the account matters more than finishing today.
+
+Bounces, unsubscribes, suppressions and replies stop contact on every channel.
+
+## Not enough email capacity
+
+A warmed mailbox sends about 30 emails a day. When a sequence needs more than the connected mailboxes can send, the answer is more mailboxes, never higher caps on the ones that exist.
+
+The workspace can buy mailboxes on lookalike domains (never its main domain), two per domain, at $7 per mailbox a month. Domains and warmup are included, and new mailboxes take about three weeks to reach full volume, so plan the sequence around the ramp.
+
+Buying spends money. Show the capacity gap and the purchase preview (addresses, today's prorated charge, the monthly amount and any blockers), and buy only when the user asks for it. If the preview shows blockers, explain them rather than working around them.

package/agent-plugin/plugins/dreamstate/skills/outreach/enrollment.md

@@ -0,0 +1,17 @@
+# Enrollment and launch
+
+Default for "enroll this list in a sequence": `sequence.sequences.create_from_worksheet`.
+
+Order of work: preview one real personalized message in chat, dry run, then build the sequence with the worksheet bound as its audience. Building from the worksheet already validates, binds the trigger and stages the rows, so never enroll the same rows again after it. Then publish. Start only when the user explicitly says start.
+
+When the user asked to enroll, do not stop at the draft: publishing is part of enrolling and sends nothing, so build from the worksheet and publish in the same turn, then report that nothing was sent. A published sequence that was never started sends nothing; that is the paused state the user asked for.
+
+Enrollment reads leads straight from the worksheet rows; do not create or import contacts first. A sequence takes one enrollment source: a workbook view, or one workflow, never both. A published sequence bound to a view keeps enrolling rows that later land in or start matching it. Filters on any worksheet column narrow who enrolls; with no filter every row enrolls. When the user said who should get the sequence, filter on the columns that hold it and report how many were held back. Enrollment is free and never sends. Starting is the moment real messages begin, paced over time.
+
+Enrolling from a worksheet binds it as the sequence's trigger. Report the trigger state and the sequence link.
+
+"Enroll in a sequence" means the people worksheet of the workbook the user is looking at, or just built, into a new sequence built for it, even when a company worksheet is open. Use an existing sequence only when the user names it; never report another worksheet's enrollment as the answer.
+
+Publishing and enrolling can happen before any sender is connected. Only starting delivery needs a connected account, and then name exactly which one. Show a preview of real rows in chat as you build; it is not an approval gate. When the user asked to enroll, build and publish in the same turn and let them edit the copy after. Stop for review only when the user asked to approve copy first. There is no send cap to pass: every enrolled lead is worked through, paced by each account's daily limits and sending hours.
+
+After a timeout or an unclear result, read the current enrollment and run state before trying again. Never enroll the same leads twice and never start a second copy of the same sequence.

package/agent-plugin/plugins/dreamstate/skills/outreach/message-copy.md

@@ -0,0 +1,41 @@
+# Message copy
+
+Preview first. Draft one full message for one real qualified prospect, subject line included for email, written in chat from that lead's own worksheet values, and show it with the personalized parts called out. A preview is text in the conversation: it needs no contact record, no enrollment and no send. When the user asked you to preview and then build, show the preview and keep going in the same turn; otherwise let them react, revise, and only then write every step.
+
+Keep the scaffold fixed: greeting, the pitch paragraphs, the call to action, the sign-off and every paragraph break are the same for every lead. The personalized parts are short slots, such as first name, company, niche, target persona or one signal you can point to in the prospect's data.
+
+Ground every personalized claim in the prospect's row or the workspace knowledge. If the data is empty, use the fallback wording, never a guess. Use only variables the workspace offers. An unresolved variable in a preview means the copy is not ready.
+
+For each sending step, decide row variables first. Write fallback message before personalized message, for any empty row value. Put it in that step's `fallback_template` field; it is not its own step and not a branch. Fallback must not use row variables that can be empty, sender variables always present are allowed. Never publish a sending step with row variables and no fallback. Before publishing, render every step for at least three real rows, including one row with an empty value.
+
+Merge fields are the enrolled worksheet's columns. Before copy greets someone by first name, check that the worksheet has a first name column. If it does not, add a visible `first_name` formula column with `FIRST_NAME({{name}})` through `tables.columns.add` (it runs no paid work), then write `{{first_name}}`. Derive any other short slot the copy needs the same way, as a visible formula column, before drafting.
+
+Write in the workspace voice from its message writing notes. Short beats long: one idea per message, one clear ask. A follow-up refers back to the earlier touch instead of restarting the pitch. Each message still makes sense if it is the only one the person reads.
+
+When the user asks to change one step, change only that step and leave the others untouched. Validate after every copy change.
+
+## Personalize from the signal that found them
+
+Every message should only make sense for this one lead. Name and company alone fit anyone, so each sending step carries the signal the list was built from:
+
+- Hiring lists: say what they are hiring for. "Saw {{company}} is hiring an {{matched_job}} in San Francisco" beats "saw you're hiring". Use the job title column the source returned, and connect it to why your offer matters for that hire.
+- People who posted about a need: refer to what they actually wrote, in a few words. "Your post about replacing your sales tool" beats "your recent post".
+- Role or company lists (VPs of Sales at YC startups): use what is specific to them, such as their batch, what the company sells, its stage or team size, or something they shipped.
+
+Make these slots AI variables when the raw value is long or messy. Add an AI column per slot that writes one short phrase from that row's evidence only, for example `hiring_angle` (the role and why it matters), `post_topic` (what the post asked for, in five to eight words) or `opener` (one sentence a human would write). Give it a fallback answer for rows without evidence. Run it on one pilot row, read the output, then run it on the qualified rows and reference the column in the steps as `{{hiring_angle}}`, `{{post_topic}}` or `{{opener}}`. Never paste a raw headline or a whole post into a sentence, and greet with `{{first_name}}`, never the full name.
+
+Use conditions to keep the wrong people out and the right copy in. Filter enrollment on the signal and the evidence the copy needs: every Required criterion column passes, a title family matched with contains or in (never one exact title string), the signal column is set (the job title, the post topic, the opener). When different groups need different angles (founders versus sales leaders, hiring versus posting), filter each group into its own sequence or saved view rather than one message that tries to fit both.
+
+Each follow-up brings a new reason to reply (a relevant result, a short resource, an easy question), not "following up" on the first message. Read every step side by side before publishing: if two steps say the same thing, rewrite the later one. If a step would read the same for any company, it is not done.
+
+## Check the copy like a reviewer before publishing
+
+Before publishing or enrolling, preview at least three different real rows, including one with the thinnest evidence, and judge each rendered message as pass, tighten or block:
+- Block: an unresolved or empty variable, a claim the row does not support, a fact about the lead that is wrong, or anything that reveals how they were found.
+- Tighten: the message would read the same for another company, the opener is generic, a follow-up repeats an earlier step, the ask is unclear, or it runs long.
+- Pass: specific to this person, grounded in their row, one clear ask.
+If the rendered messages across rows read nearly identical apart from the name, the signal slot is too thin: strengthen the evidence column or the AI step prompt, not one row's copy. Fix every block and tighten, preview again, and say in the report what you checked.
+
+## A/B testing
+
+When a step writes with AI, it can test variants: vary either the angle (the overall approach) or the opener (only the first line), not both, and keep each variant a genuinely different idea rather than a paraphrase. Turn on automatic winner promotion when the user wants the sequence to keep the better variant on its own. Read the results per variant before changing copy, and change the losing variant, not the whole sequence.

package/agent-plugin/plugins/dreamstate/skills/outreach/replies.md

@@ -0,0 +1,5 @@
+# Replies
+
+A reply, bounce, unsubscribe, suppression or decline ends the sequence for that person. Read the whole current thread before drafting an answer, and answer what they said instead of restarting the pitch.
+
+A conversation status is not proof a message was delivered. After an unclear send result, check the conversation before sending again.

package/agent-plugin/plugins/dreamstate/skills/outreach/steps-and-timing.md

@@ -0,0 +1,13 @@
+# Steps and timing
+
+Authorable steps are an email, a LinkedIn connection request, a LinkedIn message and a Slack message; read the step schema for the exact shape. There is no standalone wait step: set the delay on the sending step that follows the earlier touch. A LinkedIn message never sends an invite. To reach someone who is not connected, put a connection request step first (after a profile view when there is one), then the message steps; a message waits until the request is accepted. Leave the connection request note empty by default: a blank invitation is accepted more often and the message after acceptance does the talking. Write a note only when the user asks for one. Skip the connection request only when the audience is already connected (first-degree) or an earlier step waits for the person to connect. Fetching the profile happens on its own, so never add fetch-profile steps. Timing is part of a sending step.
+
+Typical cadence: three to five touches over two to three weeks, two to five days apart, mixing channels when both are available. An email follow-up reads best as a reply in the same thread. Put the strongest message first, and make the last touch an easy way to close the loop.
+
+A reply, an unsubscribe or a failed send ends a lead's run on its own, so do not add a condition that only checks reply state. Sequence conditions may branch on worksheet-row variables, such as `fit_score`, `title`, or `first_name`, using `expression` plus both `true_step_id` and `false_step_id`. Keep reply as stop. Never refuse whole build over one step.
+
+Build the whole sequence in one pass when you know every step. Add, edit, remove or reorder a single step when the user asks for a narrow change, and leave the rest alone. Read the real step settings before writing them rather than guessing field names or time units.
+
+After every change, validate, fix every real error and validate again. Read the saved sequence back before saying it is ready.
+
+Delivery is paced by sending hours, per-account cooldowns and daily caps, so a start is never an instant blast. Enrichment for enrolled leads runs only while the sequence is active.

package/agent-plugin/plugins/dreamstate/skills/outreach/stop-and-suppression.md

@@ -0,0 +1,7 @@
+# Stops
+
+Unsubscribe, do not contact, bounce, wrong person, decline and a finished conversation all end outreach to that person on every channel. Do not reach them through another sender, another sequence or another channel.
+
+A stop means automation halted, not that a reply went out. After an unclear stop or send result, read current state before retrying.
+
+When a CRM list stays in sync, new members become blocked automatically and members who leave stay blocked.

package/agent-plugin/plugins/dreamstate/skills/plays/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: plays
+description: "Recommend and run one named, proven go-to-market play when the user asks what to do next, picking by stage and what the workspace already has, and stating prerequisites, credit estimate and checkpoints before starting. Use it for \"what should I do\", \"how do I get leads\", \"help me start outbound or content\", or a weekly review. It does not replace the skills each step uses (knowledge, list-building, outreach, social, writing, visibility, workflows)."
+---
+
+Run this through the Dreamstate MCP tools: `packs_get` for the pack's capabilities, `tools_get` for the exact input schema, then `tools_run` (`dry_run` first for anything that writes, spends credits or reaches a person). If the server asks you to sign in, approve it in the browser.
+
+# Plays
+
+## Boundary
+
+- Owns: picking and running a named proven play.
+- First session in a fresh workspace: [`first-win`].
+- The `sequence` pack lists the tools and their exact inputs.
+
+A play is a proven order of ordinary steps aimed at one business outcome. It teaches order and judgment; each step still runs through its own skill and tools with their normal rules.
+
+## Backing packs
+
+A play has no pack of its own. It routes across packs: brain for Company Context, workbook for lists, sequence for outreach, inbox for replies, social for posts, visibility for analytics, workflows for automation. Use packs_list to see which are available, then packs_get only for the pack the current step needs.
+
+## The invariant
+
+"What should I do?" gets one named play with a reason, not a menu. When the user names a play, run that play. The play is shaped by the workspace's real state (Company Context, connected accounts, existing worksheets, sequences, drafts and analytics), not a generic default. Lists, warm leads and scores always live in a worksheet: a row source, evidence columns, an AI judgment column and a score. There is no separate leads feed.
+
+## Practice
+
+1. **Read the workspace.** Search first for three free, state-aware blueprint recommendations. That read uses registry requirements plus connected LinkedIn accounts, mailboxes, worksheets and credit posture. For one candidate, read the exact describe result the recommendation names next. Then read Company Context (Ideal Customer, Offer, Tone of Voice), connected LinkedIn and X accounts, existing worksheets, sequences, drafts and analytics freshness. Reuse what exists; never rebuild a worksheet or sequence that already does the job.
+2. **State the plan.** Steps in order, what each produces, the credit estimate for paid steps, and the checkpoints where the user sees real output. Credits are the consent: state the estimate, then proceed.
+3. **Run it step by step,** loading each step's skill with skills_get. Build everything buildable even when an account is missing, then name what to connect.
+4. **Show before it leaves.** Final copy of every message or post before anything sends or publishes, and say so before switching on any daily schedule.
+5. **Close with the leading metric** and when to check it.
+
+## Catalog
+
+**Inbound-led outbound** (inbound-led-outbound). People already paying attention become conversations.
+- Worksheet sources: reactions and comments on the user's own recent posts or on posts by people they pick, followers and connections, profile viewers. One source per worksheet.
+- AI judgment column: fit against the Ideal Customer page, level high, medium or low with a one-line reason from the headline and company. Run a sample first, read the top rows with the user.
+- Sequence to the high-fit rows only, chosen by a column filter, a few new people a day, already-contacted people excluded. The first message opens on the shared topic and never says you saw them react, follow or view.
+- Metric: good fits per sample, positive replies per ten messaged.
+
+**Signal-based outbound** (signal-based-outbound). One ranked list each morning of the warmest people engaging with the user's content.
+- One worksheet with the engagement sources: post engagers and new followers first, then profile viewers when connected.
+- AI judgment column scoring fit plus how recent and how strong the engagement was; sort best first.
+- Refresh every morning so new people land and only new rows run the criterion columns. Say before switching it on.
+- Each morning: the top five to ten with what they did, when, and an honest first line built on a true fact.
+- Metric: warm people contacted from the list, replies they produce.
+
+**What should I post?** (founder-posting-system). Regular LinkedIn posts in the user's own voice.
+- Learn the voice from the account's past posts; posts that drew comments are the best examples.
+- Draft a few posts or plan a week of different kinds (customer story, contrarian take, build in public), each with one concrete point, who it is for, and a call to action.
+- Schedule each for the user to approve one by one; nothing publishes unapproved.
+- After publishing, read back how each did and write more like the ones that got comments.
+- Metric: posts published per week, then comments from people who could buy.
+
+**Analyze my social media** (social-performance-review). What works and what does not.
+- Read stored analytics first and state freshness; if data is missing or stale, say which account and why.
+- Totals and trend over the period against the previous one, best and worst posts against the user's own median, follower change.
+- Patterns: themes, formats, length, hooks, posting days and times that win or lose, each backed by the posts that show it.
+- End with three concrete experiments for next week.
+- Metric: the metric the workspace optimizes for, week over week.
+
+**TAM sourcing** (tam-sourcing). About 25 companies that look like the best customers, graded with a reason, or a list the user shares graded instead. Company search or the shared list as the source, an AI fit grade, then name which kinds of company fit best.
+
+Other plays when the state calls for them: first win on a fresh workspace, reply to meeting when replies wait, visibility sprint for search and answer engines, weekly review of any live motion.
+
+## Guardrails
+
+- Never run two plays against the same audience; the same person would be touched twice.
+- Anything sent externally (posts, DMs, emails) is shown with final copy before the send step.
+- A play is not mandatory architecture. Skip or reorder steps whose output already exists.
+
+## What to return
+
+- The play and why, the step plan with credit estimates.
+- As it runs: what each step produced, with links, read back from results.
+- Missing accounts, the leading metric to watch, and the natural next play.
+
+## Check it works
+
+Done means checked, not built. Before you report, read back everything you made or changed, and run, test or preview it where that is offered; publish or send only when the user asked. An empty, failed or wrong result means an input or setting is wrong: find which from the error or the output, correct it and check again, until it is right or a real blocker stops it. Report what you checked and what it showed.