Turn recurring customer feedback into a draft feature PR

Why use this

1. A product team may hear repeated requests but struggle to distinguish one widely repeated complaint from several independent needs. Moving directly from frequency to code can hide conflicting requirements or a feature that does not fit the product strategy.

2. This job could connect feedback clusters to a scoped proposal and explicitly proposed engineering work. Keeping the evidence, threshold assumptions and unresolved trade-offs visible helps reviewers decide whether the next step is justified before an issue or draft pull request is created.

Why an agent / simpler alternative

Useful judgment

Group semantically related feedback, distinguish independent evidence and convert a bounded need into testable proposal questions.

Simpler alternative

Use a manual backlog review when feedback volume is modest and context is already clear.

Unsuitable when

The workflow would publish customer details, treat frequency as product authority or merge features automatically.

Proposed inputs

1. Name

   Approved feedback sample

   Owner

   Product owner

   Minimum scope

   Relevant excerpts with minimized customer identifiers

   Quality check

   Distinguish duplicate reports and independent sources

2. Name

   Proposal rules

   Owner

   Owner

   Minimum scope

   Configured threshold, strategy constraints and repository scope

   Quality check

   Clarify what reaching the threshold authorizes

Access and setup — proposed or unknown

Proposed minimum

1. Use fictional feedback and a draft specification outline; no live logs, issue creation, coding or pull requests.

Compatibility unknowns

1. Current feedback access, clustering behavior, repository integration and runtime compatibility are unknown.

External actions requiring approval

1. Sharing customer data, creating issues/PRs, code changes and recurring delegation requires explicit authorization; merge remains separate.

Expected deliverable and review checks

Proposed artifact

Evidence-linked feature proposal with cluster membership, conflicting needs, acceptance ideas and engineering questions.

Critical checks

1. Avoid duplicate-count inflation; preserve dissenting use cases; keep requirements proposed; separate threshold crossing from priority approval.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   Repeated copies of one complaint dominate the cluster

   Why it matters

   Frequency appears stronger than independent evidence

   Proposed response

   Deduplicate provenance before applying the rule.

2. Signal

   Two requests sound similar but need opposite behavior

   Why it matters

   A merged feature spec can satisfy neither

   Proposed response

   Separate use cases and ask the owner to resolve the trade-off.

Effort and cost — unknown

Setup work

1. Define feedback identity and threshold semantics.

Ongoing review

1. Product/engineering reviewers validate scope and any later implementation.

Unknowns

1. Feedback representativeness, clustering accuracy, development effort and costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent six feedback notes with duplicates and conflicting needs; draft clusters and a proposed feature brief.

Acceptance checks

1. Preserve provenance/conflict; apply no automatic priority; create no issue or code.

Stop conditions

1. Stop if threshold authority or customer-data sharing scope is unclear.

Limits

1. A feedback-derived proposal cannot establish demand, strategic priority or correctness of an implemented feature.