Product Manager Skill

Turn analytics and customer signals into prioritized product decisions, PRD drafts, experiment plans, and implementation-ready GitHub backlog issues or draft...

Security Scan

The skill's code and runtime instructions mostly match a product-manager/autopilot workflow, but registry metadata omits required secrets and the runtime includes scripts that write to the workspace and start network services — these mismatches and side-effects deserve review before use.

Purpose & Capability

The skill claims to convert analytics+code context into PRDs, issues, and draft PRs and to optionally create GitHub issues/PRs — the included scripts and examples (analytics, sentry, revenuecat) align with that purpose. However the registry metadata declares no required environment variables while SKILL.md and references list multiple required tokens (GITHUB_TOKEN, ANALYTICSCLI_READONLY_TOKEN, REVENUECAT_API_KEY, SENTRY_AUTH_TOKEN, optional FEEDBACK_API_TOKEN). That metadata omission is an incoherence to surface.

Instruction Scope

Runtime instructions and scripts perform repository scanning (repo-root), read analytics summary files, call CLI tools (analyticscli), and may create GitHub issues/PRs using GITHUB_TOKEN. The startup protocol and bootstrap script copy skill runtime into the workspace root and the feedback API can start an HTTP server. These are coherent with the stated purpose but broaden the agent's access (file-system writes, repo read access, network listeners). Also the SKILL.md mandates 'portable mode' not to block on missing helper files, giving the agent discretion to run automatic checks and network calls without further prompts.

Install Mechanism

No formal install spec is declared (instruction-only), but the package bundles multiple runtime scripts that are intended to be copied into the workspace via scripts/bootstrap-openclaw-workspace.sh. That copy action writes files into the user's workspace (scripts/ and data/). No remote, obscure downloads were present in the reviewed files, but the absence of an install spec + bundled executable scripts means code will be executed from local files — review them before running.

Credentials

The credentials requested in SKILL.md (GITHUB_TOKEN, ANALYTICSCLI_READONLY_TOKEN, REVENUECAT_API_KEY, SENTRY_AUTH_TOKEN, optional FEEDBACK_API_TOKEN) match the skill's integration points and are proportionate to creating issues and pulling analytics/error/monetization summaries. The concern is that the registry metadata incorrectly lists required env vars as 'none', and the skill's instructions allow the agent to perform actions with these tokens (create issues/PRs, read code). Ensure tokens are least-privilege and confirm where tokens will be stored/injected. Also note FEEDBACK_API_TOKEN is optional: if unset, the bundled feedback API will accept unauthenticated requests.

Persistence & Privilege

The skill does not set always:true and does not request system-wide privileges. However it includes a bootstrap script that copies runtime files into the workspace root and guidance to place secrets in /etc/openclaw-growth/env for scheduled runs — both are persistent changes. The feedback API opens a local HTTP port by default (4310). These behaviors are reasonable for an autopilot runner but are higher-impact than a read-only instruction-only skill and should be approved explicitly.

What to consider before installing

What to check before installing/using this skill: - Metadata mismatch: the registry lists no required env vars but SKILL.md and references require multiple tokens (GITHUB_TOKEN, ANALYTICSCLI_READONLY_TOKEN, REVENUECAT_API_KEY, SENTRY_AUTH_TOKEN). Treat that as an administrative omission; verify you must provide those tokens before running autopilot. - Token scope: if you enable GitHub creation modes, use a fine-grained PAT limited to the minimal repo scopes indicated (Issues: Read/Write; Contents: Read for issue mode; Contents Write only if creating PRs). Never supply account-wide tokens. - Inspect bundled scripts locally before running (openclaw-growth-*.mjs, feedback API, charts script). The bootstrap script will copy runtime files into your workspace (scripts/ and data/); this writes files — review them and prefer running in an isolated workspace or sandboxed environment first. - Feedback API exposure: scripts/openclaw-feedback-api.mjs will listen on a TCP port (default 4310). If you run it without FEEDBACK_API_TOKEN, it accepts anonymous POSTs. Run behind a firewall or enable the token if you expose the endpoint. - Secrets handling: follow the skill's own guidance — keep tokens out of repo files and CLI args; inject via OpenClaw secret storage or a protected environment file with strict permissions. - Least-privilege testing: before enabling autopilot modes that create issues/PRs, run the analyzer in file-only mode (using the provided example JSONs) to see outputs without network side effects. Verify generated content and repository file mappings to ensure it won't create mistaken changes. If you want higher assurance, ask the publisher for (1) explicit install instructions and a manifest of what files will be copied, (2) a list of outbound network targets used at runtime (e.g., analyticscli endpoints, GitHub API), and (3) a short security note confirming no secrets are exfiltrated or logged by default. Review any omitted scripts not included in the truncated listing before running scheduled/autopilot modes.

Use This Skill When

• you need to prioritize product opportunities from analytics signals
• you want concise PM outputs that engineering can execute directly
• you need a PRD or experiment brief with measurable success criteria
• you need a decision memo with tradeoffs and recommendation
• you want analytics + code context converted into prioritized GitHub issues or draft proposal PRs

Core Rules

• Always state assumptions explicitly before recommendations.
• Prioritize with an impact x confidence x effort rationale.
• Tie every recommendation to at least one measurable KPI.
• Keep scope bounded: max 3 major opportunities or max 3-5 generated issues per pass.
• Avoid generic advice without concrete scope and acceptance criteria.
• Mark low-confidence conclusions clearly if data quality is weak.
• For implementation outputs, include explicit file/module hypotheses.
• For autopilot mode, run a preflight checklist and list missing dependencies/secrets explicitly.
• If the user says "start/run the skill", do not ask generic discovery questions first. Run the startup protocol below.
• In start/run, never require workspace-local helper files under scripts/ or data/ as a hard prerequisite.

Required Inputs (Manual PM Mode Only)

• problem statement or objective
• at least one data source summary (analytics, feedback, revenue, errors)

Optional Inputs

• constraints (timeline, team capacity, dependencies)
• strategic context (OKRs, business goals, target segment)
• existing roadmap or in-flight initiatives
• repository root (for file/module mapping when generating issue drafts)
• GitHub repo + token (required baseline; use least-privilege fine-grained token)

Autopilot Preconditions (Mandatory)

Before running issue generation/autopilot mode, verify and report:

• Data sources:
  • analytics_summary.json (required)
  • revenuecat_summary.json (recommended for monetization decisions)
  • sentry_summary.json (recommended for stability prioritization)
  • feedback_summary.json (optional, but high value)
• Code-readiness:
  • --repo-root points to the target repository checkout
  • agent user has read access to the codebase
  • if needed, restrict scan with --code-roots apps,packages
• Runtime dependencies:
  • node for analyzer/runner
  • analyticscli CLI for analytics data extraction
  • analyticscli-cli skill must be installed/fetched (for canonical analytics source refresh workflow)
  • optional charting: python3 + matplotlib
• Secrets:
  • GITHUB_TOKEN (required baseline; fine-grained PAT with repository Issues: Read/Write, Contents: Read)
  • ANALYTICSCLI_READONLY_TOKEN (recommended; required for non-keychain CLI auth)
  • REVENUECAT_API_KEY
  • SENTRY_AUTH_TOKEN
• optional FEEDBACK_API_TOKEN
• optional connector-specific env vars used by sources.extra[]

If anything is missing, stop autopilot and return a concrete "missing items" list with where to obtain each value.

OpenClaw Startup Protocol (Mandatory)

When the user asks to start/run/kick off the skill, execute this exact sequence. This protocol must work even when the user prompt is vague and even when repo-specific helper scripts are missing.

0. ClawHub layout (only when scripts/openclaw-growth-start.mjs is missing at workspace root):

   • ClawHub installs skills under skills/<slug>/. If skills/product-manager-skill/scripts/openclaw-growth-start.mjs exists but scripts/openclaw-growth-start.mjs does not, run once from workspace root:
     • bash skills/product-manager-skill/scripts/bootstrap-openclaw-workspace.sh
   • Then the standard paths scripts/... and data/openclaw-growth-engineer/... exist at the workspace root for tools that expect them.

1. Start in portable mode first (always):

   • Ensure dependencies and auth without asking for manual analytics summaries:
     • check analyticscli binary (command -v analyticscli)
     • check analytics auth (analyticscli projects list with token or existing login)
     • check GITHUB_TOKEN presence (fine-grained token: repository Issues: Read/Write, Contents: Read)
     • detect GitHub repo from git remote origin if available; if not available, ask once for owner/repo
   • If any check fails, return only a concrete blocker checklist with exact fix commands.

2. Portable mode execution:

   • run first pass directly via analyticscli commands (bounded, deterministic)
   • generate 3-5 prioritized issue drafts and create GitHub issues or draft pull requests when allowed

3. After run:

   • report whether drafts were generated and whether GitHub issues or PRs were created
   • include command to repeat the same run path

Never block on "please provide goal + datasource" if config and sources already exist. Never fail only because local helper files are missing in the workspace. If config or runtime prerequisites are missing, return only a concrete missing-items checklist (config path, API keys, repo access, missing binaries/skills). Do not ask for manual data summaries in start/run mode.

Standard Output Format

Return results in this order:

1. Executive Summary (3-5 lines)
2. Top Opportunities (max 3, ranked)
3. Recommendation (single preferred path + why)
4. Execution Scope (in-scope, out-of-scope, dependencies)
5. KPIs And Targets (baseline, target, measurement window)
6. Acceptance Criteria (implementation-ready)
7. Risks And Mitigations
8. Next 7-Day Plan

If the user explicitly asks for issue generation/autopilot mode, return this format instead:

1. Executive Summary (3-5 lines)
2. Top Issue Drafts (3-5, ranked)
3. Recommendation (single preferred execution path)
4. Execution Order (week 1 sequencing)
5. Risks And Guardrails

Each issue draft must include:

• Problem
• Evidence
• Affected Files / Modules
• Proposed Implementation
• Expected Impact
• Confidence
• optional PR prompt

Output Quality Bar

• recommendations are testable within one iteration cycle
• each KPI has a concrete time window
• acceptance criteria can be copied into engineering tickets
• risk section includes at least one rollback or guardrail condition
• in issue mode, each issue has clear file/module hypotheses and measurable impact

Anti-Patterns

• broad strategy talk without operational next steps
• recommendations that ignore technical or business constraints
• “improve UX” phrasing without affected flow/module hypothesis

Portable Start Commands

Dependency/auth checks:

command -v analyticscli
analyticscli projects list

Baseline analytics pull (bounded):

analyticscli schema events --limit 200 --last 30d --format json

Optional additional signals:

analyticscli timeseries --metric unique_users --interval 1d --last 30d --format json

References

• README
• Required Secrets
• Setup And Scheduling
• Input Schema
• Issue Template