ce-product-pulse

Trigger phrases

Phrases that activate this skill when typed to Claude Code:

• show me the pulse
• weekly product recap
• how are we doing this week

What it does

ce-product-pulse generates a compact, single-page report on product health across a time window — typically 24h, 7d, or a custom duration. See skills/ce-product-pulse in Every’s compound-engineering plugin. You run it when you want a quick snapshot — “show me the pulse,” “weekly recap,” “how are we doing?” The report covers engagement metrics, value realization, system performance (latency and error rates), recommended follow-ups, and signals worth investigating.

It reads STRATEGY.md if present (so the report is framed against the product’s real key metrics rather than generic ones) and .compound-engineering/config.local.yaml for configuration, then pulls from external data sources — analytics, tracing, and optionally databases — and writes a timestamped report to docs/pulse-reports/YYYY-MM-DD_HH-MM.md. It keeps no PII in the saved output. In the plugin’s loop, it closes what ce-strategy opens: strategy declares the metrics that matter, and product-pulse measures the product against them while surfacing what to look at next.

When to use it

• A weekly or daily product health check — usage, errors, and latency in one page
• After a launch — did the numbers move, what broke, what to investigate
• Grounding a planning or ideation session in what users actually experienced
• Reporting up without hand-assembling a dashboard screenshot

When not to reach for it:

• Deep incident forensics — this is a pulse, not a root-cause investigation (pair it with ce-debug)
• Marketing / funnel analytics (GA4, attribution) — that’s a different lane (see analytics-tracking)
• Anywhere you’d need PII in the artifact — it deliberately strips it

Install

Part of the compound-engineering plugin (not a standalone ~/.claude/skills/ drop-in). In Claude Code:

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Then invoke /ce-product-pulse (e.g. /ce-product-pulse 7d). The plugin namespaces every skill with ce-. MIT-licensed.

What a session looks like

1. /ce-product-pulse 7d on a Monday morning.
2. It reads STRATEGY.md to know which metrics count, and .compound-engineering/config.local.yaml for data-source configuration.
3. It pulls data: engagement and value metrics from analytics, latency and error rates from tracing, optionally a database query.
4. It assembles a one-page report: what users experienced, how the product performed, signals worth investigating, recommended follow-ups.
5. It writes docs/pulse-reports/2026-06-01_09-00.md — timestamped and PII-free.
6. The “signals worth investigating” section becomes input to the next ce-plan or ce-debug.

The discipline that makes it work: the report is framed against STRATEGY.md, not generic vanity metrics. The pulse only means something if the numbers it reports are the ones the strategy said mattered — which is why the two skills are designed as bookends of the same loop.

Receipts

TODO — to be filled in from a real session. Once product-pulse has been wired to real data sources, this section will capture: which sources it connected to automatically vs. needed manual config in .compound-engineering/config.local.yaml, whether framing the report against STRATEGY.md’s metrics produced a more useful pulse than a generic dashboard, how clean the PII-stripping actually was, and whether the “signals worth investigating” section pointed at real issues or noise.

Source and attribution

From Every’s compound-engineering plugin — the MIT-licensed plugin (Dan Shipper & Kieran Klaassen) packaging Every’s engineering workflow.

License: MIT.

Quoting the skill’s own framing verbatim: a report on “what users experienced and how the product performed — usage, quality, errors, signals worth investigating.” It is the downstream measurement half of the ce-strategy → ce-product-pulse loop.