-
Notifications
You must be signed in to change notification settings - Fork 2
crew_template_catalog
Status: catalog in progress, 2026-09-27. 79 Crew templates are installable locally: nine Finance (four core roles, Tax Export and four billing capability packs), eleven Website Growth, six other Marketing, seven Sales, five Customer Success, five Customer Support, five Product, six Operations, thirteen Engineering (seven core, three QA and three Security specialties), five GTM, and seven Shopify. The remaining Crew names in this document are proposals. The forty-nine multi-Crew Automation Playbooks below are installable chat proposals, not active automations. This document is a product map, not evidence that a customer has connected tools, completed setup, or achieved an outcome. The broader Dominion deployment remains pending.
Use category for the team or business function, use case for the customer's concrete job, Crew template for a reusable agent capability, and Automation Playbook for a proposed multi-Crew journey. One Crew can hold several compatible capabilities. A Playbook can reuse existing Crews; installing it does not create them or start a run. See how setup and activation work.
Product target: A Crew does the recurring work a person would do using the customer's existing SaaS: read signals, investigate exceptions, prepare decisions, coordinate owners, and verify outcomes across tools. The template specifies the human job and its first reviewable result. Existing systems remain the sources of record and, when authorized, the places where approved actions happen. A strong template names its input systems, decisions, handoffs, approval boundary, and proof of completion. Prioritize cross-tool jobs with an accountable owner over standalone features such as generic PR review, vulnerability scanning, or test generation.
| Browse category | Boundary and customer use cases | Installable Crew templates | Planned roles or packs | Relevant installable Automation Playbook |
|---|---|---|---|---|
| Finance | Subscription billing exceptions; overdue and failed-payment recovery; finance performance; close reconciliation; vendor spend; invoice intake; tax export and payment disputes. Owns money records and financial review, not sales contact. | 9 templates: 4 core roles, Tax Export, 4 billing packs | 3 later roles | Finance Operations Review; Invoice Intake to Reviewed Payable; Refund Request to Reconciled Outcome; Subscription Receivable to Verified Outcome; Dispute to Reconciled Outcome |
| Marketing → Website Growth | A new or existing site needs relevant traffic: audit, buyer questions, SEO, content, reviewed publication, distribution, conversion, and measurement. | 11 | 0 in this subcategory | Website Growth Loop; SEO Intelligence for focused search review; AI Visibility Intelligence for sampled answer citations |
| Marketing → Other Growth | Competitive positioning, campaign analysis, SaaS conversion, experiment design, verified launch and outcome review. | 6 | 0 | Campaign Signal to Reviewed Experiment; Funnel and Conversion Intelligence; Growth Experimentation and Follow-Through |
| Sales | Qualify inbound interest, prepare calls and proposals, review pipeline movement, and decide permitted trial assists. Owns prospect qualification and contact. | 7 | 0 | Inbound Lead-to-Meeting Review; Discovery to Reviewed Proposal; Pipeline Health to Owned Action; Trial Account to Reviewed Sales Assist |
| Customer Success | Verify a signed-deal handoff, move the customer through onboarding to first value, measure cohort retention, and review contract-backed renewal decisions. Owns post-sale adoption and renewal preparation. | 5 | 0 | Signed Deal to Onboarding Handoff; New Customer to First Value; Activation and Retention Intelligence; Renewal Risk to Owned Decision |
| Customer Support | Triage and answer incoming issues, coordinate escalation, analyze feedback, and maintain approved help content. Owns the support case and knowledge quality, not the account's full adoption journey. | 5 | 0 | Support Case to Reviewed Resolution; Case Pattern to Knowledge Review; Verified Knowledge to Case Reply |
| Product | Research customer problems, decide priorities, define requirements, review release readiness, and connect feedback or adoption to owner decisions. | 5 | 0 | Feedback Theme to Product Decision; Released Feature to Adoption Decision; Opportunity to Reviewed Requirements; Approved Requirement to Release Readiness; Release to Observed Adoption |
| Operations | Meeting actions, project status, order exceptions, vendor research, and document intake. | 6 | 0 | Meeting Decision to Owned Follow-through; Vendor Evaluation to Purchase Decision; Order Exception to Reviewed Update; document intake also feeds the cross-category Invoice Intake to Reviewed Payable |
| Engineering | Service reliability, delivery, performance, cloud cost, QA release evidence, and Security risk and access review. QA and Security are Engineering specialties in browse. | 13: 7 core, 3 QA, 3 Security | Distinct next jobs | Engineering Operations Intelligence; Release Candidate to Reviewed Gate; Finding to Verified Remediation; Access Exception to Verified Fix; Incident to Verified Recovery; Performance Regression to Owned Change |
| GTM | Coordinate positioning, launch, seller readiness, offer design, and source-linked pipeline measurement across Marketing and Sales. | 5 GTM-specific Crews; existing Marketing and Sales Crews are reused | No duplicate cross-listed roles | Launch to Qualified Pipeline; Offer to Seller Readiness; Launch Signal to Pipeline Review; Accepted Offer to Launch Readiness |
| Shopify | Store launch, catalog quality, storefront conversion, checkout recovery, supplier replenishment, order exceptions, payments, inventory, and returns. | 7 Shopify-specific Crews | Generic Website Growth Crews can support public-storefront work | Seven Shopify Automation Playbooks |
The browse catalog has ten major categories, each with at least five installable Crew templates: Finance, Marketing, Sales, Customer Success, Customer Support, Product, Operations, Engineering, GTM, and Shopify. QA and Security sit beneath Engineering; their existing package IDs, skills and setup records are unchanged. Website Growth is a Marketing subcategory that still appears as its own Crew picker filter. GTM spans Marketing and Sales; Shopify is a store-specific lens across Growth, Sales, Operations, and Support. A template has one canonical ID, skill, and setup record even when it appears in several browse categories. GTM has five canonical Crew IDs; cross-listed Website Growth and Sales roles keep their original identities. The public site's broader Money, Customers, Growth, Operations, and Engineering labels are separate navigation groups. Marketing and Website Growth already have deeper coverage; future template authoring should prioritize other categories by missing customer jobs, not equalize counts mechanically.
The new roles follow existing work boundaries: Atlassian's discovery and delivery model separates evidence capture, priority and delivery; Salesforce's attribution model distinguishes touchpoints, conversions and pipeline; and Zendesk's self-service guidance treats knowledge content as work that needs maintenance and measurement. These sources informed role selection, not a claim that any customer has connected those products.
Status terms: Available locally means the Crew template can be selected and installs a skill plus a pending setup checklist, or the Automation Playbook can be installed as a Builder proposal. Planned means the row is a candidate, not selectable. Operationally ready applies only to a particular customer's configured Crew or Automation after access, a representative result, handoffs, and run policy are verified. None of the category counts asserts operational readiness.
In the category tables below, an unlinked suggested Automation name is an idea, not an installable Playbook. A linked existing Workflow Playbook can be installed separately, but it does not make its proposed Crew identity or a new cross-category handoff available.
| Playbook and use case | Required Crew capabilities | Optional capabilities | First reviewable result | Manual first-run proof and outcome |
|---|---|---|---|---|
| Website Growth Loop: find useful traffic opportunities for a new site | Website Growth Starter → Search Opportunity Mapper | Technical SEO, content brief, page draft, verified publication, distribution and measurement | Source-linked priority brief and buyer-question map; optional approved draft, shipped change, channel plan and traffic readout | Validate exact upstream IDs at each selected handoff. Separate draft approval, provider receipt, live verification, channel delivery and comparable analytics; publication alone is not a traffic result. |
| SEO Intelligence: review one site’s technical search health and buyer-question gaps | SEO Analyst → Search Opportunity Mapper | Search Console evidence when authorized; baseline-first otherwise | Dated issue list and linked question-to-page opportunity with owner action | Validate site, market, locale, device and exact issue artifact. Public fetch does not prove indexation; a proposed change is not published or measured. |
| AI Visibility Intelligence: turn one buyer-question answer sample into a reviewed site opportunity | AI Visibility Analyst → Search Opportunity Mapper | Approved answer source or tracker, site inspection, optional Search Console context | Dated answer-level sample with reconciled mentions and citations, then exact-question page proposal | Validate brand domain, question version, engine/surface, locale, each answer source, valid versus failed denominator and exact snapshot ID. A content proposal is not a published page, AI rank or traffic gain. |
| Funnel and Conversion Intelligence: move a sourced signup-to-paid rate change into a reviewed test question | Funnel Analyst → Growth Experiment Planner | Product analytics and subscription billing source or exports; consented session context optional | Reconciled cohort and stage counts or an honest first baseline, then a pending experiment proposal with metric and guardrail | Validate ordered stages, unique-account counts, equal windows for a trend, identity coverage, paid-state evidence, rate arithmetic and exact observation ID. A funnel drop is not causal proof; a plan is not a launched or winning experiment. |
| Activation and Retention Intelligence: compare SaaS signup cohorts and propose a bounded retention test | Lifecycle Analyst → Growth Experiment Planner | Product events and subscription source or exports; consented feedback optional | Comparable mature cohorts, a single baseline, or explicit pending maturity; only mature evidence reaches a pending experiment proposal | Validate day-7 and day-30 rules, exact cohort identity, maturity, censoring, coverage, equal windows, source references and plan linkage. Cohort differences do not prove cause or individual churn; no variant launches from a plan. |
| Growth Experimentation and Follow-Through: take one approved growth test through provider evidence and guarded outcome review | Experiment Run Coordinator → Growth Outcome Analyst | Existing sourced plan from campaign, funnel, retention or another authorized route; experiment provider, analytics and guardrail exports | Pending approval, exact provider-confirmed launch, then pending, measured or inconclusive readout | Validate frozen plan revision, dated owner approval, provider launch and exposure receipts, complete window, exact variant counts, rates, minimum sample and guardrail. A ticket is not a launch; an observed lead is not a win or ship action. |
| Campaign Signal to Reviewed Experiment: turn a measured campaign change into one bounded next test | Campaign Performance Analyst → Growth Experiment Planner | Competitor Intelligence Analyst | Comparable campaign and CRM metric brief, then a sourced experiment proposal with metric and stop rule | Validate exact account, campaign, offer, metric, attribution and period; recompute qualified events per click and keep partial coverage visible. A plan is not a launched variant or causal result. |
| Inbound Lead-to-Meeting Review: turn an inbound enquiry into a reviewed booking path | Lead Intake & Qualifier → Sales Follow-up Coordinator | Account Researcher | Sourced qualification brief and an unsent, reviewable booking offer | Validate lead identity, fit, duplicate/contact gates and the draft. Count delivery only from a provider receipt, and a meeting only from a calendar or CRM event. |
| Trial Account to Reviewed Sales Assist: decide whether one SaaS trial account merits a seller assist | Product Adoption Analyst → Sales Follow-up Coordinator | None in v1 | Exact-account use observation, then an unsent draft, no-contact or needs-review decision | Match trial/subscription revision, event rule and coverage, CRM account, current permission, suppression, replies and meetings. Partial coverage cannot prove inactivity; a draft is never a send. |
| Discovery to Reviewed Proposal: turn an exact meeting and approved discovery into a commercial draft | Sales Call Briefing Assistant → Proposal Drafter | Account Researcher | Sourced meeting brief and unsent proposal with current pricing and explicit unknowns | Validate the exact account/opportunity/meeting join, approved post-call note, product source and line-item arithmetic; stop before drafting when discovery is absent. Owner review and provider send are separate states. |
| Pipeline Health to Owned Action: turn one stale CRM opportunity into an owned next-step decision | Pipeline Analyst → Deal Follow-through Coordinator | None in v1 | Comparable-snapshot exception and current-state seller action register | Verify snapshot comparability, stale arithmetic, exact opportunity, fresh activity and contact state. A changed stage or owner forces recheck; CRM or contact actions need separate approval and receipts. |
| Finance Operations Review: resolve billing exceptions with finance context | Billing Operations Coordinator → Finance Analyst | Revenue & Close Analyst, Spend & Payables Coordinator | Validated exception queue and source-linked finance impact readout | Run with authorized billing and ledger records; review the queue and impact together. No refund, payment, or accounting write follows from installation. |
| Invoice Intake to Reviewed Payable: move an authorized vendor invoice from field extraction to an AP owner decision | Document Intake Assistant → Spend & Payables Coordinator | None in v1 | Page-linked invoice fields and a current duplicate, approval and payment-state review | Match entity, document hash/version, vendor, invoice key, currency and total. Re-read AP after extraction; a possible duplicate needs review, and paid state requires provider evidence. Bill creation and payment remain separate approved actions. |
| Refund Request to Reconciled Outcome: move a customer refund request from exact review to observed finance state | Billing Operations Coordinator with Refund Review → Revenue & Close Analyst | None in v1 | Reviewed exact-amount refund decision and finance state, which may truthfully be pending action | Match entity, account, mode, customer, request, payment, currency and amount. Validate the decision before finance consumes it. Provider success and ledger reconciliation require their own receipts; no refund action follows from installation. |
| Dispute to Reconciled Outcome: take one payment dispute from evidence review to observed finance treatment | Billing Operations Coordinator with Dispute Review → Revenue & Close Analyst | None in v1 | Exact-case evidence gaps and owner decision, then pending or provider-backed outcome and separate ledger review | Match entity, processor account/mode, dispute, charge, customer, amount and case revision. A packet is not submitted, an accepted submission is not a win, and a provider decision is not reconciliation. |
| Subscription Receivable to Verified Outcome: move one overdue or failed-payment invoice to a verified money state | Billing Operations Coordinator with Invoice Chasing or Failed Payment Recovery → Finance Analyst | None in v1 | Exact-invoice review, policy-safe contact decision and source-linked open, partial, collected or deposited outcome | Recompute due amount; bind customer, invoice, account, mode and cutoff. A sent reminder needs approval and delivery receipt; collection needs a matching provider payment; deposit additionally needs matching payout, bank and ledger evidence. |
| New Customer to First Value: track a new customer to an agreed result | Customer Onboarding Coordinator → Product Adoption Analyst | Customer Health Coordinator | Owned milestone register and evidence-linked first-value readout | Verify customer identity, event definition, source coverage, and the onboarding-to-adoption handoff on a real authorized account. A milestone plan alone is not first-value proof. |
| Signed Deal to Onboarding Handoff: verify a signed SaaS deal before CS starts work | Deal Follow-through Coordinator → Customer Onboarding Coordinator | Existing New Customer to First Value route after acceptance | Executed-scope handoff and receiving-owner acceptance or a sourced blocker | Match CRM, contract, customer, purchased scope, first-value promise and current entitlement. Closed Won alone cannot start onboarding; acceptance does not prove first value or authorize customer contact. |
| Renewal Risk to Owned Decision: review one SaaS account before its contract notice deadline | Customer Health Coordinator → Renewal Coordinator | Existing Finance Analyst for a separately authorized financial explanation | Bounded health brief and exact-contract renewal register with owner decision or terms blocker | Match tenant/account and health artifact, re-read executed terms and subscription, calculate notice in policy timezone, and keep open billing or low use distinct from churn intent. No notice, discount, cancellation or renewal follows from selection. |
| Support Case to Reviewed Resolution: take an authorized case through triage, reply, optional escalation, and observed follow-through | Support Triage Assistant → Support Reply Drafter | Escalation Coordinator | Validated case triage and grounded unsent reply; owned escalation when warranted | Match tenant, case, account, and thread; verify approved claims and recipient. Count contact from a provider receipt and resolution only from later authoritative case state. |
| Case Pattern to Knowledge Review: turn repeated questions into reviewed help content | Support Triage Assistant → Support Knowledge Curator | None in v1 | Distinct-case pattern and unpublished article update draft | Validate exact cases, product and question; compare current article and approved behavior. A draft or approval is not publication or measured deflection. |
| Verified Knowledge to Case Reply: ground an exact-case reply in observed live help | Support Knowledge Curator → Support Reply Drafter | None in v1 | Published article revision and an unsent, case-specific reply draft | Verify live publication receipt, exact article revision, open case, recipient, suppression and contact policy. A draft is not a send or resolved case. |
| Feedback Theme to Product Decision: move bounded feedback from source-backed theme to product owner decision | Feedback & Review Analyst → Product Feedback Coordinator | None in v1 | Validated theme with denominator and coverage, then current-issue review and owner decision | Match tenant, product, segment, theme and period; block duplicates, unsupported prevalence, false exact-issue matches and unreceipted actions. Issue writes and customer promises are separate. |
| Released Feature to Adoption Decision: decide what to investigate after one shipped feature | Product Adoption Analyst → Product Feedback Coordinator | None in v1 | Release- and flag-bound eligible, exposed and using-account observation, then pending product owner decision | Match release/build, flag revision, account identity, segment and window; check count arithmetic, coverage, sample and comparable rules. Current issues and owner decisions are separate; no causal claim or automatic product change. |
| Opportunity to Reviewed Requirements: carry a bounded problem into draft requirements | Product Discovery Researcher → Roadmap Prioritization Analyst → Product Requirements Coordinator | None in v1 | Reviewed opportunity, owner-accepted priority and testable draft criteria | Match product, opportunity, source revisions and owner acceptance; keep an unapproved requirement from becoming delivery work. |
| Approved Requirement to Release Readiness: prepare a Product go/no-go | Product Requirements Coordinator → Product Release Coordinator | Independent QA and Support sources | Exact requirement and build decision with QA, help and measurement blockers | A passing gate alone is insufficient. Validate approved scope and exact handoff; do not treat go, deployment, exposure and adoption as one state. |
| Release to Observed Adoption: measure first observed use after a verified release | Product Release Coordinator → Product Adoption Analyst | Product owner review after observation | Exact release and flag handoff, then eligible, exposed and using counts with coverage | Validate passing QA, deployment, rollout authority and frozen event rule; enforce using ≤ exposed ≤ eligible. Go is not deployment, exposure is not use, and the observation is not a causal effect. |
| Release Candidate to Reviewed Gate: decide whether one exact candidate satisfies the required QA policy | Browser Journey QA Analyst → Release Quality Assistant | Flaky Test Investigator | Attempt-level journey evidence and full suite matrix with a reviewed pass, fail, or needs-review proposal | Match release, SHA, build, environment, policy and journey revisions. Keep failures visible, block a pass with missing suites or an open flake investigation, and count publication only from a provider receipt. |
| Finding to Verified Remediation: carry one authorized, applicable finding through owned remediation | Security Findings Analyst → Security Remediation Coordinator | None in v1; Access Review evidence may be attached separately | Source-linked finding and owned ledger with change, deployment, independent retest, and disposition | Match tenant, finding, asset, environment, observed build and written scope. A merged change remains open; closure needs affected deployment, matching independent retest and owner decision. |
| Access Exception to Verified Fix: correct one permission-policy exception | Access Review Analyst → Security Remediation Coordinator | None in v1 | Exact policy-cell mismatch, approved fix, deployment and independent same-cell retest | Match tenant, role, resource, action and expected decision; keep a posted change distinct from deployed state and require affected-environment retest plus owner closure. |
| Meeting Decision to Owned Follow-through: carry reviewed meeting actions into observed project status | Meeting Actions Coordinator → Project Status Reporter | Chief of Staff for a separate leadership review | Source-linked action register with accepted versus pending owners, then exact project task status and optional decision brief | Match tenant, project, meeting revision, action and task IDs. Pending owners cannot become tasks; completed work requires tracker evidence. Task writes and messages remain separate approved actions. |
| Vendor Evaluation to Purchase Decision: compare SaaS vendor plans before an owner purchase decision | Vendor Researcher → Spend & Payables Coordinator | Separate Security reviewer when policy requires one | Requirement- and quote-bound comparison followed by fresh vendor, commitment, budget and gate review | Match entity, request, exact vendor/product/plan/quote, seats, term and total; reject expired quotes, unresolved must-haves, duplicate commitments and false approval or payment. Approval is not a PO, signature or purchase. |
| Order Exception to Reviewed Update: investigate a generic commerce or ERP exception and prepare an exact-case customer update | Order Operations Coordinator → Support Reply Drafter | None in v1 | Source-linked order exception and unsent, case-linked update or explicit no-message decision | Validate business, order, customer, case and artifact IDs before Support reads the exception. A label is not carrier acceptance or delivery; a draft is not sent or resolved. |
| Incident to Verified Recovery: move a production incident through investigation, owned delivery work, and observed recovery | Incident Investigator → Engineering Delivery Coordinator | None in v1 | Sourced incident timeline and validated blocker ledger | Validate same incident, service, owner, and approval state. Run manually on authorized records; an approved change and deployment still require a separate telemetry-based recovery decision. |
| Performance Regression to Owned Change: move a reproducible regression to an owner decision | Performance Investigator → Engineering Delivery Coordinator | Separate independent retest after any later deployment | Comparable baseline/current finding and an owner-reviewed proposed change | Match service, build, budget and exact finding. Distinguish observed regression, proposed fix, deployment and recovery; a proposed change never proves improvement. |
| Engineering Operations Intelligence: turn one governed team metric into an owned improvement question | Engineering Operations Analyst → Engineering Delivery Coordinator | Broader data-foundation and recurring review methods | Exact-scope metric observation with complete, baseline or unknown comparison, then current-issue owner review | Recompute counts and rates under one rule, verify equal windows and source coverage, join exact team/service/metric, and keep owner acceptance, issue writes and later observed outcomes distinct. |
| Post-Incident Review and Actions: reconstruct a stable incident and verify improvements | Post-Incident Reviewer → Improvement Follow-Through Coordinator | Canonical incident/recovery, monitoring, issue and independent verification sources | Review draft or approved sourced impact and factor analysis, then pending, accepted or independently verified action register | Validate stability, impact arithmetic, dated timeline, factor evidence, exact review/action IDs, owner acceptance, issue receipt and later passing control evidence. A closed ticket is not verified improvement or publication. |
| Cost Anomaly to Verified Savings: explain one cloud bill change, review a bounded infrastructure change, and verify actual savings | Cloud Cost Analyst → Engineering Delivery Coordinator → Finance Analyst | None in v1 | Reconciled cost brief, exact candidate and change review, then pending or billed savings readout | Match account, resource, currency, billing basis, period and candidate. Recompute usage, price and one-time effects. Require risk review, approval, deployment and health receipts before comparing equal-workload billed periods; an estimate is never verified savings. |
| Launch to Qualified Pipeline: take a B2B offer from approved launch strategy to sourced pipeline signals | GTM Strategy Analyst → Launch Coordinator → Lead Intake & Qualifier → Sales Follow-up Coordinator | Website Growth Starter for a bounded site task | Approved launch brief, provider-backed channel state, linked inbound signal, Sales qualification, and reviewed booking path | Match launch, offer, campaign, event and lead IDs; run GTM and Sales validators; count sends and meetings only from their own provider evidence. |
| Offer to Seller Readiness: prepare a current seller asset from an approved offer | Pricing & Packaging Analyst → Sales Enablement Coordinator | None in v1 | Accepted plan and price version, then unpublished persona-specific guidance | Match offer, plan and price; require owner acceptance, current claim refs and protected contract review. Asset distribution and prospect contact need separate approval. |
| Launch Signal to Pipeline Review: reconcile one observed campaign to pipeline stages | Launch Coordinator → Revenue Operations Analyst | None in v1 | Provider-backed campaign observation, deduplicated event counts and partial-attribution review | Match offer, launch and campaign; enforce ordered stage counts and preserve unmatched events. A form event is not a qualified lead or revenue. |
| Accepted Offer to Launch Readiness: prepare an approved-priced offer for a bounded launch | Pricing & Packaging Analyst → GTM Strategy Analyst → Launch Coordinator | Seller guidance may be prepared on a separate route | Accepted price and entitlement revision, sourced positioning and unpublished launch readiness | Verify owner acceptance, buyer evidence, current approved claims and exact asset revisions. An accepted plan does not publish a campaign, change spend or contact leads. |
| Order Exception to Resolution: resolve a Shopify order problem tied to a return or refund request | Store Operations Coordinator → Returns & Refunds Coordinator | None in v1 | Sourced order exception and validated policy/money review with an unsent customer draft | Validate same store, order, case, currency, and policy. Run manually on an authorized case; count a refund or sent response only from a provider receipt. |
| Storefront Opportunity to Verified Change: turn a specific buyer friction into a reviewed catalog correction | Shopify Growth Analyst → Catalog & Merchandising Analyst | None in v1 | Validated growth opportunity, exact variant change review, and post-publish retest rule | Validate store, market, product, variant, and opportunity; publish only after merchant approval, then measure only against a comparable baseline. |
| Inventory Availability to Owner Action: resolve a variant/location stock or display mismatch | Catalog & Merchandising Analyst → Store Operations Coordinator | None in v1 | Location-aware exception, owner-reviewed action, and inventory/storefront retest | Validate exact inventory item and location; separate available, committed, and incoming; require approval and receipt for writes. |
| Payment Exception to Order Decision: decide whether an order must wait or can be reviewed for fulfillment release | Payment Operations Investigator → Store Operations Coordinator | None in v1 | Transaction evidence and owner-safe hold/release review | An authorization is not capture; release review requires successful capture or sale in this route, then owner approval and provider evidence. |
| Product Launch Readiness to Go/No-Go: check one product and market before publication | Catalog & Merchandising Analyst → Shopify Growth Analyst | None in v1 | Catalog blockers, buyer-journey check, merchant go/no-go, and post-publish retest | Match exact product, variant, market, and Publication; blocked checks prevent go review; approval is not publication. |
| Checkout Signal to Reviewed Recovery: review one abandoned checkout for contact | Shopify Growth Analyst → Checkout Recovery Coordinator | None in v1 | Minimal checkout signal, consent and suppression decision, and unsent draft only when eligible | Match store, market, checkout, campaign and channel; block recovered checkouts, unknown consent and duplicate sends. A message needs approval and provider receipt; a later order needs a trusted checkout/order link. |
| Inventory Risk to Reviewed Replenishment: decide whether one item/location needs a supplier order | Catalog & Merchandising Analyst → Replenishment Planner | None in v1 | Location-specific stock signal and recomputed supplier quantity/cost review | Validate exact item and location; count open-PO incoming once, calculate target/shortage/pack rounding, and separate approval, PO order, transfer receipt and stock verification. |
Each Playbook's playbook.json declares its slots, artifact names, and capability suggestions; its SETUP.json records ten customer-specific checks. The Website Growth guide, Funnel handoff guide, AI visibility handoff guide, Marketing campaign guide, Sales guide, proposal handoff guide, the pipeline handoff guide, signed-deal handoff guide, the Customer Support guide, Product feedback guide, feature adoption guide, QA release guide, Security remediation guide, access exception guide, Operations guide, Engineering operations guide, vendor purchase guide, invoice intake guide, refund handoff guide, dispute handoff guide, the FinOps handoff guide, and Shopify operator guide provide detailed journeys. Existing Workflow Playbooks outside these forty-nine are indexed in the Playbooks README; their presence does not make a planned Crew template installable.
The remaining 15 Workflow guides provide methods or setup material. Keep them as guides until a distinct team owner and handoff is justified. The next cross-team route candidates identify customer jobs the installed library does not yet cover. Before promoting another route, require a representative fictional case, a typed handoff with a rejected example, five to ten chat setup checks, and a real authorized manual case before customer setup is complete. A Playbook may link to another Playbook, as the signed-deal route links to first value; Builder must validate the receiving artifact and preserve each route's approval and activation boundary.
This is the current use-case map, not a list of extra agents. Start with one relevant Crew for a chat request. Offer the named Automation Playbook when the customer wants an owned, measured journey across capabilities or a separate access/review boundary. A source export may support the first read-only result; the connected version needs a verified account and scope.
| Customer request or use case | Primary available Crew | First useful result | Multi-Crew route when needed |
|---|---|---|---|
| “Explain what changed in our SaaS revenue, spend, or cash.” | Finance Analyst | Sourced finance brief with calculations and unknowns | Finance Operations Review when billing exceptions need a separate owner |
| “Which invoices, failed payments, refunds, or disputes need attention?” | Billing Operations Coordinator | Dated exception queue and drafts for review | Finance Operations Review |
| “Which overdue invoices need a reminder?” | Invoice Chasing pack on Billing Operations Coordinator | Current-balance queue with prior contact and unsent next reminder | Subscription Receivable to Verified Outcome for an exact invoice through finance verification |
| “What should we do after this failed subscription payment?” | Failed Payment Recovery pack on Billing Operations Coordinator | Current retry and contact state with a reviewed next step | Subscription Receivable to Verified Outcome for an exact invoice through finance verification |
| “Can we approve this customer's partial refund?” | Refund Review pack on Billing Operations Coordinator | Exact-amount decision with prior refunds and remaining balance | Refund Request to Reconciled Outcome if a separate close owner must verify provider and ledger state |
| “What is missing for this payment dispute?” | Dispute Review pack on Billing Operations Coordinator | Evidence and deadline brief with an owner handoff | Finance Operations Review if a separate analyst must assess impact |
| “Reconcile subscription billing to our close.” | Revenue & Close Analyst | Close checklist and mismatch memo | Optional specialist in Finance Operations Review; no close handoff is packaged yet |
| “Review bills and company expenses before approval.” | Spend & Payables Coordinator | Source-linked payables queue | Invoice Intake to Reviewed Payable for document-to-AP review; optional specialist in Finance Operations Review |
| “Prepare transaction records for our tax professional.” | Tax Export Preparer | Reconciled export and exception list | Usually a capability on Finance Analyst; no tax filing Automation is packaged |
| “We launched a site; what should we fix first to attract relevant visitors?” | Website Growth Starter | Source-linked audit and 30-day priority brief | Website Growth Loop |
| “Which technical SEO issues are observable on our site?” | SEO Analyst | Page-level issue list and retests | Optional technical SEO slot in Website Growth Loop |
| “Which buyer questions lack a useful page?” | Search Opportunity Mapper | Buyer-question-to-page map | Required search slot in Website Growth Loop |
| “Prepare a brief for this approved page opportunity.” | Content Brief Writer | Reviewable page brief | Optional content slot in Website Growth Loop |
| “Draft the approved page for review.” | Content Page Builder | Sourced page draft and next action | Optional page slot; publication is a separate reviewed step |
| “Was this approved page actually published and checked?” | Website Publishing Coordinator | Pending readiness or verified live change record | Optional publication slot in Website Growth Loop |
| “Which existing pages can improve from Search Console evidence?” | Search Console Optimizer | Sourced page/query recommendations | A standalone Crew task unless Builder designs a compatible handoff |
| “What changed in traffic and useful visitor actions?” | Traffic & Engagement Analyst | Sourced readout with a next action | Optional measurement slot in Website Growth Loop |
| “What changed in this competitor's product or plan?” | Competitor Intelligence Analyst | Dated change brief with prior/current evidence and owner question | Optional context in Campaign Signal to Reviewed Experiment |
| “Where do signup users drop before paying?” | Funnel Analyst | Reconciled ordered-stage counts, paid/eligible rate and source coverage | Funnel and Conversion Intelligence |
| “How did activation and day-30 retention change across signup cohorts?” | Lifecycle Analyst | Maturity-aware cohort counts, rates, source coverage and limits | Activation and Retention Intelligence |
| “Why did campaign clicks rise while qualified demos fell?” | Campaign Performance Analyst | Comparable campaign and CRM readout with coverage gaps | Campaign Signal to Reviewed Experiment |
| “What should we test next from this signal?” | Growth Experiment Planner | Bounded proposal with metric, guardrail, owner and stop rule | Campaign Signal to Reviewed Experiment |
| “Did our approved experiment launch, and what did it actually achieve?” | Experiment Run Coordinator, then Growth Outcome Analyst | Exact provider launch state and guarded measured or inconclusive readout | Growth Experimentation and Follow-Through |
| “Where do answer engines cite us or competitors?” | AI Visibility Analyst | Question-level observations and citation gaps | AI Visibility Intelligence Automation for a distinct question-to-page handoff |
| “Why is this landing page not converting?” | Landing Page Optimizer | Page diagnosis and testable improvement | A standalone Crew task or reviewed experiment workflow |
| “How should we distribute this published asset?” | Content Distribution Coordinator | Channel plan and reviewed drafts | A standalone Crew task; sending needs its own approved route |
| “Which inbound enquiries fit our customer criteria?” | Lead Intake & Qualifier | Deduplicated, source-linked qualification brief | Inbound Lead-to-Meeting Review |
| “What verified company context will help this seller?” | Account Researcher | Dated facts, labeled hypotheses, seller questions | Optional research slot in Inbound Lead-to-Meeting Review |
| “Prepare and track a reply offering a meeting.” | Sales Follow-up Coordinator | Unsent, cited booking offer with owner decision | Inbound Lead-to-Meeting Review; send and booking require real receipts |
| “What should I know before this buyer call?” | Sales Call Briefing Assistant | Exact-meeting brief with verified facts and discovery questions | Discovery to Reviewed Proposal when reviewed post-call notes will support a draft |
| “Draft a proposal from this approved discovery.” | Proposal Drafter | Sourced unsent proposal with current pricing and open approvals | Discovery to Reviewed Proposal |
| “What changed in our pipeline?” | Pipeline Analyst | Comparable snapshot movement and stale-deal brief | Pipeline Health to Owned Action for a bounded stale opportunity |
| “Who owns the next step on this stale opportunity?” | Deal Follow-through Coordinator | Current-state action register with seller review, contact coverage and stable action key | Pipeline Health to Owned Action |
| “Can CS start onboarding this signed customer?” | Deal Follow-through Coordinator, then Customer Onboarding Coordinator | Exact contract-backed scope and a receiving-owner acceptance or blocker | Signed Deal to Onboarding Handoff, then New Customer to First Value |
| “Turn this signed customer handoff into an onboarding plan.” | Customer Onboarding Coordinator | Owned milestone register with blockers | New Customer to First Value |
| “Did this customer achieve the agreed first result?” | Product Adoption Analyst | Observed first-value status and source coverage | New Customer to First Value |
| “Which customer accounts need an owner decision?” | Customer Health Coordinator | Sourced account health brief | Optional health slot in New Customer to First Value |
| “Which renewals need review before notice is due?” | Renewal Coordinator | Exact-contract notice and billing register with an owner decision or terms blocker | Renewal Risk to Owned Decision after a bounded Customer Health brief |
| “Which support cases are urgent or duplicated?” | Support Triage Assistant | Sourced case triage and next owner decision | Support Case to Reviewed Resolution when reply needs another owner |
| “Draft a reply to this customer issue.” | Support Reply Drafter | Grounded unsent response for the exact case and recipient | Support Case to Reviewed Resolution |
| “Who owns this escalated case now?” | Escalation Coordinator | Impact brief with receiving-owner acceptance state | Optional escalation slot in Support Case to Reviewed Resolution |
| “What themes are emerging in feedback?” | Feedback & Review Analyst | Sourced theme brief with denominator and owner action | Feedback Theme to Product Decision when a Product owner must review the theme |
| “Should this shipped feature be investigated or changed?” | Product Adoption Analyst | Eligible, exposed and using-account observation with coverage and sample status | Released Feature to Adoption Decision |
| “Should this feedback become product work?” | Product Feedback Coordinator | Exact-theme decision brief with current issue match, gaps and owner state | Feedback Theme to Product Decision |
| “What did we decide in this meeting, and who accepted each action?” | Meeting Actions Coordinator | Sourced action register with owner acceptance and duplicate state | Meeting Decision to Owned Follow-through |
| “Which project tasks are open, blocked, or actually done?” | Project Status Reporter | Exact project status with source coverage and owner requests | Meeting Decision to Owned Follow-through when meeting actions need tracking |
| “Which business decisions need me this week?” | Chief of Staff | Sourced priorities and decision brief | Optional review slot in Meeting Decision to Owned Follow-through |
| “Which orders are stuck or late?” | Order Operations Coordinator | Cross-system order exception queue | Order Exception to Reviewed Update when a distinct Support owner prepares customer contact; proactive Order Watchdog remains proposed |
| “Which vendor meets our requirements?” | Vendor Researcher | Requirement-level comparison with costs and unknowns | Vendor Evaluation to Purchase Decision when a separate owner must review current procurement gates |
| “Extract and verify fields from these documents.” | Document Intake Assistant | Source-linked extraction and review queue | Invoice Intake to Reviewed Payable when an AP owner must review an invoice; destination write needs approval |
| “Investigate this incident across alerts and deploys.” | Incident Investigator | Sourced timeline, hypotheses, and owner decisions | Incident to Verified Recovery when a separate delivery owner must track a fix through release and service verification |
| “What did we learn from this incident, and were the fixes verified?” | Post-Incident Reviewer, then Improvement Follow-Through Coordinator | Sourced blameless review and exact pending or verified improvement register | Post-Incident Review and Actions after stable recovery |
| “Which team delivery signal needs an owner decision?” | Engineering Operations Analyst | Reconciled metric, coverage and comparable-window state with one bounded question | Engineering Operations Intelligence when Delivery must own the next review |
| “What is blocking this change from shipping?” | Engineering Delivery Coordinator | Joined issue, PR, CI, and deployment blocker ledger | Existing CI and Deployment Failure Triage Workflow can guide a Builder proposal |
| “Why did this route become slower?” | Performance Investigator | Comparable regression brief and retest plan | Existing Performance Engineering Workflows can guide a Builder proposal |
| “What changed in cloud spend?” | Cloud Cost Analyst | Reconciled cost-change brief and risk-checked candidates | Cost Anomaly to Verified Savings Automation joins an engineering change to a finance-verified readout |
| “Did this exact release's signup journey pass?” | Browser Journey QA Analyst | Attempt-level result with build, expected/observed outcome, and evidence | Release Candidate to Reviewed Gate when the result must feed a full suite decision |
| “Why does this test pass only after retry?” | Flaky Test Investigator | Controlled attempt comparison and reviewed cause hypothesis | Optional investigation in Release Candidate to Reviewed Gate |
| “Can this release candidate pass the QA gate?” | Release Quality Assistant | Exact-build suite matrix and pass/fail/needs-review proposal | Release Candidate to Reviewed Gate when a separate Journey Crew supplies evidence |
| “Which reported security findings apply to this deployed asset?” | Security Findings Analyst | Scoped, sourced finding queue with confidence and owner | Finding to Verified Remediation when another owner tracks the approved fix |
| “Can this role access another tenant's data?” | Access Review Analyst | Expected/observed permission matrix with direct-route evidence | Access Exception to Verified Fix when the exception needs an owned change and same-cell retest; Role and Permission Validation guides the test method |
| “Was this security fix deployed and retested?” | Security Remediation Coordinator | Finding-to-deployment ledger with independent retest state | Finding to Verified Remediation |
| “How do we launch this B2B offer and measure qualified pipeline?” | GTM Strategy Analyst | Sourced launch brief with approved claims and metric rule | Launch to Qualified Pipeline |
| “Which assets, channels, and leads need a launch owner decision?” | Launch Coordinator | Source-linked action ledger with provider and inbound event state | Launch to Qualified Pipeline |
| “Which orders are stuck between payment and fulfillment?” | Store Operations Coordinator | Sourced order exception queue and owner action | Order Exception to Resolution when a return or refund request needs a separate policy owner |
| “Can we approve this return or refund request?” | Returns & Refunds Coordinator | Policy and payment review with an unsent customer reply | Order Exception to Resolution when fulfillment facts must be verified first |
| “Which products and variants need merchant review?” | Catalog & Merchandising Analyst | Product and variant issue queue with proposed edits and retests | Storefront Opportunity to Verified Change when a growth finding is involved |
| “Where is this store losing shoppers?” | Shopify Growth Analyst | Store growth brief with evidence, limits, and measurement plan | Storefront Opportunity to Verified Change |
The first-party Crew metadata, billing capability packs, Website Growth specialists, Marketing specialists, Sales specialists, expanded Sales roles, Customer Success specialists, Customer Support specialists, Product specialist, Product, GTM and Support additions, Operations specialists, Engineering specialists, QA specialists, Security specialists, GTM specialists, and Shopify specialists are the current installable definitions. Each entry already provides a role, purpose, first result, minimum inputs, optional connections, example requests, a local skill, and a chat checklist. The Finance and Website Growth Starter skills are stored in template files; the specialist skills and setup guides are generated from the typed definitions. These are implementation sources, not customer setup evidence.
These journeys provide concrete handoff examples for deeper agent detail:
| Reference journey | Fictional good output | Blocking example and review point | Second-run behavior |
|---|---|---|---|
| Website Growth Loop | Priority brief → buyer-question map → optional approved page → verified ship → distribution plan → traffic readout | Invalid page, false ship, invalid delivery and invalid readout stop their consumers. Separate owner approval, provider receipts and source review remain required. | Read prior action IDs and owner decisions; inspect changed pages and new evidence first; report no new evidence when nothing changed. See action and measurement. |
| AI Visibility Intelligence | Two-answer snapshot → pending page opportunity | Inflated citation and false publication fail. The owner reviews question provenance, answer captures, page facts and useful change. | Repeat only on the same question version, engine/surface, locale and method; retain failed runs and old samples. A new method starts a new baseline. |
| Funnel and Conversion Intelligence | Reconciled stage observation or baseline-first case → pending experiment | False launch and winner fails. Product and growth owners review source joins, partial coverage, metric and proposed variant before any launch. | Keep cohort/event versions and paid-state keys stable, wait for billing lag, then compare like windows; changed instrumentation starts a new baseline. |
| Activation and Retention Intelligence | Comparable cohorts, one baseline, or pending maturity → pending experiment only when mature | False approved winner fails. Product and growth owners review join coverage, maturity, metric and guardrail. | Preserve cohort and policy IDs; wait until every signup reaches day 30 plus billing lag. Changed instrumentation starts a baseline. |
| Growth Experimentation and Follow-Through | Approved provider-confirmed run → inconclusive readout or measured readout | False launch and false winner fail. Owner reviews approval, provider state, outcome source and action decision. | Keep plan, variant, assignment and experiment IDs stable; wait for full window and source lag; corrected evidence supersedes earlier readouts. |
| Post-Incident Review and Actions | Sourced approved review or pending draft → verified and pending actions | Unsupported confirmed cause and closed issue without control proof fail. Review owner checks truth and privacy before any issue/publication action. | Keep incident/review/action IDs and earlier decisions; re-read issue and independent control state, with reviewed revisions for corrected facts. |
| Campaign Signal to Reviewed Experiment | Campaign brief → optional competitor context → experiment plan | False active plan fails. The owner reviews the sample, metric, guardrail and stop rule before a separate launch route. | Keep campaign and metric IDs, wait for attribution to settle, compare the same policy and preserve the proposed versus launched state. |
| Discovery to Reviewed Proposal | Exact call brief → approved discovery → unsent proposal | Unapproved note, unsupported claim and false send fail. Seller reviews the call facts; commercial owner reviews scope and price before any delivery. | Re-read meeting, opportunity, approved note and price revisions; retain proposal versions and never overwrite a sent draft silently. |
| Pipeline Health to Owned Action | Comparable-snapshot exception → pending seller action | Wrong opportunity, duplicate key, opt-out and false send fail. Seller reviews current opportunity and prior-contact state before an action. | Re-read stage, owner, activity and contact status; retain opportunity/action keys and supersede old suggestions rather than duplicating work. |
| Invoice Intake to Reviewed Payable | Page-linked extraction → payable review | Unreceipted paid claim fails. The AP owner checks document identity, vendor match, duplicate and current payment state before any write. | Re-read the same document hash/version and current bill/payment records; retain bill and provider IDs and never create a second bill from the same invoice key. |
| Refund Request to Reconciled Outcome | Exact refund decision → pending finance state | Invalid amount and fake provider result fail validation. Billing owner reviews policy and amount; finance owner separately reviews provider and ledger state. | Re-read the same request, payment, prior refunds, action key, provider receipt and ledger before another proposal or reconciliation claim. |
| Dispute to Reconciled Outcome | Pending exact-case review → pending finance state | False submission and false finance win fail. Dispute owner reviews evidence and deadline; finance owner checks provider and ledger state. | Re-read the same case revision, deadline, submission history, provider outcome and exact principal/fee entries; hold uncertain submissions rather than retrying blindly. |
| Subscription Receivable to Verified Outcome | Exact invoice review → open outcome or collected but unsettled | Wrong balance and fake send and false deposit fail. Billing reviews policy; Finance checks payment, payout and bank evidence. | Re-read exact invoice, retry, prior contact, payment and deposit records; keep stable case and contact keys rather than sending duplicate reminders. |
| Cost Anomaly to Verified Savings | Cost review → change proposal → pending savings; separate approved deployment can reach verified savings | False verified savings fails. Service owner reviews risk, IaC plan and approval; Finance checks actual billed period, workload and health before verification. | Re-read the same account, resource and candidate; retain prior approval and deployment IDs, and compare equal billing windows on the same basis before updating the outcome. |
| Engineering Operations Intelligence | Comparable metric, one baseline or incomplete coverage → pending owner review | False cause, ranking and verified action fail. Engineering owner reviews current issue state and action boundary. | Preserve team/service, metric and source rule revisions and case key; changed definitions start a new baseline and later observations do not prove causality. |
| Inbound Lead-to-Meeting Review | Qualification brief → unsent follow-up | Invalid qualification must stop follow-up. The owner reviews exact recipient, offer, contact policy, and booking link; a delivery receipt is separate from a booked outcome. | Re-read lead, suppression, prior contact, replies, and booking state before another touch; retain one stable action ID. See team and handoffs. |
| Renewal Risk to Owned Decision | Bounded health or unknown coverage → pending exact-contract decision or unverified terms | False renewal and customer action fail. Owner reviews notice rule, billing evidence and health uncertainty before any action. | Keep account, contract revision and case key; an update cites its prior artifact and re-reads terms, notice, billing and health. Other than calendar-day notice needs a reviewed manual calculation. |
| Support Case to Reviewed Resolution | Case triage → unsent reply → separate delivery and outcome | Wrong-case reply must stop the route. The owner approves exact text and recipient; an accepted escalation has its own owner receipt. | Re-read current thread, prior contact and case status before another action; a reopened case supersedes previous closure. |
| Feedback Theme to Product Decision | Bounded feedback theme → pending Product decision | False exact issue match, write and promise fail. Product owner reviews scope, counterexamples and current issue state before any action. | Compare like source windows, retain theme and issue IDs, and reopen a decision only when new evidence or owner policy changes. |
| Released Feature to Adoption Decision | First baseline, comparable repeat, or incomplete coverage → pending owner decision | False cause, issue action and product change fail. Product owner reviews sample, target, current issue state and gaps. | Preserve release, flag revision, rule and case key; compare equal windows only under the same definitions and start a new baseline after instrumentation changes. |
| Release Candidate to Reviewed Gate | Exact-build journey → required-suite gate | Wrong-build pass fails. A flake investigation yields needs-review. Status publication is separate. | A new SHA or build requires a new matrix; preserve old failed attempts and owner decisions, then re-read current candidate and prior status before publication. |
| Finding to Verified Remediation | Validated finding → open remediation ledger → separate verified closure | Merged-only closure fails. Written scope, reviewed change, affected deployment, independent retest and owner decision each have their own evidence. | Re-read finding and deployment before another action; preserve failed retests and accepted-risk decisions, and reopen when the affected build or finding state changes. |
| Access Exception to Verified Fix | Policy-bound access matrix → pending fix or separate verified closure | Merge-only closure fails. Direct server evidence, policy cell, approved change, affected deployment and independent same-cell retest are checked separately. | Re-read policy, build and issue; preserve failed attempts and require a new comparison when policy or fixture identity changes. |
| Meeting Decision to Owned Follow-through | Meeting action register → project action status → optional review brief | False completion fails. A pending owner is not an accepted task and a meeting promise is not tracker completion. | Reconcile the same meeting revision, action and task IDs with current tracker state; preserve owner corrections and avoid duplicate writes. |
| Vendor Evaluation to Purchase Decision | Exact-plan comparison → pending purchase review, blocked review or approved decision | False approval and purchase fail. Budget owner reviews current vendor, commitment, security, privacy and cost evidence. | Retain request and case key, quote and rule revisions; re-read vendor and budget state, and restart comparison when the quote or requirements change. |
| Order Exception to Reviewed Update | Exact-order exception → case-linked unsent update | Wrong order, false delivery, refund, send and resolution fail. Operations and Support owners review source and contact state. | Re-read the same order, carrier and case on retry; retain case and action IDs, avoid duplicate drafts and count a send only from a separate provider receipt. |
These fixtures demonstrate fields and handoff shape, not a real customer result. Before promoting each individual Crew as a fully demonstrated public example, its own detail must also include one complete fictional input/output pair, an inadequate output with a reason it fails, the exact source or connection probe for its hard task, the owner review point, a second-run rule, and at least one exercised customer-like case. The content quality review tracks gaps in the Website Growth specialists; the setup quality review tracks remaining runtime readiness gaps. All forty-nine packaged multi-Crew Playbooks describe their handoffs and have executable contract suites; the full library has fifty-four suites. Fictional fixtures do not prove a customer's integration or business outcome.
A Crew template currently provides a reusable capability pack: a local skill, starter instructions, example requests, expected outputs, and a setup checklist. A new Crew may start from one template to seed its identity. An existing Crew can add more packs without changing its role or purpose. Each pack keeps its own setup progress. The target model is a unified Playbook catalog: an Agent Playbook proposes one primary agent for a Crew, while an Automation Playbook proposes a multi-agent team and Workflow plan. Selecting a Playbook opens a setup draft in chat; the Builder inspects what exists, proposes concrete changes, and applies them through authorized tools after review. Supporting packs remain capabilities of one Crew, not additional agent identities. The Automation owns the recurring goal and handoffs; selecting either Playbook does not activate a schedule or run.
Each template must work as a useful interactive Crew after the user provides its minimum inputs. Connected accounts, schedules, outbound messages, payments, production changes, and other consequential actions require explicit setup and the product's normal permissions and approvals. Never prefill a customer's target metric with an illustrative website number.
The catalog tracks ten major browse categories and the Website Growth subcategory described above. QA and Security are Engineering specialties. Several related jobs should become capabilities of one Crew rather than separate Crew identities. Existing Workflow playbooks may inform a template or its suggested Automation, but they are not Crew templates.
The creation picker is designed for a larger installed catalog: keep Blank Crew separate from scrolling results; search across template names, categories, purposes, and first outputs; show category counts and the result count; reveal results in batches; and preserve the chosen template while filters change. On phones, browsing and Crew details are separate views. Only implemented templates appear in the picker—planned catalog entries are not offered for installation.
The B2B SaaS finance role and tool map identifies eight job families: subscription billing and receivables; payments and recovery; revenue accounting and close; payables, procurement and spend; planning and SaaS performance; cash and treasury; tax; and payroll. These are catalog filters and possible roles, not eight Crews every customer must install. Tool suggestions depend on the customer's actual billing, accounting, and regional stack.
Start a small business with two default Crew identities: Finance Analyst owns read-oriented analysis, processor account checks, and planning; Billing Operations Coordinator owns customer-facing invoice follow-up, failed-payment investigation, and refund-request preparation. Add Revenue & Close Analyst or Spend & Payables Coordinator when a separate accounting or payment owner needs a distinct setup and access scope. Payroll Review Coordinator, Tax Compliance Coordinator, and Cash & Treasury Analyst are later specialist candidates. Tax Export Preparer is already available as an installable supporting pack for Finance Analyst; create a separate tax Crew only when a different owner, access scope, or review boundary requires it.
Later role candidates, not installable: Payroll Review Coordinator for payroll exceptions and approvals; Tax Compliance Coordinator for jurisdiction-specific obligations and professional review; Cash & Treasury Analyst for liquidity and cash-position review. These are distinct owners only when a Finance Analyst capability would be insufficient for access or accountability.
The Finance Operations Review Automation Playbook is an installable chat proposal. Builder can reuse or create distinct Billing Operations Coordinator and Finance Analyst Crews, then plan a manual billing exception queue → validated handoff → finance impact readout. Its ten setup checks track actual source access, owner decisions, Crew binding, validators, and a real first run. The packaged fixtures demonstrate the contract; they do not count as a customer's first run. Optional close and payables roles can be proposed, but their automated handoffs are outside this first contract. No recurrence, customer message, refund, or accounting write is activated by installation.
The Refund Request to Reconciled Outcome Automation composes Billing Operations Coordinator with its Refund Review pack and Revenue & Close Analyst. It validates the exact request/payment/amount handoff, then re-reads provider and ledger state. A first manual run may end at an approved but unprocessed decision. Refund execution, customer contact and ledger posting remain separately reviewed actions.
The Dispute to Reconciled Outcome Automation reuses Billing Operations Coordinator with Dispute Review and Revenue & Close Analyst. It begins with the exact current dispute, payment, deadline, authorized evidence and missing proof; submission, provider decision and principal/fee ledger treatment are separate states. One pending manual case is valid even when no packet was submitted. Evidence submission and accounting writes remain separate approved routes.
The Subscription Receivable to Verified Outcome Automation reuses Billing Operations Coordinator with Invoice Chasing or Failed Payment Recovery and Finance Analyst. It binds one exact invoice, recomputes the balance, checks retry and contact suppression, validates any claimed reminder receipt, then re-reads provider payment and finance records. A first run can truthfully end open. Provider collection and bank deposit have distinct evidence gates; installation sends nothing and does not retry a charge.
The Invoice Intake to Reviewed Payable Automation composes the Operations Document Intake Assistant with Spend & Payables Coordinator. The handoff validates a document's exact version, page-linked invoice fields, arithmetic and invoice key; Payables then re-reads current vendor, bill, credit and payment state before an owner decision. It can stop at read-only review. Creating a bill and paying it each require their own approval, current duplicate check and provider receipt.
| Crew template | Job and first useful output | Minimum user input | Optional recurring work |
|---|---|---|---|
| Finance Analyst — available v1 | Explain revenue, expense, cash, SaaS metrics, and reconciliation changes in a sourced finance brief. Add optional processor checks, forecasting, expense review, and tax export capabilities within this Crew. | Authorized records, period, currency, metric definitions; further inputs only for selected capabilities. | A weekly brief or processor account check can be this Crew's schedule. A broader review Automation is useful when distinct owners or Crews must coordinate. |
| Billing Operations Coordinator — available v1 | Review overdue invoices, failed payments, refund requests, and disputes; produce an exception queue and customer-safe drafts for approval. | Invoice/payment/refund records, billing and refund policies, contact rules, routing owner. | Billing Review, if a recurring goal and review policy are wanted. |
| Revenue & Close Analyst — available v1 | Reconcile subscription invoices, credits, cash, and ledger records into a close memo with source-linked exceptions. | Fiscal period, entity, accounting policy, billing and ledger records or exports. | Period Close Review when another Crew must review exceptions or forecast impact. |
| Spend & Payables Coordinator — available v2 | Review proposed purchases, vendor bills and expenses against current vendor, budget, duplicate and approval state. | Validated vendor comparison or bill/expense records, entity, currency, current sources and approval policy. | Vendor Evaluation to Purchase Decision; Invoice Intake to Reviewed Payable when a separate Crew extracts document fields. |
| Capability pack | Installed in | First result and boundary |
|---|---|---|
| Revenue Reconciliation — Finance Analyst procedure v1 | Finance Analyst | Match orders, invoices, payments, and refunds with a source-linked mismatch list. Read-only until the owner separately authorizes a correction. |
| Processor Account Checks — Finance Analyst procedure v1 | Finance Analyst | Read authorized Stripe or Paddle balances, transactions, payouts, fees, refunds, and disputes for a dated exception report; reconcile payout entries to deposits when bank evidence exists. An export works without a live connector. |
| Expense Review — Finance Analyst procedure v1 | Finance Analyst; Spend & Payables Coordinator when payment access differs | Categorize expenses under the owner's chart of accounts and approval rules. No automatic approval or payment. |
| Cash Flow Planning — Finance Analyst procedure v1 | Finance Analyst | Forecast from dated source balances, receivable/payable timing, and scenarios with stated uncertainty; do not present it as a verified balance. |
| Tax Export Preparer — available v1 | Finance Analyst by default; separate Crew when access requires | Reconciled transaction export and exception list for review by the owner and tax professional. No automatic tax classification, filing, or delivery. |
| Invoice Chasing — available v1 | Billing Operations Coordinator by default | Ranked overdue-invoice queue with current balance, due date, prior or scheduled contact, and unsent follow-up. Nine independent setup checks cover source access, policy, a real reviewed queue, and run choice. |
| Failed Payment Recovery — available v1 | Billing Operations Coordinator by default | Current invoice/payment retry state, prior dunning and a policy-safe next step. Nine independent setup checks; no charge retry or customer message is activated. |
| Refund Review — available v1 | Billing Operations Coordinator by default | Exact customer request, original and prior refunded amounts, remaining refundable amount, currency, policy and approver. Nine independent setup checks; a refund requires a separate approved action and provider receipt. |
| Dispute Review — available v1 | Billing Operations Coordinator by default | Current dispute status, deadline, evidence gaps and owner. Nine independent setup checks; evidence submission and customer contact remain separately approved actions. |
The Billing Operations Coordinator v1 skill can inspect these case types from authorized records and produce one review queue. The four deeper packs above can now be installed together on that Crew, each with its own skill, setup file, progress and fictional worked example. Use separate Crew identities only when owner, access or review boundaries differ. Installation adds no provider-specific write action.
Stripe check setup: choose the exact Stripe account, live/test mode, currencies, timezone, reporting window, and read scope. Verify one accessible balance transaction and payout, reconcile gross, fees, refunds, and net using their source IDs, and record expected payout timing or a mismatch. Stripe's pending balance is not a bank deposit. Do not call a missing payout a loss before its expected arrival. Save the last inspected cursor or period and deduplicate webhook events by event ID. An authorized invoice.payment_failed or payout.failed webhook can open an exception, but first validate its signature, account, object ID, and idempotency before a Crew acts on it. See Stripe balance transactions and Stripe events.
Refund boundary: the default pack reads and prepares a reviewed refund decision. An actual refund is a separate action with narrow Stripe write access, owner approval of the exact payment and amount, an idempotency key, and a saved Stripe result/receipt. Check prior partial refunds and the remaining refundable amount first; Stripe supports partial refunds and rejects amounts beyond the remaining charge. See Stripe refunds.
Tax Export keeps its own setup checklist, so a Finance Analyst can be ready for a sourced brief while tax export remains pending. The analyst's processor, SaaS metric, reconciliation, and cash procedures require source and definition checks for each actual request; the basic Crew checklist does not certify them all. Builder should inspect the existing Finance Analyst Crew before proposing a new one and create another only when the permission, owner, cadence, or independent-review boundary makes sharing inappropriate. Adding a pack never imports another Crew's connections or activates a schedule, function, trigger, refund, payment action, or delivery channel.
For a B2B SaaS company, the first useful post-sale journey is new customer to first value. Start with Customer Onboarding Coordinator and Product Adoption Analyst. Customer Health Coordinator reviews bounded adoption and support evidence; Renewal Coordinator separately verifies executed contract, notice, subscription and billing facts for an owner decision. Lifecycle Analyst compares mature signup cohorts under one day-7 activation and day-30 retention policy; this is a cohort job, not an individual account health score. These are reusable capabilities; one Crew may carry several when access and ownership are compatible. Each installed skill includes a fictional source-to-result example, a failed result and a role-specific setup probe; real account evidence and owner review still complete setup.
The Signed Deal to Onboarding Handoff Automation verifies the exact executed agreement, CRM revision, purchased scope, first-value promise and current entitlement, then asks the receiving CS owner to accept or return the handoff. A Closed Won stage alone does not start onboarding. The separate New Customer to First Value Automation consumes an accepted handoff or another authorized subscription source and proposes an owned milestone register → validated adoption readout → optional health review. Renewal Risk to Owned Decision joins a bounded health brief to current executed terms, notice arithmetic and billing state, then asks the renewal owner to decide the next reviewed step. Each has ten pending setup checks and requires a real manual run. Selection does not contact customers, update accounts, change terms, or enable recurrence. The Sales to CS handoff guide, Customer Success guide and renewal guide define their evidence boundaries.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Customer Onboarding Coordinator — available v1 | Accept or return a verified signed-deal handoff, then turn an authorized handoff into an owned milestone register with evidence and blockers. | Customer account, purchased scope, first-value goal, owner, target date, authorized handoff. | Signed Deal to Onboarding Handoff; New Customer to First Value |
| Product Adoption Analyst — available v3 | Verify first value, released-feature adoption, or one trial account’s usage with exact identity and coverage. | Account or eligible segment, versioned event/identity rule, observation window and authorized product export. | New Customer to First Value; Released Feature to Adoption Decision; Release to Observed Adoption; Trial Account to Reviewed Sales Assist |
| Lifecycle Analyst — available v1 | Compare mature signup cohorts' activation and retention with exact denominators, maturity, censoring and source coverage. | Product/tenant, cohort windows, versioned activation and retention predicates, identity rule, product and billing records, owner. | Activation and Retention Intelligence |
| Customer Health Coordinator — available v1, optional specialist | Review adoption, support and renewal signals in a sourced account brief. | Account, health rules, owner, first-value or usage observation and authorized context. | Optional health slot in New Customer to First Value; required bounded health slot in Renewal Risk to Owned Decision |
| Renewal Coordinator — available v1 | Re-read executed contract, notice and subscription/billing state for an owner decision, without changing terms or contacting the customer. | Exact tenant/account, legal entity, contract revision, subscription, notice policy, billing source, bounded health brief and renewal owner. | Renewal Risk to Owned Decision |
The five Crew templates are locally installable. The Support Case to Reviewed Resolution Automation Playbook composes Triage and Reply with optional Escalation. Builder inspects existing Crews and the live case source, then proposes a validated manual route. Its ten checks require exact case identity, priority and contact rules, current approved knowledge, real source access, owner review, and a representative run. A support case is the unit of work; Customer Success owns account-level adoption. Feedback & Review Analyst can also hand a validated theme to the separate Product decision route. Support Knowledge Curator owns article quality and proposes a reviewed update; it does not publish from installation. Verified Knowledge to Case Reply checks a live publication receipt and exact article revision before Support drafts a case reply.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Support Triage Assistant — available v2 | Classify one current case, its urgency, duplicate state, owner, and next review. | Authorized case and thread, priority policy, owner. | Support Case to Reviewed Resolution |
| Support Reply Drafter — available v2 | Prepare a grounded unsent reply for the exact case, recipient, and channel. | Current case, approved help sources, contact and approval policy. | Support Case to Reviewed Resolution; Verified Knowledge to Case Reply |
| Escalation Coordinator — available v2, optional specialist | Keep an impact brief current and track receiving-owner acceptance. | Escalation policy, case history, receiving team and deadline. | Optional escalation slot in Support Case to Reviewed Resolution |
| Feedback & Review Analyst — available v2 | Analyze a bounded feedback set into sourced themes and an owner action; public replies remain drafts. | Review or feedback export, time window, source coverage, response policy. | Feedback Theme to Product Decision |
| Support Knowledge Curator — available v1 | Find repeated unresolved questions and stale help instructions; prepare an article draft and later verify its published revision. | Current cases and article revision, approved product facts, owner and privacy rule. | Case Pattern to Knowledge Review; Verified Knowledge to Case Reply after publication evidence. |
The five locally installable Product roles span discovery, evidence-led decisions, prioritization, requirements and release readiness. Feedback Theme to Product Decision composes Support Feedback & Review Analyst with Product Feedback Coordinator. Released Feature to Adoption Decision composes Product Adoption Analyst with the same Product Crew. Opportunity to Reviewed Requirements and Approved Requirement to Release Readiness connect the four newer roles through separate owner gates. Release to Observed Adoption binds an actually verified release to the first bounded usage observation. Installation creates no issue, flag change, roadmap promise, customer message or recurrence.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Product Feedback Coordinator — available v3 | Compare validated feedback or feature-adoption evidence with current issues and prepare a traceable owner decision; setup certifies the selected evidence route. | Validated theme or feature observation, product/segment scope, current issue source, owner and decision criteria. | Feedback Theme to Product Decision; Released Feature to Adoption Decision |
| Product Discovery Researcher — available v1 | Turn interviews, cases and observations into one bounded opportunity with contrary evidence and a next research question. | Product, segment, authorized research sources, privacy rule and owner. | Opportunity to Reviewed Requirements. |
| Roadmap Prioritization Analyst — available v1 | Compare accepted opportunities against goals, evidence, capacity and current commitments for an owner decision. | Candidate IDs, strategy goal, scoring policy, current roadmap and owner. | Opportunity to Reviewed Requirements. |
| Product Requirements Coordinator — available v1 | Translate an accepted problem into scoped, observable acceptance criteria for Design, Engineering and QA review. | Accepted decision, user journey, current behavior, constraints and owners. | Opportunity to Reviewed Requirements; Approved Requirement to Release Readiness. |
| Product Release Coordinator — available v1 | Review exact build, flag, QA gate, help content and measurement readiness before a Product go/no-go. | Release/build, approved scope, rollout policy, QA gate and owners. | Approved Requirement to Release Readiness; Release to Observed Adoption after a verified deployment. |
For a B2B SaaS company receiving enquiries from a new website, start with Lead Intake & Qualifier and Sales Follow-up Coordinator. Use Account Researcher when sourced company context will improve the seller's response or call preparation. These are reusable Crew templates, not a requirement to create six separate Crews for every company. If one owner can safely handle the entire job in one Crew, use chat or a Crew schedule. A distinct owner or access boundary justifies a multi-Crew route.
The Discovery to Reviewed Proposal Automation is also installable as a chat proposal. It joins an exact call brief to an approved post-call discovery note and a current-price unsent proposal, with a blocking validator and a real manual-case check. It stops after the brief when discovery has not happened; approval and delivery remain separate actions.
The Pipeline Health to Owned Action Automation joins Pipeline Analyst with Deal Follow-through Coordinator for one stale opportunity. It needs two comparable CRM snapshots and a fresh opportunity, activity and contact read. Builder proposes the team and a manual first case; the seller reviews the resulting action register. Selection creates no CRM task, stage move, message or recurrence.
The Trial Account to Reviewed Sales Assist proposal reuses Product Adoption Analyst and Sales Follow-up Coordinator. It binds one current trial and subscription revision, validates account-level use and coverage, then joins the exact CRM account and current contact policy. Unknown coverage, missing permission or a converted trial cannot produce a draft. The output is an unsent draft, no-contact or needs-review decision; later sending and booking need separate evidence. Its ten setup checks remain pending until a real authorized manual case and owner review.
The Inbound Lead-to-Meeting Review Automation Playbook is an installable chat proposal. Builder inspects existing Crews, lead sources, booking route and connections, then proposes qualification → validated handoff → owner-reviewed booking offer. Optional account research has its own validated handoffs. Its ten checks require a real inbound source, fit and contact policy, current prior-contact state, Crew binding, validator steps, a reviewed plan, and a real manual first run. A separate approved action may send through a verified provider and save a delivery receipt; a calendar or CRM event is required to record a booking. The example artifacts are fictional contract samples. Instant on-page booking requires a separate website integration.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Lead Intake & Qualifier — available v1 | Deduplicate and assess an inbound request against owner-defined fit rules; return a sourced lead brief and next owner decision. | Inbound enquiry/export, ideal-customer criteria, routing owner and contact policy. | Inbound Lead-to-Meeting Review |
| Account Researcher — available v1, optional specialist | Prepare verified company context, labeled hypotheses and seller questions without assuming purchase intent. | Company/domain, approved research scope and offer. | Optional research slot in Inbound Lead-to-Meeting Review |
| Sales Follow-up Coordinator — available v3 | Prepare a permission-gated, unsent inbound or trial assist and separate provider-observed delivery and booking. | Validated lead or trial usage, exact CRM account and recipient, current permission and suppression, approved offer, owner, booking URL and outcome source. | Inbound Lead-to-Meeting Review; Trial Account to Reviewed Sales Assist |
| Sales Call Briefing Assistant — available v1 | Bind an exact meeting and opportunity, separate verified context from questions, and prepare a seller-reviewed brief. | Meeting details, CRM notes or files, approved product material, seller. | Discovery to Reviewed Proposal |
| Proposal Drafter — available v1 | Draft a sourced, unsent proposal from approved discovery and current pricing; flag missing scope or approvals. | Approved discovery revision, opportunity, pricing and product sources, commercial owner. | Discovery to Reviewed Proposal |
| Pipeline Analyst — available v1 | Explain comparable CRM snapshot movement and stale deals with stable IDs, currency rules and coverage gaps. | CRM snapshots/export, stage definitions, period and owner. | Pipeline Health to Owned Action |
| Deal Follow-through Coordinator — available v1 | Recheck one opportunity and activity history, then prepare a seller-owned next-step register with suppression and duplicate safeguards. | Validated exception, current CRM/activity source, seller, stale and contact policy. | Pipeline Health to Owned Action |
Use the customer's CRM or form export for a first read-only result. HubSpot and Salesforce are relevant provider examples, not connected accounts by default; an email or calendar connection is needed for approved delivery and outcome tracking. The Sales implementation guide records the handoff, validation, and setup boundaries.
For a new company with a recently launched site, start with a result that can be produced from the public website and owner context. Add Search Console and analytics when available; a new site may not have enough history to support trend claims. One Crew can install several packs. Website Growth Loop proposes the broader multi-Crew site journey; SEO Intelligence proposes a focused technical-SEO-to-buyer-question route. The eleven specialist Crew templates below are available; both Playbooks guide setup in chat and do not start recurrence when selected.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Website Growth Starter | Audit the public site and produce a source-linked 30-day plan for attracting relevant visitors. Available v1. | Site URL or page export, offer, target audience, primary visitor action. | Website Growth Loop |
| SEO Analyst | Prioritize crawl, indexability, internal-link, and on-page issues with page-level evidence. Available v1. | Site, approved crawl scope, Search Console if available. | SEO Intelligence |
| Search Opportunity Mapper | Map buyer questions and search intent to existing pages and a ranked content gap list. Available v1. | Offer, audience, market, site pages, optional search data. | Required search slot in Website Growth Loop and SEO Intelligence |
| Content Brief Writer | Create a sourced page brief with audience, angle, claims to verify, and success signal. Available v1. | Topic, buyer need, brand guide, source material. | Optional validated content slot in Website Growth Loop |
| Content Page Builder | Draft a useful, reviewable page with sources, internal links, and a clear next action. Available v1. | Approved brief, existing site content, publishing format. | Optional validated page slot in Website Growth Loop; publication is separate |
| Website Publishing Coordinator | Verify an approved page’s provider publication receipt and exact live revision, or report readiness blockers. Available v1. | Approved page artifact, canonical URL, site owner, release authority, live-check method. | Optional validated publication slot in Website Growth Loop |
| Search Console Optimizer | Find pages with measurable query opportunities and propose natural title, copy, or link improvements. Available v1. | Authorized Search Console property or export with page/query data. | Search Query Review |
| Traffic & Engagement Analyst | Explain landing-page, source, and conversion changes with a prioritized action list. Available v1. | Analytics export or connection, event definitions, comparison window. | Website Traffic Review |
| AI Visibility Analyst | Test buyer questions across chosen answer engines and summarize citation gaps. Available v1. | Brand, competitors, buyer questions, measurement method. | AI Visibility Intelligence |
| Landing Page Optimizer | Audit one conversion path and prepare a bounded page test or revision for review. Available v1. | Page URL, visitor intent, target action, available conversion data. | Landing Page Experiment Review |
| Content Distribution Coordinator | Find relevant channels and prepare a reviewable distribution plan and outreach drafts. Available v1. | Published asset, audience, approved channels, contact policy. | Content Distribution Review |
Suggested sequence: audit and baseline → choose audience/search opportunities → improve or create pages → distribute → measure and repeat. The first Website Growth Brief must not claim a ranking or traffic increase that has not been observed. Installing a template never grants Search Console, analytics, CMS, repository, email, or outreach access.
This is Marketing outside the Website Growth subcategory. All six Crew rows below are locally installable with pending nine-check chat setup. Campaign Signal to Reviewed Experiment composes Campaign Performance Analyst → Growth Experiment Planner, with optional competitor context. Funnel and Conversion Intelligence composes Funnel Analyst → Growth Experiment Planner for a separate signup-to-paid job. Activation and Retention Intelligence reuses Growth Experiment Planner after Lifecycle Analyst provides mature cohort evidence. Growth Experimentation and Follow-Through takes a separately approved plan to verified provider state and outcome review. Builder inspects existing Crews and real source access, validates each handoff and plans a manual first run. The remaining Growth Analytics Workflow guides in the Playbooks README remain separate routes. Selection changes no budget, variant or schedule.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Competitor Intelligence Analyst — available v2, optional specialist | Track exact competitor product and plan changes with dated prior/current primary sources, relevance and unknowns. | Own offer and buyer, bounded competitor list, topics, baseline, market, owner. | Optional context slot in Campaign Signal to Reviewed Experiment; standalone competitor watch remains a separately reviewed route. |
| Campaign Performance Analyst — available v2 | Compare platform spend and clicks with deduplicated qualified CRM events under the same period and attribution rule. | Campaign/account IDs, current and baseline records, qualified-event definition, time zone, owner. | Required measurement slot in Campaign Signal to Reviewed Experiment. |
| Funnel Analyst — available v2 | Reconcile one eligible signup-to-paid cohort across product events and billing with stage counts, identity coverage, comparable windows and no causal claim. | Product/tenant/cohort, event and paid-state definitions, identity rule, baseline/current sources, timezone and owner. | Required observation slot in Funnel and Conversion Intelligence. |
| Growth Experiment Planner — available v2 | Turn a sourced signal into one falsifiable test with eligible unit, primary and guardrail metrics, sample/stop rule, owner and approval boundary. | Source brief, baseline, target audience, metric and constraints, change authority. | Required plan slot in Campaign Signal to Reviewed Experiment, Funnel and Conversion Intelligence, and Activation and Retention Intelligence. |
| Experiment Run Coordinator — available v2 | Verify exact plan approval, provider launch and exposure evidence while preserving rollback ownership. | Frozen plan/revision, owner decision, provider object, variants, population, assignment and readout window. | First slot in Growth Experimentation and Follow-Through. |
| Growth Outcome Analyst — available v2 | Recompute primary and guardrail outcomes against the frozen rule and report measured or inconclusive evidence. | Validated execution record, exposure and outcome sources, sample/window gates, owner. | Second slot in Growth Experimentation and Follow-Through. |
All six Crew roles below are locally installable with pending nine-check chat setup. Keep separate Crew identities only when owner, source access, or recurring decision differs; meeting actions, project status, and leadership review can be compatible capabilities on one Crew for a small team. The Meeting Decision to Owned Follow-through Automation is a chat-led proposal: Builder inspects existing Crews and current meeting and tracker records, then proposes explicit validators, owner review, and a manual first run. Vendor Researcher and Spend & Payables Coordinator also form Vendor Evaluation to Purchase Decision, with current quote, duplicate, budget and security/privacy review. The Order Exception to Reviewed Update route joins a generic Order Operations investigation to a separate Support owner for an unsent exact-case update; it requires carrier evidence and a blocking validator before Support reads the exception. Document Intake Assistant also participates in Invoice Intake to Reviewed Payable with a separate AP owner. Selection creates no task or notification.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Chief of Staff — available v2, optional specialist | Synthesize sourced priorities, blockers, and owner decisions into an operator brief. | Goal IDs, current updates, decision owner, reporting period. | Optional review slot in Meeting Decision to Owned Follow-through |
| Meeting Actions Coordinator — available v2 | Extract explicit decisions and action items with source spans, owner acceptance, due dates, and duplicate links. | Authorized notes revision, participant map, task convention. | Meeting Decision to Owned Follow-through |
| Project Status Reporter — available v2 | Reconcile milestones and tasks to source-observed open, blocked, done, or pending state. | Project and task IDs, tracker state, status rules, reporting owner. | Meeting Decision to Owned Follow-through |
| Order Operations Coordinator — available v2 | Investigate generic commerce or ERP order exceptions and prepare reviewed next actions. | Order, fulfillment and carrier records, policy, owner. | Order Exception to Reviewed Update for a distinct Support owner; proactive Order Watchdog remains proposed |
| Vendor Researcher — available v2 | Compare exact vendor products and plans against weighted criteria with evidence and cost assumptions. | Requirements, vendor scope, budget, security constraints, decision owner. | Vendor Evaluation to Purchase Decision when procurement needs a distinct owner |
| Document Intake Assistant — available v2 | Extract customer-defined fields with source spans, validation, duplicate check, and reviewer queue. | Authorized documents, schema, privacy and duplicate rules, owner. | Invoice Intake to Reviewed Payable for vendor invoices; broader Document Intake Queue Automation remains proposed |
The seven core Crew rows below are locally installable with skills and pending nine-check chat setup. Each installed skill includes a fictional input and reviewed result, a failed result, and a role-specific hard check; these still require a real customer-case run during setup. Engineering Operations Intelligence composes a governed team metric with Delivery owner review; Incident to Verified Recovery composes active investigation and delivery; Post-Incident Review and Actions composes a separate retrospective and control verification after stability. These are installable Builder proposals that can reuse suitable Crews. Other engineering Workflow guides cover related methods without installing these Crew identities. Within Engineering, QA owns test and release-gate evidence; Security owns application risk and remediation evidence. Engineering connects monitoring, issue tracking, repositories, CI, deployments, and cloud billing. Generic PR review is not a priority Crew template.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Incident Investigator — available v1 | Correlate alerts, logs, and deploys into a sourced timeline, labeled hypotheses, and an owner action queue. | Incident scope, authorized telemetry, escalation policy. | Incident to Verified Recovery Automation; Incident Investigation and Coordination Workflow also exists. |
| Engineering Delivery Coordinator — available v1 | Trace a blocked change from issue to PR, CI, deployment, and owner; return a sourced blocker ledger with the next action and evidence of release status. | Issue tracker, repository and CI read access, deployment source, ownership and release policy. | Incident to Verified Recovery; Performance Regression to Owned Change; CI and Deployment Failure Triage Workflow also exists. |
| Engineering Operations Analyst — available v1 | Reconcile one team delivery, quality or reliability metric with exact population, coverage, comparable windows and an owner question. | Team/service, metric rule, source snapshots, window policy, target and owner. | Engineering Operations Intelligence with Delivery Coordinator. |
| Post-Incident Reviewer — available v1 | Reconstruct a stable incident with impact arithmetic, source-linked timeline, factor labels, unknowns and reviewable action proposals. | Canonical incident/recovery, telemetry/deploy sources, impact rule, reviewer and privacy policy. | First slot in Post-Incident Review and Actions. |
| Improvement Follow-Through Coordinator — available v1 | Reconcile reviewed action IDs, owner decisions, issue receipts and later independent control evidence. | Validated review, accepted action policy, issue source, verification test and owner. | Second slot in Post-Incident Review and Actions. |
| Performance Investigator — available v1 | Analyze latency or page performance regressions and produce a reproducible diagnosis. | Targets, traces or test runs, performance budgets. | Performance Regression to Owned Change; Browser and API Performance Validation Workflows also exist. |
| Cloud Cost Analyst — available v1 | Explain cost changes and propose evidence-backed savings with service-risk checks. | Billing data, ownership map, budget, change policy. | Cost Anomaly to Verified Savings Automation composes Delivery and Finance with typed handoffs. |
QA is an Engineering browse specialty, even though its existing Workflow packages live under browser-qa/ inside the Agentic Engineering Platform. The three Crew templates below are locally installable with pending nine-check chat setup. The Release Candidate to Reviewed Gate Automation Playbook composes Browser Journey QA Analyst → Release Quality Assistant with optional Flaky Test Investigator. Its ten checks bind an exact candidate, suite policy, diagnostic evidence, Crew IDs, explicit validator steps, owner review, and a real manual run. Role and permission validation can be added as a scoped capability. A security finding discovered during QA should hand off to Security without claiming it was remediated.
The Crew uses the customer's test runner, CI, issue tracker, browser, and release records to decide what failed, who should act, and whether a retest supports release. A testing SaaS may produce the test result; the Crew owns investigation and the reviewed decision.
| Crew template | Job and first useful output | Minimum user input | Existing Workflow Playbook or proposed Automation |
|---|---|---|---|
| Browser Journey QA Analyst — available locally | Run an approved user journey and return exact pass/fail evidence with screenshots, console/network errors, and reproduction steps. | Approved journey, environment, test account, expected result. | Required Journey slot in Release Candidate to Reviewed Gate; Critical Journey Validation also exists. |
| Flaky Test Investigator — available locally | Distinguish intermittent product failures from test instability and propose a verified fix or owner action. | Test history, exact build, traces, retry policy. | Optional Flake slot in Release Candidate to Reviewed Gate; Flaky-Test Detection and Stabilization also exists. |
| Release Quality Assistant — available locally | Inspect a release candidate and summarize tests, failures, evidence, and a proposed gate decision. | Repository or build, test policy, release scope. | Required Gate slot in Release Candidate to Reviewed Gate; Release and PR Quality Gate also exists. |
Security is an Engineering browse specialty for authorized risk work. The three Crew templates below are locally installable with pending nine-check chat setup. They cover bounded assessment, access review, remediation, and retest. Finding to Verified Remediation composes Findings Analyst → Remediation Coordinator; Access Exception to Verified Fix composes Access Review Analyst → Remediation Coordinator for an exact policy cell and independent same-cell retest. Both are chat-led proposals requiring written scope, blocking validators, owner review and a real manual case. Role and Permission Validation remains a method guide under its canonical browser-qa package ID.
Security tools can supply scanner findings, dependency alerts, and access evidence. The Crew validates relevance to the customer's asset, routes the finding to an owner, follows the approved fix, and closes it only with retest evidence.
| Crew template | Job and first useful output | Minimum user input | Existing Workflow Playbook or proposed Automation |
|---|---|---|---|
| Security Findings Analyst — available locally | Triage authorized findings and draft reviewed remediation steps with verification criteria. | Findings, asset scope, severity policy, code access. | Required Finding slot in Finding to Verified Remediation; Application Security Assessment and Remediation also exists. |
| Access Review Analyst — available locally | Compare actual user, role, and tenant permissions to an approved policy; return evidence-backed exceptions. | Role matrix, test accounts, asset scope, decision owner. | Required Access slot in Access Exception to Verified Fix; Role and Permission Validation remains a Workflow guide. |
| Security Remediation Coordinator — available locally | Track an approved finding or access exception through owner assignment, change review, deployed retest, and closure evidence. | Finding or exception ID, approved fix, code/deploy evidence, retest rule. | Required Remediation slot in both Security Automation routes; existing Application Security Workflow remains available. |
GTM is a cross-functional browse category for a company taking an offer to market and turning demand into qualified pipeline. Marketing owns audience, message, content, and channels; Sales owns lead fit, contact, and meeting outcomes. Five GTM-specific roles cover strategy, launch, cross-system revenue measurement, seller enablement and pricing/package review. They can reuse Marketing and Sales Crews under one buyer journey rather than copying their templates. Launch to Qualified Pipeline composes strategy and launch with the existing Sales route; Offer to Seller Readiness and Launch Signal to Pipeline Review give the three newer roles separate, source-bound routes. Accepted Offer to Launch Readiness joins pricing, positioning and launch owners before any channel goes live.
The Crew and Automation use the customer's research, enrichment, CRM, analytics, campaign, and sequencing products where available. The agent job is to connect the launch plan to approved campaigns, handle lead exceptions, and verify a pipeline result against source records.
| Crew template or capability | Job and first useful output | Minimum user input | Status and Automation |
|---|---|---|---|
| Website Growth Starter, Search Opportunity Mapper, Content Distribution Coordinator | Find buyer questions, improve the site plan, and prepare reviewed distribution. | Offer, audience, site, relevant buyer evidence, approved channels. | Available as separate Website Growth Crews; Website Growth Loop covers the first two-Crew route. |
| Lead Intake & Qualifier, Account Researcher, Sales Follow-up Coordinator | Review inbound interest, prepare context and an approved booking offer. | Lead source, ideal-customer criteria, contact policy, owner, booking route. | Available as Sales Crews; Inbound Lead-to-Meeting Review covers qualification to reviewed follow-up. |
| GTM Strategy Analyst — available locally | Turn the offer, ideal customer, positioning, channels, and goals into an evidence-linked launch brief. | Offer, customer evidence, market, owner, success metric. | Launch to Qualified Pipeline. |
| Launch Coordinator — available locally | Keep approved launch assets, owners, dates, dependencies, and first pipeline signals in one action ledger. | Launch plan, asset inventory, owners, approved channels, measurement sources. | Launch to Qualified Pipeline. |
| Revenue Operations Analyst — available v1 | Reconcile campaign, form, lead, account and opportunity records with stage and attribution coverage. | Period, offer, CRM and attribution rules, authorized source exports and owner. | Launch Signal to Pipeline Review. |
| Sales Enablement Coordinator — available v1 | Prepare current seller guidance from approved offer, pricing, product claims and buyer objections. | Offer and persona, approved claim sources, objection records and content reviewer. | Offer to Seller Readiness; an approved brief may later feed Sales Follow-up Coordinator. |
| Pricing & Packaging Analyst — available v1 | Compare plan entitlements, buyer fit, cost and contract exceptions for a reviewed offer decision. | Current plan and entitlement matrix, buyer and cost evidence, contracts and pricing owner. | Offer to Seller Readiness; Accepted Offer to Launch Readiness. |
The installable Launch to Qualified Pipeline Automation connects a reviewed message and site plan → approved distribution → captured lead → qualification → reviewed follow-up → observed meeting or pipeline outcome. It needs stable campaign and lead IDs, attribution limits, a verified source and consent policy, and a manual first route. It is a chat-led Builder proposal with ten pending checks and contract validators; selecting it does not activate a campaign or contact.
Shopify is a store-specific browse category for ecommerce businesses using that platform. A generic Website Growth Crew can inspect a public storefront, but Shopify catalog, order, inventory, return, payment, and revenue claims require an authorized store connection or export. Store writes and customer messages need a separate reviewed route. The seven Crews below are locally installable with skills and pending nine-check chat setup. Seven Shopify Playbooks are Builder proposals with ten pending checks; they do not activate a payment, refund, customer message, inventory adjustment, purchase order, product publication, or recurrence. The operator category guide maps jobs, source probes, boundaries, and repeat work.
The Engineering and Shopify expansion queue prioritizes order risk, B2B wholesale, promotions and subscription commerce as distinct candidate jobs. They are not included in the seven installed Shopify Crews.
Store teams may already use Shopify plus support, returns, analytics, email, and fulfillment apps. A Crew works through the store team's queue across those systems: identify a specific product or order, apply store policy, prepare the next action, and verify the resulting state.
| Crew template | Job and first useful output | Minimum user input | Suggested Automation |
|---|---|---|---|
| Store Operations Coordinator — available v1 | Investigate stuck orders, fulfillment and inventory exceptions with source-linked owner actions. | Authorized Shopify order/fulfillment export or account, service policy, owner. | Order Exception to Resolution; Inventory Availability to Owner Action; Payment Exception to Order Decision. |
| Returns & Refunds Coordinator — available v1 | Review return/refund requests against order, payment, delivery, and policy; prepare an unsent customer reply. | Store/order ID, return request, payment and delivery records, refund policy, approval owner. | Order Exception to Resolution. |
| Catalog & Merchandising Analyst — available v1 | Identify missing product facts, variant conflicts, out-of-stock presentation, and search/navigation gaps with exact IDs. | Store URL or product export, catalog rules, priority collection, owner. | Storefront Opportunity to Verified Change; Inventory Availability to Owner Action; Product Launch Readiness to Go/No-Go. |
| Shopify Growth Analyst — available v1 | Analyze storefront discovery, product-page quality, traffic and checkout-path evidence; propose bounded improvements. | Storefront URL, buyer, product scope, analytics or export for performance claims. | Storefront Opportunity to Verified Change; Product Launch Readiness to Go/No-Go; Checkout Signal to Reviewed Recovery with route-specific minimal checkout signal. |
| Payment Operations Investigator — available v1 | Reconcile exact order transaction kind/status, capture and refund evidence, and fulfillment impact in one currency. | Store/order/transaction IDs or scoped export, capture policy, payment owner. | Payment Exception to Order Decision. |
| Checkout Recovery Coordinator — available v1 | Review one abandoned checkout against completion, consent, suppression, and prior sends; prepare an unsent draft when eligible. | Store and checkout ID, market/channel, merchant contact policy, authorized order/consent/provider records, owner. | Checkout Signal to Reviewed Recovery. |
| Replenishment Planner — available v1 | Compute a supplier-aware item/location reorder proposal and separate PO status from stock receipt. | Authorized InventoryItem/Location, demand and incoming records, supplier terms, procurement owner. | Inventory Risk to Reviewed Replenishment. |
The existing Order Operations Coordinator proposal under Operations could later become a shared capability instead of a duplicate Shopify Crew. Keep one canonical ID and put a Shopify-specific pack on it only when store access, schemas, and policy genuinely differ. Website Growth Starter, Landing Page Optimizer, and Traffic & Engagement Analyst may also be discovered here for their generic public-storefront or analytics jobs; they do not inherit Shopify credentials or order access.
Each catalog entry should eventually include:
- Stable ID, category, name, one-sentence purpose, icon, and search terms.
- Crew identity and starter instructions, including its scope and when to ask a human.
- Two or three example requests and one inspectable example output, clearly marked as illustrative.
- Required and optional MCP capabilities, skills, channels, input data, and a setup checklist that checks actual connection state.
- Suggested Crew schedules, authenticated triggers, and typed functions, plus any separate goal-chasing Automations and metrics.
- Version and update notes so existing customer Crews are not silently rewritten.
Every template must include a project-owned checklist of five to ten checks. The first checks verify that this Crew can perform the pack's job and that its skill is selected; later checks cover customer data, definitions, a tested first result, and decisions about optional delivery or recurring work. The Crew reads and updates that checklist through chat. The frontend only displays whether each pack's setup is pending or complete, based on its saved checklist. Optional connections are not required if the owner chooses a valid file-based or chat-only path.
Finance Analyst v1 declares nine setup checks in its copied TEMPLATE_SETUP.json. The chat header shows Setup pending or Setup complete and starts a setup conversation when clicked. The Crew reads the checklist and marks a check complete in the same file only after verifying it; optional decisions can be completed when the owner explicitly chooses not to configure them. The header never marks a chat request as completion on its own. Existing Finance Analyst Crews with the older progress-only file are migrated without losing completed check IDs.
No entry should be labeled ready to use on the public website until a person can create it from the catalog, complete its stated setup, and produce the example output using supported product capabilities.
The template must declare capabilities, not assume one provider. For example, Lead Qualifier needs a way to read lead records; HubSpot, another CRM MCP, or a customer-provided file may satisfy that requirement. A provider-specific template may recommend a provider, but its preview must say so.
| Template field | Meaning | Creation behavior |
|---|---|---|
| Bundled project skill | The template's reusable procedure and checks, stored as a project-local SKILL.md. |
Copy into the new Crew and select it for that Crew. Finance Analyst v1 does this. It contains no customer facts or credentials. |
| Additional skill requirements | Capabilities such as spreadsheet analysis or browser research that need an existing skill. | Resolve installed skills and show any missing ones. Review the source before installing an external skill. |
| Required MCP capabilities | The minimum tools needed for the promised connected behavior, including read or write access. | Show compatible connected servers, let the owner choose an account/server, and select it for this Crew after permission review. |
| Optional MCP capabilities | Tools that enhance the template but are not needed for its minimum output. | Offer them during setup; keep the Crew usable without them. |
| Channels | Slack and WhatsApp routes, or Gmail access, when the job needs messages. | Set up through their existing Crew controls. Gmail and bot routes are separate from MCP selection. |
| Secrets and folders | Named credentials or administrator-authorized file access needed for a particular setup. | Ask the owner to attach them explicitly. Never put values or existing customer paths in a template. |
The Crew chat shows each pack as Setup pending or Setup complete. Clicking Set up in chat asks the Crew to inspect that pack's checklist, verify what is already available, and finish the remaining checks conversationally. A pack is ready for a particular job only after its required capabilities are tested with the user's access. Optional capabilities do not block the core job when the owner explicitly chooses to skip them.
For example, Finance Analyst bundles its finance-analysis procedure. An uploaded statement is enough to produce its first brief. Spreadsheet read access can be selected if already connected; an accounting MCP is optional. Posting the brief to Slack requires a separately configured route and approval policy. The template never copies a previous user's connection, token, selected secret, or Slack channel.
Current Crew has separate MCP, Skills, Slack, WhatsApp, and Gmail controls in its Integrations view. Template creation should use the same project selections and connection rules rather than introduce a second credential store. The server must validate the chosen resources against the owner and the new project before recording them.
Templates should include reusable definitions and setup suggestions for these Crew capabilities. They should not start recurring work or expose a callable function merely because a user selected a template.
| Capability | Template contains | Setup and activation |
|---|---|---|
| Crew schedule | Suggested name, one complete message for the Crew, cadence, timezone question, required connections, and expected output. | Owner chooses the actual cadence and timezone. Create paused, test once with the owner's data, then enable explicitly. A Crew schedule sends a message to the Crew conversation; it is not a goal-chasing Workflow run. |
| Authenticated trigger | Event purpose, one saved instruction, expected payload fields, authentication options, and example test payload. | Owner chooses the source and authentication. Create only during setup, show its one-time secret privately, test a delivery, then enable. No endpoint or credential is copied from a template author. |
| Crew function | Stable function name, description, typed input and result schemas, execution instructions, required skills/MCP capabilities, and an example call/result. | Show the contract for review. Register it only after the owner accepts it and required capabilities are ready, because other Crews and workflows can call it. Test schema validation and an authorized call. |
| Goal-chasing Automation | Suggested outcome, metric, and relationship to the Crew. | Create as a separate Automation through its own setup and approvals. Do not turn a Crew schedule or function into a Workflow by implication. |
For Finance Analyst, a template might suggest a Monday finance-brief schedule, a new_statement webhook trigger, and an analyze_finances(period) function returning a structured brief. These are suggestions until the owner chooses a data source, reviews access, supplies a real timezone or event source, and tests the output. The separate Weekly Business Report Automation can be offered when the customer wants a measured recurring goal.
The setup checklist should report these independently: suggested, configured but paused, tested, and active. Template updates must never silently change an active schedule, trigger, function contract, or goal-chasing Automation.
Auto-synced from docs/ on main. Edit there, not here.