Product Feedback Digest

## First run — make it yours

Before touching any data, interview the user one question at a time, then restate the resolved bindings for confirmation before running. On later runs, reuse these bindings unless the user asks to change them.

1. **Data source** — "Which data source holds the support conversations you want scanned? If several look plausible, I'll list the candidates so you can pick." Store as {{data_source}}. Call `list_data_sources`; if one obvious support-conversations table exists use it, otherwise show candidates and let the user choose. A wrong table silently corrupts everything downstream.
2. **Time window** — "What time window should I scan — the default last 7 days, or a custom range like since a specific outage or last month?" Store as {{time_window}} (default: last 7 days).
3. **Scope** — "Should I run over all support conversations in the window, or scope to one product area or channel?" Store as {{scope_filter}} (default: all conversations in the window).
4. **Output destination** — "Where should the finished report land — a Google Doc, or a .docx fallback if Google Workspace isn't connected?" Store as {{output_destination}}.
5. **Issue tracker project** — "After the report, do you want me to draft issues for the top bugs into an issue tracker, and if so which project?" Store as {{issue_tracker_project}} (optional).

Restate: "Scanning {{scope_filter}} from {{data_source}} over {{time_window}}, delivering to {{output_destination}}" and proceed.

---

# Product Feedback Digest

Turn a window of support conversations into two things a product org needs: a bug list engineering can act on without re-reading every ticket, and a feature-request list PMs can prioritize by real demand.

**The core idea:** the raw data knows which tickets happened; it doesn't know which ones are the *same* underlying bug or ask reported by different customers in different words. That clustering — and the resulting count — is what makes the report actionable. Do the clustering with enrichment, not by eyeballing summaries.

**When NOT to over-engineer:** if the user wants a simple count or a single distribution, that's a plain `aggregate_table` call, not this skill.

## Analysis engine

`list_data_sources`, `describe_table`, `create_worksheet`, `enrich_worksheet` + `get_enrich_status`, `aggregate_table`, `pivot_table`, `read_table`, `read_conversations`, `get_report_guide`. The worksheet→enrich path is the core: it reads each full transcript and adds per-row judgments. Enrichment cost scales with rows, not columns — batch every column into one `enrich_worksheet` call.

## Step 1 — Read the schema

`describe_table` on {{data_source}}. Identify: the recency field defining {{time_window}} (prefer creation date, fall back to last-activity); the id/link fields for evidence-pulling via `read_conversations`; roughly how many rows fall in the window (`aggregate_table` count). If it's tens of thousands, warn about enrichment cost and offer to sample rather than silently truncate.

## Step 2 — Build the worksheet

`create_worksheet` filtered to {{time_window}} on the recency field. Omit `columnIds` so every source column carries over. Title it `Product Feedback Digest — <date range>`. After it returns, `read_table` a few rows to confirm rows landed (hydration is async) before enriching.

## Step 3 — Enrich (ONE call, all columns)

Each judgment is made against the full transcript. Create:

1. **feedback_type** — `enum`, `multi: true`, values `["bug_report", "feature_request", "none"]`. Flag a genuine PRODUCT bug (malfunction relative to design — error, crash, wrong calculation, feature not working, data not syncing) and/or an explicit feature/product recommendation. A ticket can be both. A customer being upset about a policy, fee, security hold, or expected verification step is NOT a bug — only flag `bug_report` when something didn't work as *designed*, or an agent confirms a known issue. Return `none` when neither applies; don't inflate frustration into a bug or request.
2. **bug_topic** — `unspecified_enum`, `desired_cardinality: 15`. The canonical name of the *specific* underlying bug, so the same bug in different words lands under one label. Output `not_a_bug` if `feedback_type` excludes `bug_report`.
3. **bug_summary** — `string`. One engineering-facing sentence: what should happen vs. what actually happens. `"N/A"` if not a bug.
4. **bug_repro_context** — `string`. What the customer described about how/when it happens (device, timing, error text, steps), drawn only from the transcript — never invent steps. If no useful detail, say `"Customer did not provide reproduction detail."` `"N/A"` if not a bug.
5. **bug_severity** — `enum`, values `["critical", "high", "medium", "low", "not_a_bug"]`. Calibrate to {{scope_filter}}'s domain — critical = blocks a core transaction, causes incorrect data, or is a security/compliance exposure; high = breaks a workflow but has a workaround; medium = real malfunction with moderate friction; low = cosmetic; `not_a_bug` otherwise.
6. **bug_evidence_quote** — `string`. The customer's own words (≤25 words, verbatim, never the agent's or automated text). Empty string if none.
7. **feature_topic** — `unspecified_enum`, `desired_cardinality: 15`. The canonical name of the specific ask. Output `not_a_request` if `feedback_type` excludes `feature_request`.
8. **feature_request_summary** — `string`. One PM-facing sentence, "Customer wants X" (add "because Y" if given). `"N/A"` if not a request.
9. **feature_request_quote** — `string`. The customer's own words (≤25 words, verbatim). Empty string if none.
10. **affected_area** — `unspecified_enum`, `desired_cardinality: 15`. The broader product area (applies to bug or request). `"N/A"` if `feedback_type` is `none`.

Then poll `get_enrich_status` in a loop until `done: true` — it blocks; keep calling. Capture the returned column **ids** for the next step.

## Step 4 — Quantify and rank

Call `get_report_guide` once. Then, filtering out `not_a_bug`/`not_a_request`/`none`: `aggregate_table` on **bug_topic** crossed with **bug_severity** via `pivot_table`; `aggregate_table` on **feature_topic** crossed with **affected_area**. Sanity-check topic lists by eye — `unspecified_enum` occasionally over-splits near-duplicates; merge them before ranking. **Watch for an incident signal**: if one bug_topic's count is dramatically higher than others in the window, flag it at the very top rather than burying it. Rank bugs by severity then count; rank feature requests by count.

## Step 5 — Pull evidence

For each featured topic (top 8–12 of each, or fewer if fewer qualify — never pad), `read_table` the underlying rows for 2–3 example ticket ids per topic, then `read_conversations` on those ids (≤10 per call) to verify each quote is the customer's verbatim words and capture the real link (`ticketDoc.link`). Never invent a link.

## Step 6 — CHECKPOINT: show findings in chat before finalizing

Show a compact summary in chat first — headline count, the incident flag if any, and the ranked topic lists with counts/severity — before building the deliverable. Ask if anything looks off or needs re-scoping.

## Step 7 — Build the deliverable

Build the report as Markdown using the structure below, then publish to {{output_destination}}. If that is a Google Doc, call `mcp__plugin_google-workspace_google_workspace__import_to_google_doc` with `user_google_email` (from session context, or ask), `file_name` = `Product Feedback Digest — <date range>`, `source_format` = `"md"`, and `content` = the full Markdown inline (prefer `content` over `file_path`, which is often sandboxed). This creates a fully-formatted native Google Doc; report back the Drive link. If the google-workspace MCP isn't connected, say so plainly and fall back to a **.docx** via the `docx` skill with the same structure — say it happened rather than silently producing something different.

### Document structure

```
# Product Feedback Digest — <date range>
<N> conversations scanned · <B> flagged as bug reports · <F> flagged as feature requests

[If an incident signal was found, one bolded callout line here, above everything else.]

## Bugs — for Engineering
For each bug topic, ranked by severity then count:
  ### <bug topic> — <severity> · <count> reports
  <one-sentence engineering summary>
  Reproduction detail: <bug_repro_context, or the note that none was given>
  "<customer evidence quote>"
  Example tickets: <link 1>, <link 2>, <link 3>

## Feature & Product Recommendations — for PMs
For each feature topic, ranked by count:
  ### <feature topic> — <count> requests · <affected area>
  <one-sentence PM summary of the ask>
  "<customer evidence quote>"
  Example tickets: <link 1>, <link 2>, <link 3>

## Methodology
Window scanned, total conversations, link to the underlying Rippit worksheet(s), and a note that classification is AI-generated — treat topic groupings as a strong starting point, not ground truth.
```

Never fabricate a count, quote, or link. If a section is thin, say so — a padded report loses reader trust.

## Step 8 — Offer to route top bugs into an issue tracker (optional)

After the doc is built, offer to draft issues for the top N bugs into {{issue_tracker_project}}. If yes, confirm the project (`getVisibleJiraProjects` / ask) and get explicit approval before creating anything — `createJiraIssue` is a write action, not a side effect. Pre-fill each issue with the bug_summary, repro context, severity, and links back to the example tickets. Don't create issues below the report's "worth featuring" cutoff.

## Step 9 — Offer the recurring automation

Once the user is happy, offer to set it up as a recurring task so the digest builds itself. A recurring run can't do the first-run/checkpoint steps, so lock in {{data_source}}, {{time_window}}, and {{scope_filter}} as the task's fixed config rather than re-asking.

## Output discipline

- Never fabricate a quote, count, or ticket link — every number traces to an `aggregate_table`/`pivot_table` call, every link to a real `read_conversations` result.
- Keep the "customer upset ≠ bug" and "policy/fee/security-hold ≠ bug" distinctions sharp.
- Creating issue-tracker items and setting up a recurring task both require explicit approval at the moment of doing them.