@trydreamstate/cli 1.2.0 → 1.3.0

package/agent-plugin/plugins/dreamstate/skills/reddit-posts/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: reddit-posts
+description: "Draft Reddit posts the user posts themselves: subreddit choice and rules, the title, a value first body, disclosure, post types (success story, guide, resource list, problem solving, behind the scenes, question), and what gets posts removed. Use it for the copy of any Reddit draft. It does not cover scheduling or automations (social 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.
+
+# Reddit posts
+
+## Boundary
+
+- Owns: Reddit post and thread copy the user posts themselves.
+- Post lifecycle, review, and publishing: [`social`].
+- The `social` pack lists the tools and their exact inputs.
+
+Reddit is draft only: you write the title, the body and the target subreddits, and the user posts it themselves. Reddit punishes anything that reads like marketing, so write every draft as a real member of that community would.
+
+## Pick the subreddit, then respect it
+
+Match subreddits to where the topic and register fit, not to size: a founder sub reads differently from a practitioner or general discussion sub. Mirror the community's language without copying posts. Tell the user to check each sub's rules and recent top posts before posting: karma minimums, required flair and self-promotion rules vary, and some subs ban self-promotion outright. With low or unknown karma, write pure value and no self-promotion.
+
+## The title carries the hook
+
+Front-load the outcome, claim or question, never setup. Maximum 300 characters, aim for 60 to 120. Patterns that work, always with real numbers the person gave you: a big specific number, a story hook, a lesson count, a direct ask ("Roast my landing page"), a problem and its fix. No clickbait, hashtags or emoji. Do not repeat the title as the first line of the body. If the body's focus changes, change the title.
+
+## Body: hook, value, soft close
+
+- **Hook** (2 to 3 sentences): the most compelling point and a specific number.
+- **Value** (the bulk): deliver everything the title promised, in full, with specifics. Give the whole playbook, not a teaser.
+- **Soft close**: invite the conversation. Mention the person's own product only if it is genuinely relevant.
+
+## Value first, never a pitch
+
+At most a tenth of the post may touch the person's own product, and only naturally. Lead with the problem, never the product name. When the product is mentioned, disclose it plainly ("I built a tool for this"); never pose as a neutral recommender. No links in the body: describe the tool and offer details in the comments.
+
+## Voice
+
+Contractions always. Mix short and long sentences, and never start three sentences the same way. Include one specific, unrounded detail only someone who did the thing would know ($4,217, the tool that failed, the moment of doubt). No em dashes, en dashes or double hyphens. No emoji or hashtags unless asked.
+
+## Formatting
+
+Reddit markdown: bold for key points, `##` headers to break up long posts, numbered lists for steps, bullets for items. Paragraphs of 2 to 3 sentences. Add a TL;DR to anything over 500 characters.
+
+## Post types
+
+Follow the format the person named. Otherwise pick from what they have:
+
+- **Success story** (a real milestone): open on the struggle or turning point, the win lives in the title. What failed first, the tactics with trade-offs, unrounded before and after, what still has not improved, 3 to 5 lessons, a question.
+- **Guide** (a repeatable process they have run): the outcome and the common mistake, numbered steps each doable without more research and naming the exact tool, real pitfalls, an offer to help in the comments.
+- **Resource list** (tools they actually used): selection criteria and how much they tested, items under headers with use, cost, one pro, one con, and who it is not for, plus 2 to 3 honest rejections.
+- **Problem solving** (a named problem and a replicable fix): the problem and its cost, what did not work, the approach that worked with a timeline, results, the limits of their context.
+- **Behind the scenes** (the building process): current state, real numbers including unimpressive ones, the real setbacks, decisions and why, a real question.
+- **Question or discussion** (they want input): their own experience first and at length, why they are asking, one specific open question that is not searchable, a promise to reply.
+
+## What gets posts removed or downvoted
+
+Round or invented numbers, a thin wrapper around a pitch, missing flair or disclosure, humble bragging, generic advice with no numbers, and phrases like "delve into", "unlock", "leverage", "game-changer", "in today's world". Remind the user that the post works only if they stay and reply to every comment for the first few hours, critical ones included.
+
+## Editing a draft
+
+Keep untouched sections and markdown exactly. Edit at the phrase level instead of rewriting. Shortening cuts content and keeps the structure. Never invent facts or numbers.
+
+## Check it works
+
+Read the saved draft back: the title is under 300 characters and matches the body, subreddits are set, there are no links or em dashes, and self-promotion is disclosed and small.

package/agent-plugin/plugins/dreamstate/skills/skill-authoring/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: skill-authoring
+description: "Read, edit and create this workspace's skills, the editable Markdown playbooks agents and people follow, keeping each one short, revision safe and in the workspace's own words. Use it when the user wants to change how a skill works, capture a repeatable practice as a new skill, or fix a skill that reports issues. It does not change what an agent is allowed to do (a skill grants nothing) and does not edit Company Context pages (knowledge 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.
+
+# Skill Authoring
+
+## Boundary
+
+- Owns: workspace skill playbooks.
+- Company Context and wiki pages: [`knowledge`].
+- The `knowledge` pack lists the tools and their exact inputs.
+
+Skills are this workspace's editable Markdown playbooks. People edit them on the Skills page and agents edit the same pages, so a change made by either is what both follow next. A skill is guidance: it grants nothing, binds no tool and changes no permission.
+
+## The invariant
+
+Every change lands on the current revision and is reported back. Never overwrite a revision you did not read, and never leave the user guessing what changed.
+
+## Read
+
+1. Find a skill with skills_list query before reading it. The result ranks lexical matches and names matching documents; omit query only to inspect the complete catalog, workspace copies and issues.
+2. Read one with skills_get. The response carries the full Markdown, parsed frontmatter, supporting pages, document index and current revision.
+3. Read a supporting page only when the task needs it.
+
+## Edit
+
+1. Read the skill with skills_get immediately before writing.
+2. Follow its `edit` descriptor: read the named tool's schema with tools_get, then run it with tools_run, passing the document, the revision from that read and the complete new Markdown in the named content field. The save replaces the whole page, so send the full text, frontmatter included.
+3. Change only what the user asked for. Keep the frontmatter name equal to the folder name.
+4. On a revision conflict, someone else saved first. Re-read, merge your change into their text and save again on the new revision. Never resend the old text over theirs.
+5. When `edit` is null an existing starter skill is still a repo default for this workspace. Read skills_list again shortly; the workspace copy appears once seeding finishes. This applies only to starter skills, never to a skill you just created.
+
+## Create
+
+1. Check skills_list query first; if a skill already covers the need, add a section to it instead.
+2. Follow the `create` descriptor from skills_list, step by step, with tools_get then tools_run for each step. Send every param the descriptor fills in exactly as given. The first step names `parent_folder_id` explicitly and returns the new folder id that the second step needs.
+3. Use a kebab-case id such as `pricing-objections` for the folder, and write SKILL.md with frontmatter `name` (the same id) and `description` (one sentence: what it does, when to use it, what it does not cover). A skill is plain Markdown and grants no tools, so it needs no tool list.
+4. Run the descriptor's `verify` read: skills_get with the new id. The skill is created only when that read returns it. Fix every issue it reports.
+5. Skills are read live, so there is no indexing delay. If skills_get says not found, the skill does not exist yet: never report it created or verified.
+
+## Shape of a good skill
+
+- One thesis line, the invariant, a short numbered practice, guardrails, and what to return.
+- Keep SKILL.md to about 5 KB. Put detail, examples and edge cases in supporting .md pages in the same folder and say when to read each one.
+- Teach practice, not tool grammar. Describe the task and let tools_search and tools_get supply exact names and fields.
+
+## Guardrails
+
+- Never delete or rewrite a starter skill unless the user asked for that. Prefer adding a new skill or a new section.
+- Remove a skill only on an explicit request, following its `remove` descriptor; say that it can be restored from trash.
+- A skill cannot widen what an agent may do. Do not write one that claims to approve spend, sends or permissions.
+- Do not copy secrets, credentials or customer personal data into a skill.
+
+## What to return
+
+- Which skill changed or was created, with its path and new revision.
+- A short summary of what changed and why, in the user's words.
+- A link to the skill on the Skills page, and any issues still reported.
+
+## 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/social/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: social
+description: "Own a short-form social post for its whole life across connected channels. Read the channel registry and learned brand voice, draft and revise, submit for review, approve, schedule or reschedule, publish now, unschedule, and archive."
+---
+
+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.
+
+# Social
+
+## Boundary
+
+- Owns: short-form social post lifecycle, review, and publishing.
+- LinkedIn post copy: [`linkedin-posts`].
+- X post and thread copy: [`x-posts`].
+- Reddit post copy: [`reddit-posts`].
+- Articles and landing copy: [`writing`].
+The `social` pack lists the tools and their exact inputs.
+
+## Delete and archive
+
+When user says delete a social post or draft, delete it permanently from Dreamstate. Show deletion impact first unless user already explicitly asked to delete. Delete removes local drafts, scheduled deliveries, and published-post records. Scheduled posts are unscheduled first. It never deletes provider posts from LinkedIn or X. When user says archive, archive only. Never say deletion is unavailable.
+
+<!-- architect-operation-contract
+{"required_capability_ids":[]}
+-->
+
+## Draft posts
+
+One post is one draft that can go to several channels and several accounts at once. When the user asks for the same post on LinkedIn and X (or Reddit), create one draft whose channels list holds every channel, and put per-channel copy in that channel's payload: an X thread, a LinkedIn body, a Reddit title and subreddits. Never create one draft per channel for one request. A channel can carry several accounts (two LinkedIn profiles, or a company page and a personal profile); bind the accounts the user named, and when they said "all accounts" bind every connected account for that channel.
+
+Before drafting or scheduling, inspect connected accounts for every requested platform and whether per-post auto-engagement is available. When more than one account is connected for a platform and the user did not name an account or say all accounts, ask which named account should post. When post request is vague, also ask what type to make, offering concrete choices such as story, how-to, opinion, announcement, or carousel. When auto-engagement is available and user has not decided it, ask whether to turn it on. Put every unresolved choice in one concise question with named account and post-type choices, never an open-ended prompt. A specific request with one connected account proceeds without questions, including no auto-engagement question.
+
+A content plan is a set of drafts, each with its channels and an optional planned date. There is no weekly plan object and no workbook or other container for a plan.
+
+Read the saved Company Context first, and the account's brand voice when one exists. When there is no account or no brand voice, write from the Tone of Voice page and say so. A missing account never blocks drafting.
+
+Write with the channel skills: `linkedin-posts`, `x-posts` and `reddit-posts` hold the craft for each channel (hooks, structure, length, post types, closes). Read the one for every channel on the draft before writing its copy. The workspace can edit them, so follow the workspace copy.
+
+Each request gets a new draft. Revise an existing draft only when the user names it or asks to change it.
+
+Drafting needs no review, approval or human step. Match the stored voice. No em dashes in post copy.
+
+Before scheduling, resolve every @mention for each channel. People and companies can be mentioned on LinkedIn and X. Never send unresolved mention text to a provider. It publishes broken public text and cannot be edited back on every channel.
+
+Read the channel registry before writing. Per-channel max_content_length is registry data. Never assume a limit. X length is weighted (a link counts 23) and each thread post is checked on its own. Reddit is draft only: write the title, body and subreddits; the user posts it.
+
+For LinkedIn, the last line must open with an ask verb or be a question addressed to the reader. Refuse the write with `linkedin_cta_required` when the close fails the rule.
+
+## Automations
+
+Per-post auto-engagement lets the workspace's connected accounts like, comment or repost after the post publishes. When the user asks for it ("add all our accounts as auto engagers"), do it: list the connected accounts, bind every account they named (or all of them), pick sensible defaults and save. Defaults: likes from every account; one comment per account, written by you in that account's voice, specific to the post and different for each account, never generic praise; stagger each account a few minutes apart instead of all at once. The post's own author does not like or comment on its own post. Report the accounts, actions, delays and exact comment copy you saved, so the user can change any of it.
+
+Keyword auto-DM rules attach to a post. A comment containing the keyword gets a DM to the commenter and can get a public reply. Write the DM and reply copy yourself from the post and the offer; keep the DM short and deliver what the post promised.
+
+Amplification is a standing workspace policy that engages from other people's real accounts and spends credits. Create it disabled, and arm it separately after scope, participant accounts, actions and credit ceiling are set.
+
+These automations run only when the post publishes. Setting them up sends nothing.
+
+## Schedule and publish
+
+Scheduling is separate from drafting: schedule only when the user asks. Publishing is outward delivery. Decide by judgment whether to confirm first; when the user already asked to publish, publish. There is no system approval step.
+
+Resolve one explicit IANA timezone. Convert requested local time once into one timestamp for every channel. Never reinterpret “morning” per channel.
+
+Read the saved draft, schedule or delivery result before reporting it done. When you change one channel of a post, send only that channel's copy, then read the post back and compare every other channel with what it was before your change; if any channel lost or changed copy you did not mean to touch, restore it before you report. Never say another channel is unchanged without reading it back. Never claim a result from the request alone.
+
+## 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/visibility/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: visibility
+description: "Get found by search engines and answer engines. Pick the query set, gather crawl, index, mention and citation evidence, fix pages, then measure the change."
+---
+
+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.
+
+# Visibility
+
+## Boundary
+
+- Owns: choosing queries and measuring search and answer-engine visibility.
+- Drafting and publishing articles: [`writing`].
+- The `visibility` pack lists the tools and their exact inputs.
+
+<!-- architect-operation-contract
+{"required_capability_ids":[]}
+-->
+
+Improve discoverability and qualified organic traffic in traditional search and in generative answer engines, as one practice. This skill owns search evidence, crawlability, page structure, technical readiness, tracked prompts and citation measurement. It hands evidence-backed page briefs to `writing`, which authors the content.
+
+## Operating contract
+
+```operating-contract
+actions: []
+```
+
+Read measured evidence, propose prioritized changes, and treat paid or asynchronous measurement as bounded work: show scope and cost, then run it with credits as consent. Before a sensitive change, show the evidence and the exact change. Knowledge owns business facts; writing owns content changes.
+
+## Loop
+
+1. Resolve the exact site, then read brand, audience, conversion goal and competitors.
+2. Check the search connection before using its data, and keep property, date range, freshness and completeness with every number. See search-evidence.md.
+3. For a named page, inspect that page now; never assume an earlier audit still describes it. See technical.md.
+4. Before adding prompts, read the tracked query set and its status. See query-sets.md.
+5. Start a new probe only when the user wants new engine observations; a metric refresh recomputes existing ones. See probes.md.
+6. Prioritize by business impact, effort, confidence and dependency, and state every assumption.
+
+## Evidence rules
+
+- An observation is what a capability returned for a stated window; everything else is inference. Say which is which.
+- Movement claims compare a window with the preceding equal-length window. Missing rows do not prove rank zero.
+- Each technical check answers its own question; one passing check is never an overall health claim.
+- A scan or refresh may spend credits or run asynchronously. Wait for its terminal state: a queued scan is not a result. Refresh only when existing evidence is too stale for the decision.
+- Crawler fetches, AI referral traffic and probe recommendations are separate evidence; never fold them into one claim. Absent crawler evidence is not proof of blocking.
+- A generated proposal for a site file is a reviewable draft; generating it neither installs nor proves it was read.
+
+## Exact denominators
+
+Prompt visibility is citations or qualifying mentions divided by completed runs for that exact prompt, engine set, locale and window. Report run count, citation count and percentage together. Zero citations over zero runs is unavailable, not 0%. Weight averages by their denominators and never merge engines, locales or windows silently. Sentiment uses its own total. Citation share, mention rate and referral traffic are distinct and never one score.
+
+The tracked query set is a revisioned instrument: changing a prompt's wording breaks the comparison, so change it deliberately and disclose the break.
+
+## Handoff to writing
+
+A brief names the target query and intent, the evidence window and property, current and previous performance, the destination page or a new page, observed competing results, the conversion goal, internal links, and evidence gaps. When an existing page owns the intent, request a revision instead of a duplicate.
+
+## Done
+
+One report covers search and answer engines: site and property, window, freshness and completeness, measured findings, assumptions, prioritized actions, query set revision, engines covered, completed versus expected runs, denominators, and the weakest prompts by name. Never claim an improvement until a later equal-scope measurement shows it. When blocked, say what is missing, what was already measured, and the one read or decision that unblocks. Read back what you changed before reporting.

package/agent-plugin/plugins/dreamstate/skills/visibility/probes.md

@@ -0,0 +1,15 @@
+# GEO probes
+
+## New observations versus recomputation
+
+Search for the capability that starts a new probe run to obtain new engine answers for active prompts, as distinct from the capability that recomputes aggregates from observations already present. A refresh cannot discover a citation the engines were never asked to produce, and a probe should not be spent merely to recalculate a dashboard.
+
+Before a new probe, read tracked-prompt status, active count, query-set scope, last probe time, and exact current capability contract. State engines, locales, expected run count, cost, and approval boundary. Use only engines the installed runtime reports as active; an enum accepted by a schema is not proof that a provider is supported or configured.
+
+After start, preserve the batch id. Poll status or today's run ledger without launching another batch. Completion means expected and completed terminal runs reconcile, or the provider returns an explicit bounded/partial terminal state. Read per-prompt results and metrics only after that. A queued, inflight, or partially completed batch is not a new baseline.
+
+## Evidence and recommendations
+
+For every reported prompt retain prompt id and text, engine, locale, run time, whether the brand was mentioned, whether it was cited, cited domains, sentiment when available, and source evidence. Rank opportunities by meaningful weak demand, competitor citation gap, evidence freshness, and a plausible page-level intervention, not by the aggregate score alone.
+
+Never attribute a citation to an engine that was not queried. Never infer absence from a failed run. Preserve provider-bounded, stale, truncated, and empty states exactly and continue pagination when the question requires complete coverage.

package/agent-plugin/plugins/dreamstate/skills/visibility/query-sets.md

@@ -0,0 +1,17 @@
+# GEO query sets
+
+## Construct from real demand, not a generic prompt list
+
+Build candidate prompts from distinct evidence streams: product/category language, ICP jobs and objections, Search Console queries already gathered elsewhere in this skill, competitor comparison questions, and high-intent buyer decisions. Record the source for each prompt. Balance prompt types across discovery, problem understanding, category education, comparison, evaluation, and purchase intent; a set made only of branded prompts measures recall, not market visibility.
+
+Every prompt must be natural enough that a real buyer could ask it, specific enough to have a stable intent, and scoped to language and country. Avoid near-duplicates whose only difference is punctuation or a synonym. Include unbranded prompts that give every credible competitor a fair chance to appear.
+
+## Prepare, review, save
+
+Search for the capability that prepares candidate prompts; it does not persist them. Review candidates for duplicates, leading brand bias, unsupported locales, and coverage gaps. A separate capability persists the chosen batch, another adds one explicit prompt, and another revises one exact prompt, each discoverable by its own input schema. Read the set back after saving and report the stable ids and active count.
+
+Do not generate a new set because metrics are weak. Weak results may be the finding. Revise the measurement instrument only when audience, market, language, product, or question taxonomy changed, and record the reason and effective date.
+
+## Version and comparison rules
+
+Treat additions, removals, activation changes, wording changes, locale changes, and engine coverage changes as query-set revisions. Compare trends only across the unchanged intersection or label the result as a new baseline. Never splice old results for retired wording into a new prompt's history.

package/agent-plugin/plugins/dreamstate/skills/visibility/search-evidence.md

@@ -0,0 +1,15 @@
+# Search evidence
+
+## Search Console first principles
+
+Check connection state before asking for data the provider can answer. A disconnected, expired, or unbound property is a typed blocker, not permission to estimate. Once connected, use the exact selected property and date window in every reported metric.
+
+For current-versus-previous claims, use adjacent windows of equal length and preserve query, page, country, device, clicks, impressions, CTR, and average position as returned. CTR denominator is impressions. It is invalid to compare CTR values without also showing impressions, because a large swing on a tiny denominator is weak evidence. Average position is an impression-weighted observation, not a fixed rank held all day.
+
+Do not blend Search Console rows with a SERP snapshot as one metric. Search Console is property performance aggregated over a window; a SERP snapshot is one observed result set for a query and locale. Use both when useful, label them separately, and never use a snapshot to fabricate historical movement.
+
+## Prioritization
+
+Favor queries where intent matches the conversion, evidence is current, the site already has impressions, and a specific page can own the answer. Striking-distance positions can be efficient, but only when the page satisfies intent and impressions provide a meaningful denominator. Net-new topics may still be valuable; label volume and outcome assumptions instead of laundering them into observed data.
+
+Every recommendation should state the evidence, assumption, expected mechanism, leading indicator, and review date. For example, a title rewrite is expected to affect qualified impressions and CTR before conversion, while an indexability fix should first affect valid indexed coverage.

package/agent-plugin/plugins/dreamstate/skills/visibility/technical.md

@@ -0,0 +1,16 @@
+# Technical SEO
+
+## Diagnose by layer
+
+- Discovery: sitemap and internal links expose the URL.
+- Crawl permission: robots and bot controls allow the intended crawler.
+- Fetch and render: status, HTML, canonical, and rendered content are usable.
+- Indexability: directives, canonical target, duplication, and page quality support indexing.
+- Experience: page-speed and field/lab evidence identify performance constraints.
+- Search presentation: title, description, headings, and structured data match the page intent.
+
+Read the specific layer that could explain the symptom. A clean robots file does not prove indexability; a fast page does not prove discoverability; an llms.txt file does not improve traditional rankings by itself.
+
+For every issue retain URL, check id, observed time, evidence excerpt or metric, severity, affected scope, and confidence. De-duplicate symptoms that share one root cause. Rank fixes by impact and dependency so a sitewide canonical bug precedes individual title polish.
+
+Scans and refreshes are durable operations. Do not claim completion from the start receipt. Read the terminal run and exact findings, and preserve partial, errored, or provider-bounded states rather than filling gaps with generic audit advice.

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

@@ -0,0 +1,43 @@
+---
+name: workflows
+description: "Best practices for building and running automations that are not outreach sequences: frame the job, smallest graph, validate after every change, runtime inputs, safe recovery of failed runs."
+---
+
+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.
+
+# Workflows
+
+## Boundary
+
+- Owns: automations that are not outreach sequences.
+- Multi-step outreach sequences: [`outreach`].
+- Explaining failed or stuck runs: [`diagnostics`].
+- The `workflow` pack lists the tools and their exact inputs.
+
+## Practice
+
+Best practices for building and running automations. The workflow pack lists the tools and their exact inputs; this skill is how to use them well. Outreach cadences to people are sequences, covered by the outreach skill. Everything else is a workflow.
+
+1. Build new unless asked. A new request gets a new automation built from scratch. When the user names an existing one to change, resolve that name among existing automations by listing workflows and sequences with that name as the search text, then change the match. A named thing that is not a workflow or sequence may be a task, a record or a worksheet; check those only after automations come back empty. A step inside a workflow, such as a task step, is edited in that workflow's graph, not in the task list.
+1a. "Enroll these in a workflow" is never a missing input. Use a workflow whose table trigger is the worksheet the user is looking at, or one they named; otherwise build a new draft for that worksheet (worksheet rows trigger plus fitting steps, a follow-up task per person by default), validate, and enroll. Never ask which workflow.
+2. Frame the job before building: what triggers it, who or what it acts on, what it changes, what it costs, when it stops and how often it runs.
+2a. Use a blueprint when one does exactly what you need; otherwise build your own. Workflow blueprints already cover common jobs: CRM syncs, list and do-not-contact syncs, routers, digests and signal monitors. List blueprints of the workflow kind, read what the closest one creates and what it still needs, install it, then adapt it to this request. Installing never needs answers or connections; the result names what is still to pick, so say that. Build from scratch only when no blueprint fits, and say which one came closest.
+3. Ask one clarifying question only when a required input is missing. Otherwise build with sensible defaults and say what you assumed.
+4. Build the smallest graph that delivers the result. Build the whole graph in one pass when you know every node. Add one node at a time when exploring, and read each result before the next.
+5. Read a node's real settings before writing them and use real workspace options. Never invent variable syntax, node ids or field names. Conditions point at real worksheet columns.
+6. A value that changes on every run becomes a runtime input, not a hardcoded setting. When a value should come from the trigger, the triggering record or an earlier step, list the variables for the graph you are about to save, passing the draft graph itself when nothing is saved yet, and use a listed token. Never save an empty or null value for something the user asked for; say which variable is missing instead.
+7. Validate after every change. Fix every real error and validate again. Never call a workflow ready until validation is clean and the saved graph shows every requested node and path.
+8. Building never waits on connections. A missing Slack, email or other connection blocks activation only. Build, edit and validate anyway, then name the connection to add.
+8a. Building never waits on rows. A worksheet trigger on an empty or still-filling worksheet is still a valid enrollment: build, validate and turn it on, and rows enroll as they land. Say it is waiting for rows, never stop because the worksheet is empty.
+8b. Use the row-created trigger when each new worksheet row must enter once. It watches future row arrivals on one worksheet, carries that row identity through the graph, and does not reuse or freeze a saved selection. Use the table trigger only when user wants a selected saved-view audience.
+8c. To tag or mark a triggering row, add the worksheet-row update step. Choose its column and either replace its value or append a value to its existing list. Do not ask user to export, reimport, or manually tag rows when workflow already has triggering row identity.
+9. Decide by judgment whether to confirm before activating something that sends or spends. When the user already asked for it, do it. There is no system approval step.
+10. Draft, published, active, running and finished are separate facts. Report only what the last result proves.
+
+## 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.
+
+## 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/workflows/durable-runs.md

@@ -0,0 +1,19 @@
+# Failed runs and unknown outcomes
+
+Start from the run history, then open the trace of the one run in question. The trace is the truth for each node: its state, attempt, output, receipt and error.
+
+Take identifiers from what you inspected, never from memory or guesswork. An empty run list or a trace without a failed node means there is nothing to retry yet.
+
+How to recover:
+
+- Succeeded with a receipt: never run it again.
+- Failed before any effect: retry that node.
+- Effect definitely not applied: retry with the same idempotency identity.
+- A preview, dry run or read that timed out applied nothing: retry the same call.
+- Timeout, lost connection or missing receipt: the outcome is unknown. Check the outside system or the trace first. When the read-back shows the write absent, retry it with the same idempotency key: the server replays a key it has seen and never applies it twice.
+- Paused or checkpointed: continue from the checkpoint, not from the start.
+- An effect that cannot safely repeat and whose outcome is still unknown: stop and tell the user.
+
+A retry targets the failed node, not the whole run. Completed nodes and earlier effects never repeat. An accepted retry is not a finished run; follow it to its final result.
+
+Metrics summarize finished runs. They never repair a run and never prove that one specific effect happened.

package/agent-plugin/plugins/dreamstate/skills/workflows/graph-authoring.md

@@ -0,0 +1,9 @@
+# Building the graph
+
+Whole graph at once when the design is clear. Otherwise start empty and add one node at a time, reading the saved result after each. For a change to an existing workflow, edit only the node or setting the user named and leave the rest of the graph untouched. Remove a node by removing it, not by rebuilding the graph.
+
+Before writing a node, read that node type's real settings and the workspace's real options for any choice field, such as a channel, a worksheet or an account. Reference earlier outputs and worksheet columns only in the form the settings describe.
+
+Give every branch an explicit outcome, including the case where a value is missing. Avoid dead ends and orphan nodes.
+
+Validate after every change, fix every real error and validate again. A workflow is ready only when validation is clean and the saved graph contains every requested node and path.

package/agent-plugin/plugins/dreamstate/skills/workflows/lifecycle-and-enrollment.md

@@ -0,0 +1,11 @@
+# Lifecycle
+
+Build or edit the draft, validate, fix, publish, then activate. Publishing stores the version that will run. Activating turns the trigger on.
+
+Missing connections never block building, editing, saving a draft or validating. They block activation only. Name the exact connection.
+
+Enrollment, activation and delivery are different events. Read the result after each one. After an unclear result, check current state before retrying, and never enroll twice or replay an effect that already happened.
+
+Preview first. Activation needs `params.max_credits` on `workflow.workflows.activate`: read exact `required_caps.max_credits` from preview, then resend that value unchanged. Live enrollment takes no send cap: every eligible selected row is enrolled. The activation ceiling is a caller input, not user approval. Never guess it or ask the user to approve it.
+
+An active worksheet trigger snapshots its saved view on periodic ticks and idempotently enrolls rows that arrive later; draft, paused, and inactive workflows never refill.

package/agent-plugin/plugins/dreamstate/skills/workflows/live-replies.md

@@ -0,0 +1,5 @@
+# Live replies
+
+Read the current conversation before drafting or sending. Suppressions, consent, cooldowns and reply exits decide whether a direct message goes out. Never route around a stop through another sender or channel.
+
+No delivery confirmation means the outcome is unknown. Check the conversation and the run before sending again.

package/agent-plugin/plugins/dreamstate/skills/workflows/recipe-routing.md

@@ -0,0 +1,5 @@
+# Starting from the goal
+
+Frame the request by outcome, subject, trigger, effects, cost, exits and recurrence. If a workflow with that purpose already exists, open it and change it. If a template fits, start from it. Otherwise build the smallest graph that produces the result.
+
+Ask one question only when inspecting the workspace leaves a required input genuinely ambiguous. Never claim templates are unavailable without looking.

package/agent-plugin/plugins/dreamstate/skills/worksheet-tidy/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: worksheet-tidy
+description: "Review a workbook worksheet's structure and values, including duplicate or overlapping columns, column order, types and formatting, columns to hide, criteria and run conditions that never vary, and suspicious values, then apply reversible fixes. Use it when a worksheet has grown messy, before sharing it, or before enrolling it into a sequence. It does not merge CRM records across the workspace, rebuild the list's source (list-building does) or explain failed runs (diagnostics 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.
+
+# Worksheet Tidy
+
+## Boundary
+
+- Owns: reversible worksheet structure and value fixes.
+- Sources, columns, criteria, and building lists: [`list-building`].
+- Explaining failed runs and spend: [`diagnostics`].
+- The `tables` pack lists the tools and their exact inputs. When user says delete, permanently delete named workbook, worksheet, view, row, or column after showing removal impact and receiving explicit approval. When user says archive, archive only. Never say permanent deletion is unavailable.
+
+A tidy worksheet reads left to right like the reasoning behind the list: who the row is, what proves they fit, how well they fit, and how to reach them. Tidying makes that visible without destroying evidence.
+
+## Backing packs
+
+The tables pack owns workbooks, worksheets, rows, columns, sources and runs, and lists every tool this skill uses. CRM record merges belong to the crm pack and are out of scope here.
+
+## The invariant
+
+Prefer reversible changes. Hide before archiving, add a cleaned column before overwriting raw values, and delete only what the user named. Source evidence is never removed to make a worksheet look cleaner.
+
+## Practice
+
+1. **Read the worksheet.** Its source, every column with its type, what feeds it and what reads it, its criterion columns (Required or Nice to have) and run conditions, and a page of real rows.
+2. **Find issues by category.**
+   - **Duplicates and overlaps:** two columns answering the same question, or a copy column that only mirrors a source field.
+   - **Order:** columns out of dependency order (identity, derived facts, enrichments, criterion columns, contact data).
+   - **Types and formatting:** numbers stored as text, inconsistent dates, URLs without a scheme, mixed casing.
+   - **Hide candidates:** helper columns nobody reads, raw payloads feeding a derived column.
+   - **Dead weight:** a criterion that never varies, a criterion unsure on almost every row, a run condition that admits every row or none, a paid or AI column with no run condition.
+   - **Empty columns:** empty on every row usually means it never ran on existing rows or its gate reads an unsettled column. Hand the cause to diagnostics.
+   - **Value sanity:** titles that do not match the source filter, companies outside the ICP, the same person or company twice in this worksheet.
+3. **Present findings by category** with column names and a few example rows each.
+4. **Apply reversible fixes** the user asked for: reorder, rename, hide, retype, or add a cleaned column beside the raw one. When the user says "tidy it", apply the reversible fixes and list destructive ones (archive, delete, overwrite) separately for the user to name.
+5. **Re-run only what is needed.** If a fix needs a column to run on existing rows, show the row count and estimated credits, then run.
+6. **Read back** the structure and a page of rows.
+
+Search the workbook tool for each change. The search returns runnable schemas for its top hits; read any other ids together in one tools_get, then run. Read a column's current state right before changing it so an edit never overwrites a newer change.
+
+## Guardrails
+
+- Hidden is not archived. A hidden column is still read by columns derived from it; archiving a feeder column breaks what depends on it.
+- Do not set cell values by hand when a column run can settle them. Manual values have no evidence trail.
+- One live source per worksheet. A second kind of search gets its own worksheet in the same workbook.
+- Paid cleanup (an AI column that normalizes values) is a new column with its own estimate, never an overwrite.
+
+## What to return
+
+- Findings by category with example rows.
+- Changes applied, each marked reversible, with how to undo it.
+- Destructive options not applied, for the user to decide.
+- Credits spent on any re-run, and the worksheet link.
+
+## 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/writing/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: writing
+description: "Draft, revise and publish articles and landing copy grounded in workspace context and a target query."
+---
+
+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.
+
+# Writing
+
+## Boundary
+
+- Owns: drafting and publishing articles and landing copy.
+- Choosing queries and measuring visibility: [`visibility`].
+- Short-form social posts: [`social`].
+- The `social` pack lists the tools and their exact inputs.
+
+<!-- architect-operation-contract
+{"required_capability_ids":[]}
+-->
+
+Own the draft, review, revise, and publish lifecycle for long-form articles and landing copy. Every factual claim traces to a workspace-wiki fact, cited evidence, or a dated external source; the voice matches what the workspace has already published; and each lifecycle step is a deliberate, verifiable state change. Traditional keyword, ranking, and generative-citation evidence belongs to `visibility`; current external evidence and durable facts about the business belong to `knowledge`. Never re-derive those measurements or restate a business fact from memory.
+
+Authoring: prepare brief, evidence ledger, novelty decision, destination, and voice; compose internally; discover owner and hydrate schema; save complete artifact; read result before showing or advancing. Unsaved long-form copy in chat is not an article. Preserve exact user-named title. A rewrite is not persisted until live result says save succeeded.
+
+## Operating contract
+
+```operating-contract
+actions:
+  - context
+  - draft
+  - get
+  - list
+  - read
+  - search
+  - update
+```
+
+Posture: context first, table first, dry run before live, inspect runs after. Read durable evidence, voice, and artifact state; propose copy only from evidence; mutate only the current revision; treat destination tests, scheduling, and delivery as consequence checkpoints. Resolve the brief, destination, and artifact; search the owner; hydrate the selected schema; inspect current state; preview final copy and delivery scope when offered; then ask only about material ambiguity or a sensitive effect. Proceed with an unambiguous draft save or revision. On refusal, a stale revision, or a failed destination, retain the draft and repair from returned guidance. Social owns short-form delivery.
+
+## Grounding is not optional
+
+A claim about the user's business needs a workspace-wiki revision, bounded workspace evidence, or a successful external evidence packet from `knowledge` with source and observation date. Writing never fetches the web. Preserve provenance, freshness, limitations, and injection warnings in the claim ledger. When no source exists, flag insufficient evidence and ask rather than filling the gap.
+
+Example: the brief wants "we grew 40% last quarter" and the wiki has no dated source for that number. Do not write the sentence. Report insufficient evidence, name the missing fact, and ask once.
+
+## Read before you write
+
+Search workspace context, prior published work, and the knowledge base for who the business sells to, what it sells, and how it wants to sound, even when the brief already names a topic and query. Match sentence rhythm, person, and CTA convention to what is already live. If an existing page already answers the brief, propose revising it. A topic and a query are not a voice. Repeat this search for every new brief in a session. See briefs.md, drafting.md, and revision-and-voice.md.
+
+## No AI-slop register
+
+Use commas, colons, hyphens, parens, or split sentences. Stock openers ("in today's fast-paced world", "it is important to note"), tricolon padding ("not just X, but Y and Z"), and a closing paragraph that restates the intro stay out. See revision-and-voice.md.
+
+## Let the owner watch it get built
+
+As soon as the article exists, first save or later revision, open a canvas onto it. Do not wait until the reply finishes.
+
+## The lifecycle is real, not narrative
+
+Discover lifecycle transition through selected schema. Read current artifact before revision, use only identifiers returned for next step, and distinguish draft, review, schedule, publish, replacement, and archive state. Show exact final content before irreversible delivery when live policy requires it. Never invent provider or external identity.
+
+Sibling capabilities (short-form social versus long-form article) can accept different values for the same-looking field. Check that exact capability's input schema every time.
+
+A scheduled drafting job may create or revise an editable draft, not deliver it. For a sensitive delivery, show the final content and exact change, then act when the user asked or confirms.
+
+Editorial review is separate from delivery. Optional workspace review records do not make content public. For a sensitive delivery, show the final content and exact change, then act when the user asked or confirms.
+
+For live-piece changes, discover selected replacement or revision path. Use destructive transition only when user explicitly wants prior live object removed. If live contract refuses replacement, retain current artifact and use returned repair path.
+
+Discover duplication and archive semantics from selected schema. Archive state does not by itself prove in-progress delivery stopped.
+
+Do not put secrets in article metadata. Inspect failed delivery before retry. Test destination when selected schema requires it.
+
+## When to stop
+
+Stop when the artifact is saved, read back, and the canvas is open, or when evidence is insufficient and you have asked. Unsaved chat copy is not an article.
+
+## When blocked
+
+Report the missing source, stale revision, failed destination, or missing publish authority; the saved draft you retained; and the next exact read or question. Publication blocked stays saved, reviewed, or scheduled as a draft.
+
+## 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.