Feedback Triage skill for Codex

Triage is done well when every item is classified and routed within the agreed time, requests are recorded as problems rather than solutions, duplicates roll up into one record with a count of distinct accounts and their revenue, and requesters hear back when something changes.

Classify every item

Type	Definition	Route to
Bug	Product behaves differently from intended or documented	Bug tracker with repro, severity
Feature request	Wants a capability that does not exist	Problem record (below)
Usability issue	Capability exists but people cannot find or use it	Design backlog, link to problem record
Question / how-to	Needs an answer, not a change	Support; consider a doc gap
Praise	Positive signal	Tag for marketing and team morale
Noise / spam	Not actionable	Archive

When unsure between bug and request, check the docs or code: documented behaviour that users dislike is a request; behaviour contradicting docs or specs is a bug.

Extract the problem

Customers propose solutions. Record what they asked for and the problem underneath:

Request: "Add a Gantt chart view"
Problem: Account managers cannot show clients when deliverables land relative to each
other, so they rebuild timelines in slides every week.
Evidence: Ticket #48213, ACME Corp (Business plan), quote: "I spend Friday afternoons
redoing this in Keynote."

If the problem is unclear, mark needs-clarification and draft a follow-up question (“What were you trying to do when you needed this?”). Do not send it without the user’s approval if it goes to a customer.

Problem records and deduplication

One record per problem, not per request. Each record:

### PR-112: Account managers cannot show clients a delivery timeline
Status: new | under review | planned | in progress | shipped | won't do
Requests linked: 23 (Gantt view x9, timeline export x6, calendar view x5, other x3)
Distinct accounts: 17 | ARR represented: $412k | Segments: agency (14), in-house (3)
Churn/deal risk mentions: 2 (links)
Workarounds seen: slides, spreadsheet, Notion timeline
Latest evidence: <date, link>
Owner: <PM> | Linked roadmap item: <link or none>

Deduplicate by meaning, not keywords: “Gantt chart”, “timeline export” and “see due dates on a calendar” may be one problem; “Gantt for resource planning” may be another. When merging, keep every original link.

Weighting rules:

• Count distinct accounts, not messages or votes; ten messages from one account is one.
• Show ARR or plan mix, but never let revenue alone decide; record it as context.
• Flag explicit churn or deal-loss risk with a link to the source.
• Separate prospects (sales notes) from customers; both matter differently.

Triage workflow

- [ ] 1. Pull new items since the last run (export, API or connector; needs network)
- [ ] 2. Strip personal data not needed for triage (keep account ID, plan, link)
- [ ] 3. Classify each item; route bugs and questions immediately
- [ ] 4. For requests, extract the problem and match to an existing record or create one
- [ ] 5. Update counts, ARR, segments and latest evidence on touched records
- [ ] 6. Flag items needing clarification, urgent churn risk, or security reports
- [ ] 7. Close the loop on records whose status changed
- [ ] 8. Produce the digest

Security vulnerability reports go straight to the security contact, never into a public tracker.

Working with exports in Codex

Typical sources arrive as CSV or JSON exports (Zendesk, Intercom, HubSpot, App Store reviews). Process them in batches of a few hundred, keep a stable item ID column, and write results to a new file rather than editing the export:

item_id, source, account_id, plan, type, problem_record, summary, needs_followup

If a tracker is reachable through gh, an MCP connector, or an API the user has configured, creating or updating issues changes shared state: list the proposed changes and get approval first. Bulk-closing or deleting tickets requires explicit confirmation.

Closing the loop

When a record moves to planned, shipped or won’t do, draft a message to linked requesters:

• Shipped: what changed, link to docs, thanks for the specific request.
• Won’t do: honest reason, any workaround, invite further context.
• Planned: only if the date is committed; otherwise say it is under consideration.

Show drafts to the user; sending messages to customers needs explicit approval.

Digest template

# Feedback digest - <period>
Items processed: 412 (bugs 61, requests 188, usability 47, questions 102, praise 14)
Median time to triage: 1.4 days

## Top problems by distinct accounts (new evidence this period)
| Record | Accounts (+new) | ARR | Segments | Status |
## Rising (2x+ new accounts vs previous period)
## Churn / deal risk mentions
## Bugs reported via feedback: count by severity, top 3 with links
## Loop closed this period: <records and number of requesters notified>
## Needs PM decision

Gotchas

• Upvote counts on public boards measure the vocal and the recent; always pair with distinct account counts from all sources.
• Sales-reported requests often describe what one prospect asked once; record them, but label them as prospect evidence.
• A recurring question is often a usability or docs problem; tag it so it does not vanish into support.
• Do not promise delivery in replies unless the roadmap item is committed.
• Keep personal data out of shared triage docs; use account IDs and links.

Verification

Spot-check 20 random items: classification is right, each request links to a problem record, and the record’s problem statement fits the item. Recount distinct accounts on the top five records from the linked items. Confirm every routed bug has a repro or a needs-repro label, and that no customer message was sent without approval.