OpenParable
Skip to content
← Back to skills

produck-feedback

Development

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.

View on GitHub ↗
QUICK START

How to use this skill

Bring this guide into your coding agent with a prompt tailored to the tool you use.

  1. Open your project in Codex.
  2. Copy and paste the prompt below.
  3. Review files and risks before approving any action.
Prompt to paste
Inspect the Agent Skill at https://github.com/tryproduck/produck-skills/blob/HEAD/skills/produck-feedback/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/produck-feedback, but wait for my approval before writing files or running scripts.

Copying this prompt does not install or run the skill. Review third-party files before use.

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.

InputTypeNotes
domainstring, optionalFilter to one website domain.
limitint 1–50, optionalDefaults to 20.
cursorstring, optionalPagination 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

InputTypeNotes
feedbackIdstring, requiredThe 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.