produck-feedback

Building from Produck feedback

Purpose: Turn real, in-context user feedback into shipped fixes. This skill drives the Produck MCP — it tells the agent how to find the right feedback, load the full context behind it, and convert that context into an aligned change instead of a guess.

Requires the Produck MCP server connected. If search_feedback / get_feedback are not available, see references/connect-mcp.md to connect it and mint a token first.

---

1. What this connects to

Produck captures feedback in the user's own session, so a ticket is far richer than a text complaint. Each ticket can carry:

• Written and spoken feedback — the user's typed note plus any voice transcription.
• Reconstructed page HTML — a static snapshot of the exact page the user was looking at.
• Annotation markers — the specific elements/regions the user pointed at.
• Session activity — a timeline of what the user did leading up to the feedback.
• A generated design doc — Produck's own first-pass analysis of the issue, when present.

The job of this skill is to pull that context and use all of it, not just the title.

2. The two MCP tools

The server is named produck (tools may appear prefixed, e.g. mcp__produck__search_feedback).

search_feedback — find relevant tickets

Returns lightweight summaries; use it to locate tickets, then load full context with get_feedback.

Input	Type	Notes
domain	string, optional	Filter to one website domain.
limit	int 1–50, optional	Defaults to 20.
cursor	string, optional	Pagination cursor from a previous call.

Returns { items, nextCursor, count } — each item a summary (id, domain, page URL, created-at, annotation count, source). Page with cursor until nextCursor is null when you need the full set.

get_feedback — load one ticket in full

Input	Type	Notes
feedbackId	string, required	The ticket id (from a search_feedback item, a URL, or the user).

Returns the full ticket: written/spoken feedback, reconstructed HTML, annotations, session activity, and the design doc when present. Always get_feedback before building — never act on a summary alone.

3. The operating loop

search_feedback   → find the relevant ticket(s) (filter by domain, page as needed)
get_feedback      → load ONE ticket's full context
user-alignment    → turn the ticket into an agent-executable PRD (do not skip)
build             → implement the fix / high-fidelity mockup
verify            → check the change against the ticket's annotations + design doc

• Do not jump from a raw ticket straight to code. A ticket is a user request, not a spec. Hand it to the user-alignment skill first to produce an aligned PRD — interpreted intent, scope, non-goals, acceptance criteria — then build from that. The two skills are designed to compose.
• Ground every decision in the captured context. Use the reconstructed HTML and annotation markers to locate the exact elements involved; use the session activity to understand what the user was doing; use the design doc as a starting hypothesis, not the final answer.
• Close the loop. When you finish, verify the result against the annotations and the stated outcome — the same ticket is your acceptance check.

4. Setup

To connect the MCP, choose the install path for your agent and mint a token — see references/connect-mcp.md.