workflow-feedback-to-closure

name	workflow-feedback-to-closure
description	Turn raw feedback — bug reports, user complaints, review comments, Sentry issues, QA findings, audit/red-team output — into deduplicated, durable, trackable tickets and drive each to production-verified closure. Normalize and cluster incoming signals, dedupe against existing issues, write clear reproducible tickets, prioritize by impact, fix via the right skill, and close only after the fix is verified live. Use when "triage this feedback", "turn these reports into tickets", "process the bug backlog", "handle these review comments", "close the loop on QA findings", or "manage incoming issues". Bridges audit/QA/monitoring outputs into complete-everything and workflow-fix-and-ship.
license	MIT

workflow-feedback-to-closure — Signal → Ticket → Verified Closure

Feedback dies in three ways: it is never captured, it is captured twice, or it is "fixed" but never verified in production. This skill prevents all three by forcing every signal through capture → dedupe → durable ticket → fix → live-verified closure.

A ticket is closed only when the fix is verified where the user hit it — not when a PR merges. No signal is dropped silently; each ends as done, deduped, tracked, or explicitly won't-fix with a reason.

Phase 0 — Gather and normalize

Collect every incoming signal for this pass and record its source:

• user reports / support messages / app-store reviews
• Sentry issues and alerts (search_issues, analyze_issue_with_seer)
• QA and red-team findings (test-qa, test-red-team)
• audit outputs (audit-*, plan-* reports)
• PR review comments and bot findings
• production logs and advisors (get_logs, get_advisors)

Normalize each into a common shape: { source, raw, symptom, suspected area, severity signal, first/last seen, evidence link }. Do not fix anything yet.

Phase 1 — Dedupe and cluster

1. Cluster signals that describe the same underlying defect (same stack trace, same flow, same root symptom). One defect = one ticket, with all reporting sources attached as evidence.
2. Dedupe against what already exists before creating anything: search the issue tracker (gh issue list/search), .cursor/ state files, and existing Sentry issue links. Link duplicates to the canonical item; never open a second ticket for a known defect.
3. Separate genuine defects from feature requests and from "working as intended" — route the latter two out, with a note, rather than forcing them into the fix pipeline.

Phase 2 — Write durable, reproducible tickets

For each unique defect, produce a ticket that a different engineer could act on:

### <concise title>
Sources: <Sentry link, report ids, review, audit finding>
Severity: Critical | High | Medium | Low   Impact: <who/how many>
Environment: <where observed>
Repro:
1. <step>
Expected: <...>   Actual: <...>
Suspected area: <file/module/endpoint>
Acceptance: <observable proof the fix works>

Persist the batch to .cursor/feedback-closure-state.md and, when a tracker is in use, create/label the corresponding issues (gh issue create). The state file is the source of truth if context compacts.

# Feedback → Closure: <batch/date>
Tracker: <gh repo / none>

## Tickets
- [ ] <id/title> — severity — status: open|in-progress|fixed|verified|wont-fix
      dedupe: <canonical or "unique"> — acceptance: <proof>

## Duplicates merged
- <signal> → <canonical id>

## Not a defect (routed out)
- <signal> — <feature request / by design> — <where routed>

## Evidence
- <ticket>: <fix + verification result>

Phase 3 — Prioritize

Rank by impact × severity ÷ effort. Critical production crashes and data-loss paths first, then broad UX breakage, then degraded experiences, then cosmetics. Present the ranked list; for large batches confirm the cut line with the user.

Phase 4 — Fix through the right skill

Drive each ticket to a fix using the matching workflow — do not improvise:

• reproducible bug from a report/Sentry → workflow-fix-and-ship
• a plan's connected deferrals / parked work → complete-everything
• FE/BE contract or 4xx/5xx mismatch → debug-fe-be-integration
• security/validation finding → the relevant plan-* remediation after approval
• whole-repo health debt → workflow-green-repo

Add a regression test that would have caught the defect. Update the ticket status to fixed (not verified) when the code lands.

Phase 5 — Verify and close

• Verify each fix where the user hit it: live flow via test-playwright, the failing query re-run, or the production signal confirmed gone after deploy (pair with workflow-ship-and-observe when a release is required).
• Only then set the ticket to verified and resolve the linked Sentry issue / close the tracker issue. Closing before live verification is forbidden.
• A defect that cannot be reproduced or verified is marked needs-info with the precise missing detail — not silently closed.

Phase 6 — Report

## Feedback → Closure — report (<date>)
Signals in: <n>  Unique defects: <n>  Duplicates merged: <n>
### Closed (verified live)
| Ticket | Severity | Fix (file) | Verified |
### In progress / deferred (tracked, with owner or reason)
### Routed out (feature request / by design)
### Won't-fix (justified)

Leave .cursor/feedback-closure-state.md as the audit trail unless asked to remove it.

Related

• workflow-fix-and-ship — the per-bug fix→verify→ship lifecycle
• complete-everything — close a plan's connected parked work
• iterate-post-launch — mine production signals proactively
• workflow-ship-and-observe — verify fixes live and watch stability
• debug-sentry-monitor — triage and resolve Sentry issues
• verification-before-completion — a ticket closes at verified, not merged