Triage launch feedback into issues

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Triage launch feedback into issues

A launch of the production site leaves feedback everywhere: comments, emails, DMs, reviews. Turn it into a backlog I can act on: bugs reproduced and traced to the code, feature requests grouped and counted, and a short list of quick wins to ship while launch attention lasts.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Create issues in a tracker unless I ask.
- Fix bugs in this pass: this is triage.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Collect and sort

Ask me to paste the feedback or point you at exports. Split it into bugs, feature requests, confusion (the product works but people misunderstood it) and praise. Merge duplicates and count each. Strip names and personal details.

### 2. Trace the bugs

For each bug, try to reproduce it from the code or a local run, find the likely file and cause, and rate severity (data loss and payments first). Note when you cannot reproduce one and what you would need.

### 3. Size the rest

Group feature requests by the job they serve, count requesters, and estimate effort (small, medium, large) from the codebase. Turn confusion into copy or UI fixes: those are often the cheapest wins.

### 4. Write the backlog

Produce issues in Markdown (or create them with the GitHub CLI if I ask), each with a title, what was reported, how to reproduce, the suspected code, severity or demand, and effort. End with the five quick wins I should ship this week.

## Done means

- [ ] All feedback is sorted into bugs, requests, confusion and praise, merged and counted.
- [ ] Each bug has reproduction steps, a suspected cause in the code and a severity.
- [ ] Requests are grouped with requester counts and effort estimates.
- [ ] I have the backlog as issues and a list of five quick wins.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.