iterate-post-launch

name: iterate-post-launch description: >- Close the post-launch improvement loop for any shipped app. Pulls Sentry for top errors and performance regressions, Supabase for slow queries, failed API calls, and advisor warnings, Firecrawl for current best-practice patterns. Identifies the top user pain points, ranks them by impact × effort, plans concrete improvements, implements fixes, and verifies them with Playwright. Generic across any stack. Use when asked to "improve the app after launch", "fix the top issues", "post-launch polish", "what should I fix next", "production issues", "iterate on feedback", "post-release improvements", "what is broken in prod", "ship a polish pass", or "make it better based on real usage". license: MIT

iterate-post-launch — Production Signal → Prioritised Fix Loop

You shipped. That is the beginning, not the end. Real users hit real paths you did not test. Sentry, Supabase logs, and the live UI tell you exactly what to fix next — if you know how to read them. This skill turns those signals into a ranked, actionable improvement plan and then implements it.

Plan → Signal → Triage → Fix → Verify. Do not guess what to improve. Let production data point to the highest-impact work first.

Before ANY browser action, read protocol-browser-anti-stall.

Phase 0: Context

Read the stack before pulling any signals:

package.json → framework, Sentry SDK, Supabase client version
.env.local    → SENTRY_ORG, SENTRY_PROJECT, SUPABASE_PROJECT_ID (name only)
README        → any known issues the team is tracking

Confirm available MCPs: plugin-sentry-sentry, plugin-supabase-supabase, user-firecrawl, user-playwright.

Phase 1: Pull production signals

Run all signal sources in parallel, then synthesise.

1a. Sentry — errors and performance

Look up tool schemas under mcps/plugin-sentry-sentry/tools/ first.

CallMcpTool(server: "plugin-sentry-sentry", toolName: "search_issues", arguments: {
  "organizationSlug": "<ORG>",
  "naturalLanguageQuery": "unresolved issues last 14 days sorted by frequency",
  "projectSlugOrId": "<PROJECT>",
  "regionUrl": "<REGION_URL>",
  "limit": 25
})

For each top-5 issue, get root-cause analysis:

CallMcpTool(server: "plugin-sentry-sentry", toolName: "analyze_issue_with_seer", arguments: {
  "organizationSlug": "<ORG>",
  "issueId": "<ISSUE_ID>",
  "regionUrl": "<REGION_URL>"
})

Record per issue: title, frequency (events/users), first/last seen, component.

1b. Supabase — query performance and API failures

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_logs", arguments: {
  "project_id": "<PROJECT_ID>",
  "service": "api"
})

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_logs", arguments: {
  "project_id": "<PROJECT_ID>",
  "service": "postgres"
})

CallMcpTool(server: "plugin-supabase-supabase", toolName: "get_advisors", arguments: {
  "project_id": "<PROJECT_ID>"
})

Flag:

• API: repeated 5xx, slow responses (>1 s), CORS errors, RLS denies
• Postgres: sequential scans on large tables, missing indexes, bloated RLS policies
• Advisors: ERROR-level items = immediate action; WARN = scheduled

1c. Live UX walkthrough (Playwright)

Navigate the app's 3–5 most-used flows as a real user. Look for:

• Anything that is obviously broken, slow, or confusing
• Empty/error states that have no message
• Console errors and network failures during normal use

browser_navigate → primary pages
browser_console_messages → capture errors
browser_network_requests → capture 4xx/5xx
browser_take_screenshot → visual evidence per page

1d. Research best practices for flagged areas

For each signal category that surfaced issues:

CallMcpTool(server: "user-firecrawl", toolName: "firecrawl_search", arguments: {
  "query": "<framework> <issue-type> fix best practices 2026",
  "limit": 3,
  "sources": [{ "type": "web" }]
})

Phase 2: Triage — rank by impact × effort

Build an improvement backlog. For each finding:

Priority mapping:

• Critical: production crash or data loss affecting real users
• High: broken feature, significant UX failure, missing index on hot query
• Medium: degraded experience, slow query, console error not shown to user
• Low: cosmetic issue, info-only log noise, minor UX annoyance

Sort the backlog: Critical first, then by impact ÷ effort (quick wins above hard ones).

Phase 3: Plan the improvement sprint

For the top 5–10 items, map each to specific code:

Improvement: [title]
Root cause: [1 sentence]
Fix: [file path + what to change]
Verify: [how to confirm it is fixed]
Risk: [low / medium — explain if medium+]

Present the plan to the user. Get confirmation before making changes.

Phase 4: Implement fixes

Work through the approved list one by one, following workflow-coding-discipline principles:

1. Read the file before editing. Understand the existing pattern.
2. Make the surgical change. No refactoring unrelated code.
3. ReadLints after each edit. Fix introduced linter errors.
4. For Supabase schema fixes (missing index, RLS policy):
   • Deploy via MCP: apply_migration for DDL, execute_sql for data fixes
   • Write the matching versioned migration file under supabase/migrations/
   • Verify the object exists: query information_schema / pg_indexes / pg_policies

Phase 5: Verify each fix

After each fix, drive the specific flow that was broken:

browser_navigate → affected page
browser_snapshot → confirm page renders correctly
[reproduce the original scenario]
browser_console_messages → green (no new errors)
browser_network_requests → 2xx where it was failing
browser_take_screenshot → evidence of fixed state

For Supabase fixes, re-run the failing query with execute_sql and confirm the performance improvement or policy correction.

For Sentry issues: mark as resolved only after live verification confirms the fix, not before:

CallMcpTool(server: "plugin-sentry-sentry", toolName: "update_issue", arguments: {
  "organizationSlug": "<ORG>",
  "issueId": "<ISSUE_ID>",
  "status": "resolved",
  "regionUrl": "<REGION_URL>"
})

Phase 6: Improvement report

## Post-Launch Improvement Report — [App] — [Date]

### Signal sources checked
- Sentry: [issue count, date range]
- Supabase logs: [service, date range]
- Supabase advisors: [ERROR count / WARN count]
- Live walkthrough: [pages tested]

### Improvements implemented
| # | Source | Finding | Fix (file) | Verified |
|---|--------|---------|-----------|---------|
| 1 | Sentry | [error] | [file:line] | ✅ |

### Deferred (needs more investigation or is out of scope)
| # | Finding | Why deferred | Recommendation |
|---|---------|-------------|----------------|

### Remaining Sentry noise
- [issues that are known / won't-fix / need tracking ticket]

### Before / after summary
- Errors resolved: [count]
- Queries improved: [count, estimated ms saved]
- UX issues fixed: [count]

Guardrails

• No speculative improvements — only act on signal from production data.
• Ask before deleting or restructuring — fixes should be surgical.
• Schema the user asked for ships; DELETE/UPDATE on real rows asks first.
• Re-test every fix live — a fix is not done until Playwright confirms it.