Skip to main content

​
Runner Setup

Use this guide after all other onboarding steps are complete. Runners are the automation layer — they run on schedules or in response to events and produce work items, content drafts, insights, and distribution actions without you having to prompt for each one manually.

​
What You’ll Need

Enabling runners before brand voice and ICPs are configured will produce generic output. Runners use your brand context as their primary instruction set — without it, they have nothing to anchor to.

​
The Prompt

Paste this into Claude to start:
For multi-product sites, be specific about scope:

​
What Claude Will Do

Claude will run two tool calls to assess your situation:
  1. list_skills — fetches all available runner skills with their categories, trigger types, and data requirements
  2. get_onboarding_status — checks which onboarding steps are complete and which data sources are connected, so it can assess which runners have enough data to be useful right now
From there, Claude will recommend a prioritized list of runners to enable, explain what each one does, and ask for your input on execution tier and schedule before applying any configuration.

​
Runner Categories

Analysts are the best place to start. They observe and summarize — no content is generated, no changes are made. Enable these first so you can see what the system notices before you authorize it to act. Producers create drafts and work items. Enable these after analysts are running and you trust the signal they’re surfacing. Librarians tag and classify existing content. Safe to enable early — they write metadata, not content. Reviewers evaluate the quality of other runners’ output. Enable output-qa-checker once you have producers running.
A good first session: enable 2–3 analysts, one librarian, and come back in a week to review what they found. That gives you a baseline before turning on producers.

​
Execution Tiers

Every runner runs at one of three execution tiers. Claude will ask you which tier you want for each runner: Start most runners on Staging until you’ve seen a few output cycles and trust the quality. Flip to Auto after that.

​
Multi-Product Configuration

On multi-product sites, runners can be scoped to a product line. A scoped runner only loads context — brand tone, ICPs, keyword clusters, ad data — for that product line. This keeps outputs focused and prevents cross-product contamination in content and messaging.
Claude will walk through each product line, confirm the configuration, and create the runners one at a time. Each scoped runner appears in the Automations list tagged with the product line name.
Unscoped runners (no product line assigned) see the full website context. Use unscoped runners for cross-product work like overall performance digests or site-wide keyword gap analysis.

​
Common Edge Cases

Too many runners competing for token budget. If you enable a large number of runners at once, they’ll queue during cron windows and some may be delayed. Prioritize by enabling 5–7 runners to start and expand from there. Runners with insufficient data. Claude will flag which runners don’t have enough data yet (e.g., an ad-refresher when no ads are connected, or a cta-revision runner when no CTA performance data exists). Don’t enable these until the underlying data is in place — the runner will skip or produce low-quality output. A runner fires immediately and produces poor output. Check the execution tier — if it’s set to Auto and the brand context was incomplete at setup time, the first few runs may be off. Switch the runner to Staging temporarily, update your brand context, and let it re-run. Multi-product site with shared runners. Some runners, like performance-digest, make more sense as site-wide runners rather than per-product. Claude will recommend which runners to scope and which to leave unscoped based on your configuration.