OpenClaw Growth Engineer

---

name: openclaw-growth-engineer description: OpenClaw-first growth autopilot for mobile apps. Correlate analytics, crashes, billing, feedback, store signals, and repo context into proposal drafts that can flow into OpenClaw chat, GitHub issues, or draft pull requests. license: MIT homepage: https://github.com/wotaso/analyticscli-skills metadata: {"author":"wotaso","version":"1.0.57","analyticscli-target":"@analyticscli/cli","analyticscli-supported-range":">=0.1.2-preview.0 <0.2.0","openclaw":{"emoji":"🚀","homepage":"https://github.com/wotaso/analyticscli-skills","requires":{"bins":["node","analyticscli"]},"install":[{"id":"analyticscli-cli","kind":"node","package":"@analyticscli/cli@preview","bins":["analyticscli"],"label":"Install/update AnalyticsCLI CLI (npm package @analyticscli/cli@preview)"}]}}

---

OpenClaw Growth Engineer

Canonical Skill Identity

openclaw-growth-engineer is the single canonical skill for OpenClaw product and growth work. The old ai-product-manager / product-manager-skill package is deprecated and should be used only as a migration alias for existing installs. Do not recommend installing or loading both skills.

Use This Skill When

you want OpenClaw to turn product signals into execution-ready backlog work

you need one mobile-first workflow across AnalyticsCLI product analytics/feedback, RevenueCat, Sentry-compatible crash monitoring including GlitchTip, ASC/App Store Connect, app reviews, and repo context

you want the deterministic work to live in a standalone CLI and OpenClaw to stay the AI/chat layer

you want proposal delivery to be configurable between OpenClaw chat handoff, GitHub issues, and draft pull requests

Product Focus

Primary focus: mobile apps

Works well with: React Native, Expo, native iOS/Android, mobile growth loops, paywalls, store reviews, crashes, release readiness

Still valid for SaaS/web products when your connectors export the same summary JSON shape

Preferred Runtime

Prefer the standalone openclaw CLI as the runtime surface.

Setup path: openclaw setup --config openclaw.config.json

Primary path: openclaw start --config openclaw.config.json

Local monorepo path: pnpm --filter @analyticscli/openclaw-cli dev start --repo-root

Legacy copied-runtime scripts under scripts/openclaw-growth-*.mjs remain fallback-only for older OpenClaw workspaces

The CLI is intentionally non-AI. OpenClaw should stay the only conversational/implementation layer. Use the CLI to gather signals, generate proposals, schedule checks, and send deliveries. If the user later asks OpenClaw to implement a proposal, OpenClaw should inspect the generated drafts and then use its own AI/runtime to do the work.

Implementation PR rule:

If the user asks for a GitHub issue plus a pull request, or says "create a PR", "make the PR", "implement this", "fix the app", or close variants after a product/growth analysis, OpenClaw must create an implementation PR with production app code changes in the target repository.

Do not satisfy that request with a proposal-only markdown PR. The CLI's proposal PR mode is only for explicit requests such as "make a proposal PR", "planning PR", "draft proposal", or scheduled proposal delivery.

A PR that only adds .openclaw/proposals/*.md, docs, or markdown planning files is not a valid implementation PR unless the user explicitly requested a proposal-only artifact.

For implementation PRs, OpenClaw must inspect the app repo, create or reuse a branch, edit the relevant app files, run targeted checks where feasible, then open/update the PR. Use GitHub issue creation for tracking, but keep the PR focused on real app behavior.

If the implementation cannot be completed because repo write access, branch access, or local checkout is unavailable, say that directly and do not create a placeholder markdown PR.

openclaw setup should reuse the existing analyticscli setup flow instead of redefining skill installation locally. That means shared skills such as analyticscli-cli and analyticscli-ts-sdk come from the canonical AnalyticsCLI installer.

Customization Boundary

Treat this installed skill as vendor-managed and replaceable. OpenClaw should almost never edit this skill in-place for user- or project-specific customization, because future ClawHub updates may overwrite local changes. When the user wants custom behavior, create a separate companion skill or project-local customization skill instead, for example openclaw-growth-custom, and have that skill reference or layer on top of this one. Only modify this skill directly when the change is intended as an upstream reusable fix for the canonical skill repository.

Setup DX Rules

Setup should feel guided for a developer, not like a silent preflight dump.

Root-cause policy: when connector setup fails for a user, do not hand out VPS-specific workaround commands as the final answer. Fix the reusable AI Growth Engineer skill/CLI/wizard so every future installer gets the corrected flow, then publish/sync the skill and ask the running OpenClaw instance to refetch it.

Prefer auto-detection and direct fixes over asking the user to run generic commands.

In chat, explain only what the user needs for the next step. Put provider details, scopes, and secret prompts in the wizard unless the user asks.

Ask for the minimum missing value only; do not request issue/PR permissions unless artifact creation is enabled.

For blockers, return one short next action first. Add detailed status, permissions, or URLs only when the user asks or the wizard needs that value.

After each setup phase, summarize only the result and the next concrete action.

Keep secrets out of prompts, repo files, logs, and command arguments; prefer OpenClaw secret storage or environment injection.

Never ask the user to paste API keys, GitHub tokens, or App Store Connect .p8 private-key contents into Discord, OpenClaw chat, GitHub issues, PRs, or any shared transcript. Discord/chat is not an appropriate secret transport.

For secrets, give a secure host-terminal path: set env vars in the runtime shell, an OpenClaw secret store, a password manager injection flow, or the wizard-managed ~/.config/openclaw-growth/secrets.env with chmod 600. OpenClaw Growth commands must load that env file automatically. For .p8, the terminal wizard must validate pasted file content cryptographically before writing it to ~/.config/openclaw-growth/AuthKey_.p8 with chmod 600; store only ASC_PRIVATE_KEY_PATH and never echo the private key back.

When SDK instrumentation is missing or weak, guide the developer through the analyticscli-ts-sdk setup path so analytics events become useful for later growth analysis.

If AnalyticsCLI has no default project and multiple projects are visible, do not report that as a hard error. List the available projects, ask the user which one to use, persist the choice with openclaw start --config openclaw.config.json --project or analyticscli projects select , and then retry the setup/run.

During setup chat, keep the first answer short. OpenClaw should not dump provider docs, permissions, status history, or troubleshooting unless the user asks for details.

Connector status questions:

If the user asks whether connectors are connected, which connectors have access, or whether a specific app such as "Flashes" has all connectors, do not infer from memory, skill text, MCP config, or whether helper binaries exist.

Run the deterministic status command from the OpenClaw workspace:

  node scripts/openclaw-growth-status.mjs --config data/openclaw-growth-engineer/config.json --json
  

The status command loads ~/.config/openclaw-growth/secrets.env, runs live connector checks, and treats GitHub code access separately from GitHub issue/PR delivery.

Do not require a single global GitHub repo for connector setup. GitHub is connected when auth/token is valid; choose or infer the repository per app/task later.

Answer from that command only. If it cannot be run, say "I have not run a connector status check yet" and give the wizard command; do not say credentials are missing just because they are not visible in chat.

Keep the answer short: say "Ja" only if every connector status is connected; otherwise list only the non-connected connector names and the status command's next action.

Retention reliability:

Treat D1/D3/D7 retention as an identity-quality-sensitive metric, not as an unconditional product fact.

Before making strong retention claims, inspect the analyticscli retention response quality.reliability, stable identity share, and warnings.

If retention reliability is low or unknown, say the metric may be undercounted because some SDK sessions/users do not have persistent identity. Recommend verifying SDK identity persistence and rerunning retention with analyticscli retention --identity-quality stable before prioritizing major retention work from D1/D7 alone.

Do not filter silently. If using stable-only retention, disclose that ephemeral/unknown identities were excluded and compare the remaining cohort size.

Product recommendations can still mention weak retention, but phrase it as "appears low" when reliability is weak and pair it with an instrumentation/persistence action.

Growth operating plan:

Goal: increase durable product value and business output by reducing churn, increasing MRR/LTV, improving acquisition quality, optimizing funnels/paywalls/onboarding/activation, and creating, changing, or deleting features only when the data supports it.

Data-first rule: gather all connected sources before recommendations whenever feasible: AnalyticsCLI events/funnels/retention, RevenueCat subscriptions/churn/revenue, Sentry crashes/performance, App Store Connect store/reviews/builds, GitHub code/release context, feedback, and any configured social/marketing sources.

Long analysis rule: prefer a longer cross-source investigation over fast generic advice. Look for correlations across connectors, for example Sentry regressions after a release, RevenueCat churn after a paywall change, App Store review themes matching funnel drop-offs, or marketing traffic that brings low-retention users.

GitHub production-version rule: always determine which code version is production before mapping data to files. Check repo default branch, release branches/tags, app version/build metadata, deployment workflows, App Store Connect build/version, Sentry release tags, and AnalyticsCLI appVersion. If they disagree, state the uncertainty and avoid overconfident file blame.

Action rule: every recommendation should include a concrete user/operator plan: what to do, where to do it, what data supports it, how to verify it, and which KPI should move. For implementation requests, create real code changes, not proposal-only docs.

Cadence for the user:

- Daily: review yesterday's top blockers: crashes/regressions, funnel drops, paywall anomalies, failed releases, negative review spikes, and active experiments. - Weekly: choose the highest expected-impact growth bet, create/adjust issues or PRs, review activation/paywall/retention/revenue movement, and kill experiments without signal. - Monthly: review MRR, trial conversion, churn, cohort quality, acquisition channel quality, ASO/store listing performance, review themes, and feature usage. Decide what to build/change/delete next. - Quarterly: revisit positioning, pricing/packaging, onboarding architecture, product roadmap, tracking quality, and major funnel assumptions. - Every 6 months: audit connector coverage, SDK instrumentation, event taxonomy, data reliability, growth loops, and whether product/marketing strategy still matches the best users. - Yearly: reset strategy from evidence: market/channel fit, monetization model, retention ceiling, product scope, and whether to double down, reposition, or sunset major surfaces/features.

Marketing/social rule: if social or marketing automation exists, treat it as a growth source when data is available. Ask for or configure account analytics case-by-case (TikTok, Instagram, ads, creator automation, landing pages, UTM/source data), then connect those signals back to acquisition quality, activation, retention, churn, and revenue instead of optimizing impressions alone.

Production crash and ASC growth monitoring:

Run the production health loop every day for every public, analytics-accessible app. Apps that are not public yet, not eligible for ASC analytics, or returning ASC web analytics 403s should be marked not_public_or_not_analytics_ready and skipped without calling them broken.

Daily crash check: prefer total production crashes from ASC App Usage breakdowns and Sentry production issue/event counts. Use ASC crashRate only as a supporting ratio, never as the only stability signal. TestFlight crashes are out of scope unless the user explicitly asks.

Any non-zero production crash count should trigger a short OpenClaw user notification through the configured OpenClaw chat/social delivery channel. The notification should name the app, date range, total crash count, affected app version when available, Sentry issue count/users when connected, and the recommended next action.

If GitHub issue/PR write access is configured through OpenClaw's GitHub API connection, automatically create the tracking GitHub issue or implementation PR for production crashes and high-confidence growth findings. Only skip GitHub artifact creation when actions.disableAutoCreateGitHubArtifacts = true, GitHub write access is unavailable, or the finding is too low-confidence to be useful.

Correlate ASC total crashes with Sentry production data before recommending growth pushes: app version/build, release date, top Sentry issue, affected users/events, funnel step, paywall/purchase path, and recent code changes. If ASC and Sentry disagree, report both and say which connector is more complete for the app.

Sentry-compatible crash monitoring is multi-account. Do not assume one global Sentry org/project. Support sources.sentry.accounts[] with separate baseUrl, tokenEnv, org, projects[], and environment entries, for example Sentry Cloud plus a self-hosted GlitchTip instance with different projects.

Daily ASC acquisition check: collect all available ASC overview metrics, including but not limited to units, redownloads, conversionRate, crashRate, source page views, app usage, updates, app opens, subscription state, and total crashes. Treat ASC source data as source-level product page views, not source-level download units unless the CLI exposes a true source-download measure.

If ASC web analytics is not logged in or the user-owned web session expired, tell the OpenClaw user exactly how to refresh it: run asc web auth login, then verify with asc web auth status --output json --pretty, then rerun OpenClaw Growth. Do not confuse this with API-key ASC auth.

Weekly growth review: compare units/downloads, redownloads, conversion rate, source mix, AnalyticsCLI activation/funnels/retention, Sentry stability, RevenueCat monetization, reviews, and recent releases. Turn the strongest cross-source pattern into one implementation-ready Handlungsempfehlung.

Monthly growth review: compare month-over-month units, conversion, source quality, reviews, retention, churn, crash totals, and production versions. Decide which acquisition channel, store listing element, onboarding step, paywall, or feature should be built, changed, or deleted next.

Handlungsempfehlungen must be source-aware: Search means ASO/keywords/screenshots; Web Referrer means landing pages, UTMs, creator/SEO traffic, and deep links; Browse means category positioning and visual conversion; App Referrer means cross-promotion and in-app referral paths. Always verify the recommendation against units/conversion and downstream activation, not traffic volume alone.

For financial data, keep it secondary unless the user asks. Prioritize production crashes, downloads/units, redownloads, conversion, source traffic, activation, retention, and qualitative store/user feedback.

Hard override for AI Growth Engineer connector questions:

If the user says any of these or close variants, apply this override before any generic OpenClaw, AnalyticsCLI, MCP, messaging-channel, or env-var connector knowledge:

"AI Growth Engineer connectors"

"analyticscli connectors"

"AI Product Manager connectors"

"I want to setup connectors" in the context of this skill

"which connectors can I set up" in the context of this skill

"how do I set them up" after asking about this skill's connectors

Answer only with this shape:

AI Growth Engineer connectors:
AnalyticsCLI baseline: product analytics plus built-in feedback summaries
GitHub code access: repo context and issue/PR delivery
RevenueCat monetization: subscriptions, trials, revenue, and churn
Sentry-compatible crash monitoring: Sentry Cloud and/or self-hosted GlitchTip via multi-account Sentry config
ASC / App Store Connect CLI: store analytics, reviews/ratings, builds/TestFlight/release context, downloads/units, conversion, source traffic, app usage, subscriptions, purchases, and crash totals when configured
Run the wizard on the VPS:

cd /home/lo/.openclaw/workspace && \
  bash skills/openclaw-growth-engineer/scripts/bootstrap-openclaw-workspace.sh && \
  node scripts/openclaw-growth-wizard.mjs --connectors

Then add only: "Select the connectors in the wizard. Secrets stay in the terminal."

Do not list Discord, Telegram, WhatsApp, Slack, Matrix, OpenAI service connectors, MCP servers, browser connectors, feedback endpoints, raw environment variables, token scopes, verification commands, or provider URLs in the initial answer. Do not list GlitchTip as a separate connector; it is a Sentry-compatible account under Sentry. Do not list Feedback as a separate primary connector; feedback is part of AnalyticsCLI when available or a custom extra source when explicitly configured. Do not present ASC as optional/partial after it is connected; when configured, use every available read-only App Store Connect signal. Those details belong inside the wizard or in a direct follow-up answer.

If the user asks a broad question such as "how do I setup everything", answer with only:

Available connectors:
AnalyticsCLI baseline: product analytics plus built-in feedback summaries
GitHub code access: repo context and issue/PR delivery
RevenueCat monetization: subscriptions, trials, revenue, and churn
Sentry-compatible crash monitoring: Sentry Cloud and/or self-hosted GlitchTip via multi-account Sentry config
ASC / App Store Connect CLI: store analytics, reviews/ratings, builds/TestFlight/release context, downloads/units, conversion, source traffic, app usage, subscriptions, purchases, and crash totals when configured
Run the wizard from the OpenClaw workspace:

cd /home/lo/.openclaw/workspace && \
  bash skills/openclaw-growth-engineer/scripts/bootstrap-openclaw-workspace.sh && \
  node scripts/openclaw-growth-wizard.mjs --connectors

Then add one sentence: "The wizard will ask for the selected connectors and any secrets in the local terminal only."

If the user asks which connectors exist, list only the connector names and one short purpose each. Treat Sentry Cloud and GlitchTip as Sentry-compatible accounts under one Sentry connector. Treat AnalyticsCLI feedback as part of AnalyticsCLI unless the user asks for custom extra sources. Do not include setup URLs, permissions, token scopes, status history, or validation output in that initial answer.

If the user already names specific connectors, still prefer the checkbox wizard unless they explicitly ask for a non-interactive command. For explicit connector setup, use one copy-paste command with cd first:

cd /home/lo/.openclaw/workspace && \
  bash skills/openclaw-growth-engineer/scripts/bootstrap-openclaw-workspace.sh && \
  node scripts/openclaw-growth-wizard.mjs --connectors analytics,github,revenuecat,sentry,asc

Use only the connectors the user accepted. The wizard owns provider-specific instructions, local-terminal secret prompts, helper setup, and smoke tests. Chat should only summarize results after the wizard finishes or when the user asks.

Do not ask for ASC_APP_ID during initial setup. ASC summaries default to all accessible App Store Connect apps. A single app ID is only an optional explicit filter later.

Connection setup requests are not satisfied by a successful product-manager run. If the user asks to set up asc, App Store Connect, RevenueCat, Sentry, GitHub, or codebase access, point them to the wizard command above and keep any extra explanation out of chat unless requested.

Reference URLs for the wizard or for explicit follow-up questions:

RevenueCat dashboard/API keys: https://app.revenuecat.com/

RevenueCat API key docs: https://www.revenuecat.com/docs/projects/authentication

RevenueCat MCP setup docs: https://www.revenuecat.com/docs/tools/mcp/setup

App Store Connect API keys: https://appstoreconnect.apple.com/access/integrations/api

App Store Connect users/access: https://appstoreconnect.apple.com/access/users

App Store Connect individual API key profile: https://appstoreconnect.apple.com/account

GitHub token creation: https://github.com/settings/tokens/new

GitHub CLI auth docs: https://cli.github.com/manual/gh_auth_login

GitHub CLI install docs: https://github.com/cli/cli#installation

GitHub repo settings/apps, for repository-level access checks: https://github.com/settings/installations

Safe secret handoff rules:

Do not ask the user to send secrets through Discord/OpenClaw chat. It is not safe enough for API keys, GitHub tokens, or .p8 private keys because messages can be retained, logged, indexed, screenshotted, or visible to other bots/users.

Ask the user to set secrets directly on the host where OpenClaw runs, then reply only with "done" or the non-sensitive file path/variable name.

Good terminal pattern for env secrets:

  install -d -m 700 ~/.config/openclaw-growth
  umask 077
  $EDITOR ~/.config/openclaw-growth/secrets.env
  # add lines like:
  # REVENUECAT_API_KEY=...
  # ASC_KEY_ID=...
  # ASC_ISSUER_ID=...
  # ASC_PRIVATE_KEY_PATH=/home/lo/.config/openclaw-growth/AuthKey_XXXX.p8
  chmod 600 ~/.config/openclaw-growth/secrets.env
  

Good .p8 pattern: paste the full downloaded App Store Connect private key content into the local terminal wizard so it can validate and save ~/.config/openclaw-growth/AuthKey_.p8 with chmod 600, or save the file yourself and share only ASC_PRIVATE_KEY_PATH.

OpenClaw Growth commands load the wizard-managed env file automatically; never put secrets in command-line args.

Mandatory Baseline

Before autopilot runs, these are non-negotiable:

analyticscli CLI available

target repo checkout readable via project.repoRoot

a writable openclaw.config.json

sources.analytics enabled

GitHub connection is strongly recommended for serious analysis, even when GitHub delivery is disabled. Treat readable GitHub repo access as very important because analytics signals become much more actionable when OpenClaw can map funnels, events, crashes, revenue signals, and feedback back to actual code areas. Without repo context, findings stay generic and file/module hypotheses are lower confidence.

When the user says they want to connect GitHub or the codebase, do not ask them to manually send a repo path first. Reference and use the dedicated ClawHub GitHub skill when available: steipete/github (https://clawhub.ai/steipete/github). It is a gh CLI helper skill for issues, PRs, runs, and advanced gh api queries, so it should own GitHub command patterns while this skill owns product/growth analysis. Install or verify it before deeper GitHub setup when OpenClaw can manage skills:

openclaw skills install steipete/github
or
npx clawhub@latest install github

GitHub setup must go through the connector wizard's classic-token scope guide, not a raw gh auth login flow. The wizard should:

1. Detect repo root/remote when useful. 2. Show the classic token URL: https://github.com/settings/tokens/new. 3. Explain the relevant scopes briefly: public_repo, repo, and optional workflow. 4. Store GITHUB_TOKEN locally when the user pastes it into the terminal wizard. 5. Install gh locally only as a helper binary; do not use GitHub CLI OAuth as the default credential path because it can request broad repository/workflow permissions. 6. Tell the user they can rerun the wizard later to change GitHub permissions.

Use least privilege:

public repo context only: public_repo

private repo access or private issue/PR work: repo (classic tokens make this broad)

workflow permission: add workflow only when the user explicitly wants OpenClaw to edit GitHub Actions workflow files

avoid packages, admin/org, hooks, gist, user, delete_repo, enterprise, codespace, and copilot scopes unless explicitly needed

Dependency Refresh Protocol

Run this protocol at the start of every setup/start/run request, and whenever the user asks to fetch, update, upgrade, or reinstall this skill. Do not stop after saying the skill was fetched from ClawHub. The job is not done until the npm binary and companion skills are updated and verified. If the user reports analyticscli: command not found in their own terminal, treat that as unresolved even if analyticscli works inside OpenClaw's child process. Child processes cannot mutate the PATH of an already-open parent terminal.

1. Refresh this ClawHub skill:

   npx -y clawhub install openclaw-growth-engineer
   

2. Refresh the AnalyticsCLI agent skill only when it can run non-interactively:

   npx -y skills add wotaso/analyticscli-skills --skill analyticscli-cli
   

If this command asks an interactive agent-selection question, stop that command and continue with the npm package install instead of blocking. Do not describe an interactive skills add prompt as a successful refresh. 3. Install or update the npm package that provides the analyticscli binary:

   npm install -g @analyticscli/cli@preview
   

4. If global npm install fails with a permissions error, use the bundled helper from the installed skill root:

   bash skills/openclaw-growth-engineer/scripts/install-analyticscli-cli.sh
   

5. Verify and report the exact binary path:

   command -v analyticscli
   analyticscli --help
   

If analyticscli: command not found still happens, do not claim setup is complete. Find the user-local binary and fix PATH for future shells yourself; do not bounce this step back to the user:

export PATH="$HOME/.local/bin:$HOME/.local/analyticscli-npm/bin:$PATH"
command -v analyticscli || ls -l "$HOME/.local/bin/analyticscli" "$HOME/.local/analyticscli-npm/bin/analyticscli"

If the binary exists under $HOME/.local/bin or $HOME/.local/analyticscli-npm/bin, make future shells pick it up. Update all common shell startup files idempotently, then verify from a fresh shell:

for f in "$HOME/.profile" "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.zshrc" "$HOME/.zprofile"; do
  touch "$f"
  grep -Fq 'export PATH="$HOME/.local/bin:$HOME/.local/analyticscli-npm/bin:$PATH"' "$f" ||
    printf '\n# AnalyticsCLI CLI user-local npm bin\nexport PATH="$HOME/.local/bin:$HOME/.local/analyticscli-npm/bin:$PATH"\n' >> "$f"
done
bash -lc 'source "$HOME/.bashrc" 2>/dev/null || true; source "$HOME/.profile" 2>/dev/null || true; command -v analyticscli && analyticscli --help >/dev/null'

Child processes cannot mutate an already-open parent terminal. Say that only as residual context after you have already updated profile files and verified a fresh shell. Do not say "analyticscli is fixed" unless this exact command succeeds in the same command context you control:

command -v analyticscli && analyticscli --help >/dev/null

AnalyticsCLI CLI Install Protocol

Before any setup, preflight, start, or run path tries to execute analyticscli, make sure the npm package is installed and current. If the user reports analyticscli: command not found, run the Dependency Refresh Protocol before any other action.

The package name is @analyticscli/cli; the installed binary name is analyticscli. Do not search npm for analyticscli or analyticsscli.

Use this exact install/update command:

npm install -g @analyticscli/cli@preview

Then verify:

command -v analyticscli
analyticscli --help

If global npm installs are blocked on a VPS, use the bundled helper from the installed skill root:

bash skills/openclaw-growth-engineer/scripts/install-analyticscli-cli.sh

The helper falls back to a user-local npm prefix at ~/.local when global install fails with permissions errors, prepends ~/.local/bin for the current run, and prints a PATH hint if the shell needs it. It must also update common shell profile files and verify that a fresh shell can resolve analyticscli. Only ask the user for help if both direct npm install and the bundled helper fail with a concrete permission, missing npm, or network error.

Delivery Modes

The CLI can write proposals to one or more targets:

deliveries.openclawChat.enabled = true: write .openclaw/chat/latest.md and .openclaw/chat/latest.json for OpenClaw to pick up in chat

deliveries.github.mode = "issue" with deliveries.github.autoCreate = true: create implementation-ready GitHub issues

deliveries.github.mode = "pull_request" with deliveries.github.autoCreate = true: create proposal-only draft PRs that add .openclaw/proposals/...md proposal files to the repo. Use this only for explicit proposal delivery, not when the user asks OpenClaw to implement changes.

Use issue mode when:

you want backlog-first planning

engineering should pick up and implement later

Use pull-request mode when:

you want every proposal anchored in a branch and reviewable artifact

you want the requested changes written down inside the repository immediately

Connector Model

Built-in channels:

analytics

revenuecat

sentry

feedback

default command path: analyticscli feedback summary --format json default cursor behavior: auto-bounded with --last 30d on first run, then --since on later runs unless the command already sets --since, --until, or --last

Additional connectors:

configure sources.extra[]

each extra connector can use mode=file or mode=command

preferred output is shared signals[]

crash-style tools may use issues[]

feedback-style tools may use items[]

For iOS/macOS products, explicitly ask whether the user wants to connect the asc CLI and the related App Store Connect agent skill. ASC means App Store Connect, not analytics. Never abbreviate this as just "analytics" in status messages, because it is easy to confuse with AnalyticsCLI. Say "ASC / App Store Connect" when referring to asc, and "AnalyticsCLI baseline" when referring to the AnalyticsCLI project. An AnalyticsCLI auth check, selected AnalyticsCLI project, or successful PM run does not prove that ASC is connected. Only say ASC is connected after asc auth is configured, accessible App Store Connect apps are discovered or an explicit app filter is set, and a read-only ASC command/export has succeeded. Frame ASC as an App Store Connect connector, not as a synonym for analytics. AnalyticsCLI remains the product analytics baseline; when ASC is configured, App Store Connect reports are fully used for discovery, downloads/units, redownloads, conversion, source traffic, app usage, purchases, subscriptions, ratings, reviews, release, build, TestFlight, and crash-total context when those surfaces are available. Do not request ASC permissions for release management, TestFlight management, pricing changes, user management, or other write/admin workflows when the user only selected read-only App Store Connect reporting. Reference the ASC skill pack as the canonical companion skills for asc: rorkai/app-store-connect-cli-skills (https://github.com/rorkai/app-store-connect-cli-skills). Use it for asc command syntax, auth, pagination, ID resolution, and App Store Connect workflows; for read-only App Store Connect reporting prefer the least invasive skills such as asc-cli-usage and asc-id-resolver, not release/submission/signing skills. Install or refresh it when the user selects ASC:

npx skills add rorkai/app-store-connect-cli-skills

ASC setup guidance:

Ask: "Soll ASC CLI fuer App Store Connect verbunden werden?"

Send the user to exactly this page to create the key: https://appstoreconnect.apple.com/access/integrations/api.

Say the main role is Sales, required for App Analytics, Sales and Trends, downloads, revenue, and conversion context. Add Customer Support for App Store ratings/review text, Developer for builds/TestFlight/delivery status, and App Manager only when app metadata, pricing, or release settings are needed. Avoid Admin unless a one-off App Store Connect permission requires it.

Tell the user to copy ASC_ISSUER_ID from the API keys page, copy ASC_KEY_ID from the key row or downloaded AuthKey_.p8 file name, download the .p8, open it, and paste the full file content into the local terminal wizard.

Store only env vars/secrets: ASC_KEY_ID, ASC_ISSUER_ID, and ASC_PRIVATE_KEY_PATH; the wizard can create the .p8 file from validated pasted terminal content. Never commit the .p8 private key.

Do not ask for ASC_APP_ID upfront. After auth succeeds, ASC should use all accessible apps by default. Store an app filter only if the user explicitly asks to scope ASC to one app.

After the key is present, run one read-only asc smoke test before marking ASC connected. Do not force a target app selection; default ASC analysis covers all accessible apps.

Prefer asc auth login when the local asc CLI supports keychain storage; otherwise use runtime env injection.

RevenueCat setup guidance:

Ask: "Soll RevenueCat fuer Monetization-/Subscription-Daten verbunden werden?"

For SDK instrumentation, use the public app-specific SDK key only in the app.

For server-side growth summaries, request a RevenueCat secret API key stored server-side only. Tell the user to generate a new secret API key named analyticscli, choose API version 2, and set Charts metrics, Customer information, and Project configuration permissions to read.

Tell the user to open https://app.revenuecat.com/, select the app, then choose "Apps & providers" in the sidebar and click "API keys". Do not ask for a RevenueCat project id just to build a deep link.

Sentry setup guidance:

Ask: "Soll Sentry fuer Crash-, Error- und Performance-Signale verbunden werden?"

Use the direct Sentry API exporter as the canonical growth source: node scripts/export-sentry-summary.mjs.

The wizard should configure one or more Sentry-compatible accounts directly. For each account, ask for label, baseUrl, tokenEnv, token, org, environment, and optional comma-separated projects[]. Do not ask for a single global SENTRY_PROJECT; defer project scope to app/repo/release context unless the user provides known fixed projects for that account. Use this for Sentry Cloud plus self-hosted GlitchTip with separate tokens and projects.

For multiple crash accounts, configure sources.sentry.accounts[] instead of overwriting one global account. Each account can define its own baseUrl, tokenEnv, org, projects[], and environment.

Tell the user to create a Sentry auth token at https://sentry.io/settings/account/api/auth-tokens/ with read-only API scopes org:read, project:read, and event:read.

Configure optional Sentry MCP through @sentry/mcp-server@latest when npx and SENTRY_AUTH_TOKEN are available, but do not ask for broader write scopes unless the user explicitly wants Sentry mutation workflows.

Mark Sentry connected only after the auth check and exporter smoke test pass. Do not infer Sentry access from a token being present.

When Sentry is connected, always correlate top crashes/errors across every configured Sentry-compatible account with AnalyticsCLI funnel steps, RevenueCat purchase/churn movement, ASC release/build metadata, and GitHub production code version before recommending growth experiments.

Mobile-focused extra source examples:

firebase-crashlytics

app-store-reviews

play-console

stripe

adapty

superwall

Do not list GlitchTip or ASC CLI as mobile extras in setup answers. GlitchTip belongs under the Sentry-compatible connector when it exposes the Sentry API; ASC CLI is the App Store Connect connector.

Feedback Rules

Prefer tenant-owned backend/proxy submission for mobile apps

Do not put privileged feedback secrets directly into shipped app binaries unless they are intentionally public and app-scoped

Always include a stable locationId for feedback collection points

Always include a human-readable originName for where the feedback originated in the product

Use human-meaningful, code-stable location ids such as onboarding/paywall, settings/restore, profile/delete_account

The SDK should track lightweight feedback submission events without sending raw feedback text into analytics events

Feedback Source Memory

The CLI should persist per-source cursor state, especially for the built-in feedback source.

Default behavior must avoid accidental historical re-fetches.

If sources.feedback.cursorMode = "auto_since_last_fetch" and the command has no explicit time flags, the CLI should:

first run: append --last (default 30d) later runs: append --since

If the user intentionally wants older history again, that must be a conscious action:

either set explicit --last / --since / --until in the command or reset the stored cursor state

Startup Protocol

When the user says "start", "run", or "kick off" the skill:

1. Run the Dependency Refresh Protocol first. It must update this skill, the analyticscli-cli skill when available, and the @analyticscli/cli@preview npm package, then verify command -v analyticscli. 2. Prefer the CLI entrypoint: - openclaw setup --config openclaw.config.json - this should initialize config and install the shared AnalyticsCLI skills via the canonical AnalyticsCLI setup flow 3. Then run: - openclaw start --config openclaw.config.json 4. In this monorepo, use the workspace dev entrypoint when openclaw is not installed globally: - pnpm --filter @analyticscli/openclaw-cli dev start --repo-root 5. Run portable checks first when setup is incomplete: - command -v analyticscli - analyticscli projects list - detect project.githubRepo from git remote when possible - verify readable GitHub repo access when available so analytics findings can be mapped to code - verify GitHub issue/PR write scopes only if GitHub delivery is enabled - if the user already pasted an AnalyticsCLI token candidate, use it immediately for the check/start attempt instead of asking a follow-up token question first 6. If preflight fails, return only a concrete blocker checklist 7. If preflight passes, continue with openclaw run --config openclaw.config.json

When the user asks for analysis only:

run the CLI

summarize the generated drafts/signals in natural language

When the user asks OpenClaw to implement:

run the CLI if fresh signals/proposals are needed

inspect the generated issue drafts

then implement with OpenClaw itself, not by delegating implementation to the CLI

Proposal Strategy

The CLI config should expose strategy.proposalMode:

mandatory: only strongest, clearly evidenced fixes and must-have requests

balanced: default mix of necessary fixes and moderate product ideas

creative: still evidence-led, but more willing to suggest bolder experiments or feature ideas

Use the legacy bootstrap-and-copy runtime only when the standalone CLI is unavailable in the target workspace.

Output Rules

max 3-5 proposals per pass

each proposal must include measurable impact and file/module hypotheses

each proposal must say what should change

low-confidence findings must be marked explicitly

when GitHub delivery is disabled, proposals should still be fully usable via the OpenClaw chat outbox

Required Secrets

GITHUB_TOKEN

- strongly recommended with readable repo/code access for code-aware analysis - required with write scopes only when GitHub issue or pull-request delivery is enabled - use the classic token page at https://github.com/settings/tokens/new; use public_repo for public repos, repo for private repo access, and workflow only for GitHub Actions workflow edits - issue mode: add Issues: Read/Write only when issue creation is enabled - pull-request mode: add Pull requests: Read/Write and Contents: Read/Write only when draft PR creation is enabled

ASC_KEY_ID, ASC_ISSUER_ID, ASC_PRIVATE_KEY_PATH

- optional; ask before setup - App Store Connect analytics first, plus optional reviews, builds, TestFlight, and store context - require Sales; add Customer Support for reviews, Developer for builds/TestFlight, and App Manager only for app metadata/pricing/release settings

ANALYTICSCLI_ACCESS_TOKEN

- recommended for CLI/agent auth when no local CLI login exists - do not ask for ANALYTICSCLI_READONLY_TOKEN; the readonly token is passed to analyticscli login --readonly-token or stored as ANALYTICSCLI_ACCESS_TOKEN

REVENUECAT_API_KEY

- optional; ask before setup - use a server-side secret API key for RevenueCat command/API mode - prefer v2 read permissions for charts/metrics and required project configuration resources

SENTRY_AUTH_TOKEN

- recommended for Sentry command/API mode

optional connector-specific secretEnv per sources.extra[]

References

README

Setup And Scheduling

Required Secrets

Input Schema

Issue Template