Ce Product Pulse
Run a structured first-run interview so Product Pulse writes SMART events and metrics into `.compound-engineering/config.local.yaml` without collecting credentials in chat.
Overview
ce-product-pulse is an agent skill most often used in Grow (also Validate scope, Operate iterate) that runs a first-run Product Pulse interview and writes SMART pulse settings into local Compound Engineering config.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-product-pulseWhat is this skill?
- Section-by-section interview merged into gitignored `config.local.yaml` as `pulse_*` keys
- SMART evaluation bar for every proposed event, metric, and signal
- One round of pushback per section with `needs-review` fallback instead of blocking the flow
- Honors strategy seeds from `STRATEGY.md` so product name and key metrics are not re-asked
- Captures tool choice and query shape only—no API keys, tokens, or database passwords
- One round of pushback per interview section maximum
- Five overall rules govern capture, naming, tools-not-credentials, strategy seeds, and SMART evaluation
Adoption & trust: 1.4k installs on skills.sh; 20.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want consistent product pulse telemetry but your events and metrics are vague categories nobody can query or trust.
Who is it for?
Teams adopting Compound Engineering who need one disciplined pass to define events and metrics before automated pulse workflows run.
Skip if: Builders who already maintain a complete, SMART-validated pulse config in `config.local.yaml` and only need execution without re-interviewing.
When should I use this skill?
At the start of Compound Engineering Phase 1 when Product Pulse config is empty or incomplete and SKILL.md loads this interviewer.
What do I get? / Deliverables
You get a merged `pulse_*` section in `.compound-engineering/config.local.yaml` with team-native naming and review flags so subsequent CE pulse runs read the same definitions.
- Updated `pulse_*` keys in `.compound-engineering/config.local.yaml`
- `needs-review` flags on sections that failed the quality bar after pushback
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Grow because the artifact is ongoing product telemetry and pulse configuration, not one-off code generation. Analytics is where named events, metric quality bars, and signal definitions belong before dashboards or agent runs consume them.
Where it fits
Turn validation hypotheses into named events and success metrics before you commit to a full build.
Standardize pulse queries and metric labels so growth reviews use the same definitions every week.
Re-run the interview sections when strategy shifts and mark stale definitions as `needs-review` instead of silently drifting.
How it compares
Use as a guided onboarding ritual for CE config, not as a generic analytics dashboard or MCP connector.
Common Questions / FAQ
Who is ce-product-pulse for?
Solo builders and indie teams using the Compound Engineering plugin who are setting up Product Pulse for the first time and need shared, readable metric definitions in local config.
When should I use ce-product-pulse?
At CE Phase 1 before pulse automation; during Validate when scoping measurable success criteria; and during Operate when revisiting metrics after strategy changes in STRATEGY.md.
Is ce-product-pulse safe to install?
The interview is designed to avoid collecting credentials in chat; review the Security Audits panel on this Prism page and keep secrets in your own environment variables or secret stores.
SKILL.md
READMESKILL.md - Ce Product Pulse
# Product Pulse First-Run Interview Loaded by `SKILL.md` at the start of Phase 1. Captures the configuration that will be merged into `.compound-engineering/config.local.yaml` (the unified CE local config, gitignored, machine-local) as `pulse_*` keys and re-read on every subsequent run. For each section: ask the opening question, evaluate the answer against the quality bar, push back when it falls into a named anti-pattern, and capture the final answer in the user's own language. ## Overall Rules 1. **Push back, but don't spiral.** One round of pushback per section max. If the second answer still isn't usable, capture what the user gave, flag it in the config as `needs-review`, and move on. 2. **Name events in the user's own words.** The config will be readable by the whole team - use the terms they actually use, not a generic template. 3. **Ask about tools, not credentials.** The interview captures *which* tool and *what shape of query*. It does not collect API keys, tokens, or database passwords. Those stay in the user's environment. 4. **Honor strategy seeds.** If `SKILL.md` Phase 1.0 surfaced a product name or a list of key metrics from `STRATEGY.md`, start with those as defaults and let the user edit. Do not re-ask questions that the strategy doc already answered unambiguously. 5. **Evaluate metrics against the SMART bar.** Every event, metric, and signal the user proposes should be: - **Specific** - a named event or a named metric, not a category. `message_sent` passes; "engagement" does not. - **Measurable** - you can point to the tool and query that returns a number. "Users like it" does not pass; "NPS score from Delighted" does. - **Actionable** - if the number moves, the team knows what to do next. "Daily active users" alone usually fails this - pair it with a conversion or retention signal that surfaces a decision. - **Relevant** - ties to the product's target problem and persona (from the strategy doc if seeded). Generic funnel metrics that don't connect to the strategy are suspect. - **Timely** - reads in the pulse window (24h, 7d, etc.) and reflects the current state. Lagging metrics that only move quarterly don't belong in a daily pulse. When a user proposes a metric that fails one of these, push back by naming the specific dimension: "That sounds more like a vanity metric than an actionable one - if it moves, what do we do? Is there a tighter signal that would drive a decision?" Do not use the word "SMART" with the user; use the plain-English question. --- ## 1. Product Name **Opening question:** - If seeded from strategy: "Product name from strategy is `{{name}}`. Keep it or edit?" - Otherwise: "What's the product called?" No pushback needed. Capture verbatim. --- ## 2. Primary Engagement Event **Opening question:** "When someone is using your product, what single event fires? The one that tells you a user is active right now." This is the heartbeat of the pulse. Pick one event - the one that represents a user actually using the product, not opening a page. **Apply the SMART bar** (see Overall Rules). The event must be specific (a named event), measurable (the analytics tool returns a count), actionable (if it moves, the team notices), relevant (ties to the product's job), and timely (reads cleanly in short windows). **Engagement vs value test.** After the user names an event, ask yourself: does this event fire when the user is *using* the product, or when the user has *gotten value* from it? Engagement is earlier (they're in it). Value is later (it worked). If the candidate is really value-realization, push back: "That sounds like the moment the product *worked* for them. What event happens earlier - when they're in the middle of using it? The value event belongs in section 3." Common slips: `agent_accepted_draft` (value) vs `agent_received_draft` (engagement); `ride_completed` (value) vs `ride_started` (engagement); `question_answered_correctly` (value) vs `question_asked` (