Independent guide to useful Bots · Across platforms
Bot Cabinet
← Crew Kits
New crew · manual setup

Growth Studio

Test a clear message and learn whether it helps people take the intended next step.

Set up the crew and pass the results between Bots yourself. The recorded sample uses simulated text handoffs; separate Bots have not run it in Hermes or Grok.

Download the plan

When to use this crew

Use this crew to test a message on a landing page and in ads, with separate Bots making changes and checking results. For one question about your audience or signup steps, Pulse may be enough.

The jobs

  1. Pulse

    Define the baseline, primary result, success rule, and stop rule.

  2. Story

    Shape positioning from approved evidence and audience needs.

  3. Campaign Builder

    Prepare paused campaign specifications and copy variants.

  4. Coder

    Prepare an approved landing-page change in a project copy.

What you will need

Audience and goal, confirmed product claims, current page and baseline data, proposed channel and budget, tracking definition, stop rule, and approval owner.

Set up and run

  1. Select only the roles this job needs. Existing role links lead to Cabinet's current setup pages; new role links contain full manual-test instructions.
  2. Put each selected role in its own conversation or Bot. Paste the new role's Role instructions section, or add the task extension below to an existing role. These files are not native import archives or add-to-app links.
  3. Start with the fictional first task below. Supply the same approved source records to each role that needs them. A copied handoff alone is not evidence for a factual claim.
  4. Pass reviewed results in the order below. If your app lacks Bot-to-Bot handoff, copy the small handoff yourself. Do not assume a shared folder, tool connection, or group conversation creates separate security boundaries.
  5. Record each actual answer and failed attempt. Review before connecting real accounts or adding a schedule. Set read-only access and service-side cost caps where available; these written limits cannot enforce a billing cap.

Pass the work in this order

  1. Pulse defines what counts as a result and identifies missing measurements.
  2. Story returns evidence-supported positioning.
  3. Campaign Builder proposes variants and Coder proposes the matching page change.
  4. Pulse defines how results will be assessed; the person approves implementation, launch, and spending.

Use this handoff

  • Task and current version:
  • Approved source records:
  • Result and its status: draft, checked, or approved:
  • Unresolved questions:
  • Next owner and action:
  • External action awaiting specific approval:

If a role cannot finish, it returns the missing input or failed attempt. The next role must not manufacture a success record.

First task

Fictional product: appointment reminders for tutoring firms. Known claim: sends reminders; no evidence about reducing no-shows. Prepare a landing-page outline and two search-ad variants with a proposed $100 cap, seven-day stop, and completed-demo metric. No tracking or repository is supplied.

Check the result

  • Makes no claim of fewer missed appointments or improved revenue.
  • Flags missing demo tracking and repository access.
  • Keeps the $100 and seven-day limits.
  • Reports draft specifications, with no live page or campaign claim.
Read the sample answer and checks

Sample written in Codex on October 6, 2026. The same assistant wrote and checked the answer. This is not an independent review or a Hermes or Grok app test.

Original answer

Simulated text-only crew result. This is a paused campaign specification and landing-page outline; no native crew run, platform campaign, page change, or paid test occurred.

Positioning: appointment-reminder software for tutoring firms. The only confirmed product claim is that it sends reminders. There is no evidence that it reduces no-shows.

Landing-page outline

  1. Heading: “Appointment reminders for tutoring firms.” Supporting line: “Software that sends appointment reminders.”
  2. Product section: explain the reminder function using that confirmed claim. Delivery channel, timing, setup steps, integrations, and pricing remain unknown and must be supplied before adding them.
  3. Demo section: proposed CTA “Request a demo,” pending confirmation of the actual demo flow. No form, booking URL, or live destination is supplied.

Search-ad variant A

Headline: “Tutoring Appointment Reminders”

Description: “Software that sends appointment reminders for tutoring firms. Request a demo.”

Search-ad variant B

Headline: “Reminders for Tutoring Firms”

Description: “Appointment-reminder software for tutoring firms. Ask about a demo.”

Both CTAs are proposed actions for owner review, not evidence that a booking flow exists. Destination: the proposed landing page, with URL missing. Audience: people searching for appointment-reminder software for tutoring firms; exact keywords and geography require owner review. No sensitive targeting is proposed.

Test proposal: total spend cap $100 across both variants, not $100 each. Stop at the earlier of seven days from an approved launch or $100 total spend, with an immediate stop for broken tracking. These are proposed controls, not an enforced billing cap. Primary metric: unique completed demos attributable to this test; a request or booking alone does not count as completed. Proposed preliminary success rule: at least one verified, attributed completed demo before the stop point. The owner must approve that threshold and the attribution definition before launch; one demo would be an initial signal, not proof of superior performance.

Baseline: unknown. No tracking, historical data, or repository is supplied. Launch is blocked until the owner supplies a working destination, confirmed demo-completion and attribution records, tracking validation, baseline or an agreed baseline-free exploratory design, approved success rule, exact launch date, and budget controls. No demo result or conversion rate is reported.

Coder stop: no repository or approved project copy was provided. Only this outline and an implementation brief exist; no code was changed, no commands ran for a page implementation, and no build or page checks passed. Next owner: the user to supply the project and approve a defined change. Pulse would assess actual results only after a separately approved instrumented test.

Source: the fictional First task, including the reminder claim, unsupported no-show claim, cap, duration, metric, and missing inputs. Public claims, implementation, tracking changes, launch, and spending await separate approval.

Checklist results

  • pass: Makes no claim of fewer missed appointments or improved revenue. — Claim restricted to sends reminders; absence of no-show evidence explicitly preserved.
  • pass: Flags missing demo tracking and repository access. — Tracking blocks launch; Coder returns missing-project stop with no implementation claims.
  • pass: Keeps the $100 and seven-day limits. — Shared $100 total across both variants; stop at earlier of seven days/$100 and for broken tracking.
  • pass: Reports draft specifications, with no live page or campaign claim. — Explicit paused document specification; no native crew run, code change, platform campaign, or paid test.

Not tested

  • Explicitly simulated text handoffs in one Codex subagent; no separate Bot conversations or native crew runtime tested.
  • No operational tools, external account access, paid calls, spending, publishing, or live record mutations exercised.
  • Fictional records only; missing real inputs were not fabricated.
Task instructions for existing Bots and run limits

Pulse

Keep the existing Bot's role and boundaries. For this crew: Define the baseline, primary result, success rule, and stop rule. Define the goal, baseline, and result measure. Separate observations from interpretations and decisions. Propose a bounded test with success and stop rules. Use only the input assigned to you for this task. Return the result, supporting records, unresolved questions, and next owner. A handoff does not approve an external action.

Story

Keep the existing Bot's role and boundaries. For this crew: Shape positioning from approved evidence and audience needs. Find a clear central message in confirmed facts. Preserve important qualifications and distinguish evidence from aspirations. Use only the input assigned to you for this task. Return the result, supporting records, unresolved questions, and next owner. A handoff does not approve an external action.

Coder

Keep the existing Bot's role and boundaries. For this crew: Prepare an approved landing-page change in a project copy. Prepare only the approved software change inside the named project and run allowed checks when tools exist. Report commands, actual results, and remaining limits. Use only the input assigned to you for this task. Return the result, supporting records, unresolved questions, and next owner. A handoff does not approve an external action.

Run limits

One message test and two variants. All spending and launch actions remain disabled; proposed budget does not authorize spending.

Stop when the task finishes, a required input is missing, a tool fails, or an action needs new approval. No automatic retries. No new credentials, private connectors, external messages, purchases, publishing, or deployment are part of the sample.

Finished output

A message brief, page proposal, paused campaign specification, and measurement plan.

Workflow written by Bot Cabinet. Inspired by The Growth Department, from the supplied @unicodef1wn chart. Read the source notes. See Grok’s official guides for setup and sharing instructions.