---
name: upg-send-feedback
description: "Share feedback about the Unified Product Graph: bugs, feature requests, ideas. Sent straight to the UPG team's triage queue."
user-invocable: true
argument-hint: "[bug|feature|observation]"
category: tooling
---

# /upg-send-feedback: Send Feedback to the UPG Team

You collect the user's feedback about the UPG and **send it via the `submit_feedback` MCP tool** so it lands directly in the maintainers' triage queue. Fast, transparent, private. No graph mutations; this is about THEIR feedback to US.

> **Mechanism:** this skill calls the native `mcp__unified-product-graph__submit_feedback` tool — the one write-OUT tool in the UPG surface. The tool is a thin HTTP client to `POST https://unifiedproductgraph.org/api/feedback`; it assembles context and enforces consent itself, so you do not `curl` and you do not gather context by hand.

**Before producing any output, read the design system:** `/upg-context` for emoji mappings, formatting rules, and shared interaction patterns.

## Tools

- `mcp__unified-product-graph__submit_feedback`: the send tool. Params: `type`, `title`, `description`, `details?`, `product_stage?`, `confirmed`. It auto-assembles `context` (client/server versions, runtime, and graph SIZE counts only) server-side — you never pass context, and no graph content is ever included.
- `Write`: ONLY as an offline fallback if the tool reports it could not reach the endpoint (see Step 7).

## Flow

### Step 1: Open

> Your feedback shapes how the Unified Product Graph evolves. This takes about **30 seconds**.

### Step 2: Ask Type

Skip this if the user provided `bug`, `feature`, or `observation` as an argument.

```
What kind of feedback?

1. bug; something broke or behaves unexpectedly
2. feature_request; something you wish existed
3. observation; a workflow friction, UX thought, or general note
4. general; anything else
```

ONE question. Wait for answer.

### Step 3: Ask Title

> Give it a one-sentence title.

Wait for answer.

### Step 4: Ask Description (and shape it to be actionable)

> Now the details; what were you doing, what happened, what did you expect?

Then SHAPE it so the team can act without a round-trip. Ask **one** short round of follow-ups only if the answer is thin; never guess. These become the tool's `details` object:

- **bug** → gather `steps_to_reproduce`, `expected`, `actual`, and a `severity` (low/medium/high/critical).
- **feature_request** → capture the underlying `problem` and `desired_outcome`, not just the proposed solution; note any current `workaround`.
- **observation / general** → the description is enough; omit `details`.

### Step 5: Preview (mandatory consent gate)

Do NOT set `confirmed` yet. Call the tool with the collected fields and **no `confirmed`** (or `confirmed: false`):

```
submit_feedback({
  type: "<type>",
  title: "<title>",
  description: "<description>",
  details: { <type-aware fields, omit if none> }
})
```

The tool sends NOTHING and returns `{ "status": "confirmation_required", "preview": { … } }`. The `preview` is the exact payload — including the auto-collected `context`. Show it to the user verbatim and get a yes:

```
Here's what I'll send to the UPG team:

  Type: <type>
  Title: "<title>"
  Description: "<description>"
  Details: <the type-aware fields, if any>
  Context: <the auto-collected context from the preview — client/server versions, runtime, graph counts>

No product graph data is included; just your feedback + the metadata above.

Send it? (y/n)
```

Wait for confirmation. If they say no, ask what to change or cancel gracefully. **Do not send without an explicit yes.**

### Step 6: Send

On an explicit yes, call the tool again with the **same fields plus `confirmed: true`**:

```
submit_feedback({
  type: "<type>",
  title: "<title>",
  description: "<description>",
  details: { <same as preview> },
  confirmed: true
})
```

A success returns `{ "status": "submitted", "id": "…", "message": "…" }`.

### Step 7: Confirm (or fall back offline)

On `status: "submitted"`:

```
Sent to the UPG team; thank you! Reference id: <id>

Your input directly shapes the Unified Product Graph.
```

The tool surfaces its own errors clearly:
- **429 (rate limited)** — tell the user to try again in about an hour. Nothing was saved.
- **401 (key rotated)** — ask the user to update `@unified-product-graph/mcp-server`.
- **Could not reach the endpoint** (network/offline) — fall back to local capture: use `Write` to save the feedback as `upg-feedback-YYYY-MM-DD.md` in the project root (append `-2`, `-3` if it exists), and tell the user:

```
Couldn't reach the feedback endpoint, so I saved it locally to upg-feedback-YYYY-MM-DD.md.
Send it when you're back online (open an issue at unifiedproductgraph.org and paste it in, or email it).
```

## Key Principles

- **FAST.** ~30 seconds. Type + title + description, shape if needed, preview, confirm, send.
- **One question at a time.** Never batch questions.
- **Send, don't stash.** The tool is the deliverable; the local file is only an offline fallback.
- **NEVER include product graph data.** The tool auto-assembles `context` from an allowlist (versions, runtime, SIZE counts) — never node titles, descriptions, or graph content. You never add context yourself.
- **Show before sending.** Use the tool's `confirmation_required` preview as the consent gate — the user must see and approve the exact payload before you re-call with `confirmed: true`.
- **No graph mutations.** Feedback only; no entities created.
- **Graceful degradation.** If the tool reports it couldn't reach the endpoint, save locally.