# ce-product-pulse

> A skill from Every's compound-engineering plugin that generates a time-windowed (24h / 7d / custom) one-page product-health report — engagement, value realization, latency and error rates, plus signals worth investigating. It reads `STRATEGY.md` and `.compound-engineering/config.local.yaml`, pulls from analytics, tracing, and optional databases, and writes a timestamped report to `docs/pulse-reports/` while keeping no PII in saved output.

**Use case**: Get a fast 'how is the product actually doing' snapshot tied to the metrics declared in STRATEGY.md

**Canonical URL**: https://agentcookbooks.com/skills/ce-product-pulse/

**Topics**: claude-code, skills, product-strategy, documentation

**Trigger phrases**: "show me the pulse", "weekly product recap", "how are we doing this week"

**Source**: [Every](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-product-pulse)

**License**: MIT

---

## 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](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-product-pulse) in [Every's compound-engineering plugin](https://github.com/EveryInc/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](/skills/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](https://github.com/EveryInc/compound-engineering-plugin/tree/main/plugins/compound-engineering/skills/ce-product-pulse) — 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.