Feedback 2 PR - Turn feedback into pull requests

See every report's status — without asking.

One row per report. State, phase, PR number, last activity — auto-refreshed. When an agent needs you, the row tells you. When it doesn't, the PR just shows up.

app.feedback2pr.com/feedback

Feedback

All

Awaiting input

2 reports

In progress

3 reports

Awaiting QA

1 report

Closed (7d)

8 reports

Reports

#	Title	State
#42	Date filter defaults to wrong range	Investigating
#41	Stripe webhook missing customer.subscription.updated	Awaiting your reply
#40	Logo wrong color on sign-up screen→ PR #318	In review
#39	Pagination breaks on empty result→ PR #317	Awaiting QA
#38	Onboarding tooltip overlaps button on iPad→ PR #316	Closed

Auto-refreshing every 10s · last update just now

Investigator agent

Drafting plan… reading 6 files

Needs you

Investigator parked here — pick an option.

Review passed

Three reviewers green — deploying to QA.

Investigator agent

Drafting plan… reading 6 files.

Needs you

Investigator parked here — pick an option.

Review passed

Three reviewers green — deploying to QA.

Pipeline

Five agents do the boring parts. You stay in the loop only where it matters.

Plan draft · #42

// 1. Fix date range default

src/lib/dates.ts · line 24

// 2. Update filter dropdown

src/app/feedback/page.tsx · line 80

// 3. Backfill stored ranges

scripts/backfill-ranges.ts · new

3 files · 1 question for client

Triage

From report to plan in seconds

The investigator agent reads the issue and the codebase, drafts a numbered plan, and flags only the questions that genuinely need humans.

#technical-judgmentjust now

Caching strategy — quick call?

Stripe sub data lives in two places now. Two reasonable approaches:

A · Cache in Neon

Simple. 5min staleness OK.

B · Always read from Stripe

Fresh. Adds API latency.

Decisions

Slack only when it's earned

Architectural calls go to #technical-judgment with named options and one-line tradeoffs — not 'let me know what you think.'

Build

Lint, typecheck, build — every time

The code-writer subagent is the only thing with write access. It runs the same checks your CI does before opening the PR.

PR #3183 reviewers · clean

Correctness0 blocking

Security0 blocking

Conventions1 nit

Review

Three reviewers in parallel

Correctness, security, conventions. Critical and major findings block; minor and nit are advisory. Idempotent per SHA.

Ship

Tech review, then QA

A grouped diff summary goes to #tech-review. After deploy, a generated test plan goes to #qa with the live URL.

Engineering quality

Production patterns, not chat-window suggestions.

// repo-investigator.output_schema

type: object,

required: [summary, paths],

properties:

summary: { type: string, maxLength: 1500 }

paths: { type: array, maxItems: 20 }

confidence: { enum: [low, med, high] }

Caps on free text. Caps on arrays. Prompt-injection hygiene.

Schemas

Every subagent has a schema

JSON Schema with maxLength on strings and maxItems on arrays. Prompt-injection hygiene, not just documentation.

mcp_servers

github${GITHUB_MCP_URL}

neon${NEON_MCP_URL}

slack${SLACK_MCP_URL}

resend${RESEND_MCP_URL}

MCP

GitHub, Neon, Slack, Resend

MCP servers wired in once. Env-injected URLs, no hardcoded endpoints, no per-agent integration glue.

Single writer

One subagent holds the pen

Orchestrators are read-only. One designated writer commits to GitHub, the DB, or Slack — so the audit trail stays small.

PR #318opened by feedback-2-pr-bot

✓ checks

src/lib/dates.ts

- const DEFAULT_RANGE = 30

+ const DEFAULT_RANGE = 7

src/app/feedback/page.tsx

+ <Select defaultValue="7d">…</Select>

Real PRs

Pull requests, not snippets

The output is a branch, a passing build, a description, and a review. You can merge it. You can also revert it.

How it works

Nine steps from “the dashboard feels wrong” to a merged PR.

Each agent runs once per webhook, persists state to the database, and hands off. No agent sits idle waiting for a human — humans gate only the parts that genuinely need judgment.

1
External · Intake
Userback report lands
The intake service writes a row to feedback_issues and opens a GitHub issue. Not an agent — just a webhook.
2
Agent · feedback-investigator
Investigate and draft a plan
Reads the issue and the codebase, drafts a plan, and decides which uncertainties actually need humans.
3
Agent · feedback-investigator
Email the client (only if needed)
Sends a self-contained option picker. The client clicks, pastes the token back, and the agent picks up where it left off.
4
Agent · feedback-investigator
Ping #technical-judgment
For architectural calls — named options with one-line tradeoffs. Not "let me know what you think."
5
Agent · client-reply-handler
Process the reply
Same orchestrator handles email pasteback and Slack threads. Validates the token, flips the gate, moves on.
6
Agent · feature-implementer
Write the code and open the PR
Single writer subagent. Runs lint + typecheck + build on every attempt — up to three — then opens a real PR.
7
Agent · pr-reviewer
Review in parallel
Correctness, security, conventions — three reviewers, idempotent per SHA. Only critical and major block.
8
Agent · release-coordinator
Hand off to #tech-review
A diff summary grouped by area so a human reviewer can sign off in under a minute.
9
Agent · release-coordinator
Hand off to #qa
After deploy, posts the URL and a generated test plan. A ✅ reaction closes the loop.

Turn feedback into pull requests.