{ "schema_version": 2, "kind": "shortening-method", "format": "agent-skill", "id": "product-feedback", "name": "Product feedback", "category": "Work", "summary": "Group product feedback by user problem without turning requests into commitments.", "use_cases": [ "Feature request batches", "Customer feedback digests", "Product discovery notes" ], "word_count": 146, "url": "https://sho.rten.it/methods/product-feedback/", "instructions_url": "https://sho.rten.it/methods/product-feedback/SKILL.md", "skill_url": "https://sho.rten.it/methods/product-feedback/SKILL.md", "json_url": "https://sho.rten.it/methods/product-feedback/llms.txt", "plain_text_url": "https://sho.rten.it/methods/product-feedback/prompt.txt", "license": "MIT", "sources_url": "https://sho.rten.it/sources/#product-feedback", "skill_name": "product-feedback", "skill_description": "Group product feedback by user problem without turning requests into commitments. Use for Feature request batches, Customer feedback digests, Product discovery notes.", "agents_md_url": "https://sho.rten.it/methods/product-feedback/AGENTS.md", "sources": [], "instructions": "Condense the supplied product feedback into a problem-focused digest. Use this for a set of comments or requests; do not treat it as a representative survey unless the source establishes that.\n\nGroup comments only when they describe the same user problem. For each group, state who has the problem, the task they are trying to complete, the obstacle, and the consequence. Separate a requested solution from the underlying need. Keep conflicting preferences and feedback that changes the scope of a theme.\n\nUse a short heading and compact bullets for each theme. Retain supplied counts and their unit: people, accounts, comments, or mentions. Do not add overlapping groups together or infer prevalence from repeated messages. Include a brief quote only if its wording explains a need better than a paraphrase.\n\nEnd with unresolved questions already supported by the feedback. Do not create priorities, roadmap promises, or recommendations.", "example": { "before": "The feedback log contains messages from four accounts, not four individual users. Cedar and Larch each asked for scheduled CSV exports because their analysts currently repeat the same download every Monday before a reporting meeting. Cedar sent three messages about that one request. Larch said that a Monday email with the CSV attached would also solve its problem. Birch asked to hide columns before exporting because external partners should not receive internal cost fields. Birch already removes the fields in a spreadsheet, which takes time. Elm prefers the current manual export because someone checks the figures before sharing them. The log does not tell us whether Cedar or Larch needs that review step. None of these requests has been accepted for the roadmap.", "after": "Four accounts provided feedback; message counts are not account counts.\n\nRepeated reporting work — Cedar and Larch want to avoid manual Monday downloads before reporting meetings. Cedar's three messages concern one request. Larch would also accept an emailed CSV.\n\nPartner-safe exports — Birch wants to exclude internal cost columns. Removing them in a spreadsheet takes time.\n\nManual review — Elm prefers manual export so someone checks figures before sharing.\n\nNo request has been accepted for the roadmap.\n\nOpen question: Do Cedar or Larch need a review step?", "context": "Export feature feedback", "must_preserve": [ "Four accounts, not individual users", "Cedar and Larch Monday reporting need", "Cedar three messages are one request", "Larch emailed CSV alternative", "Birch cost fields and manual removal", "Elm prefers manual review", "Cedar/Larch review need unknown; no roadmap acceptance" ], "omitted": [ "Conversational framing of the feedback log" ], "kind": "illustrative" } }