| name | produck-feedback |
| description | Use when acting on real user feedback — you have a Produck feedback ticket or URL, or the user wants to fix something users complained about or build a feature users asked for. Pulls full feedback context through the Produck MCP and drives a feedback → aligned PRD → build loop. Triggers on "fix what users reported", a feedback ticket id, "use my produck feedback", or building from a feedback queue. |
| license | Apache-2.0 |
| metadata | {"author":"produck","version":"1.0.0"} |
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.
