Review pending LaunchDarkly flag changes in one inbox

Build me an app that acts as a review inbox for pending LaunchDarkly feature flag change approvals, so change reviews stop living in Slack threads and my reviewers have one screen that shows what is waiting, what it changes, and what it might break.

The main view is a queue of pending approvals. Build it from LaunchDarkly's List approval requests, filtered to requests still awaiting review. Group the queue by environment and always sort the production group to the top, since those are the ones that matter most. Within each group, sort oldest first. For every request show the requester, the project and environment, the flag it targets, and how long the request has been waiting. Highlight anything older than 24 hours with a clear visual treatment and a label explaining why it stands out, because those are the requests holding up a release.

Do not show reviewers a raw diff. Each request carries the instructions describing the change it would make, so translate those into plain language on the card: something like "Turn this flag on in production" or "Increase the rollout from 10 percent to 50 percent of traffic" or "Add the beta-users segment to the targeting rules". Next to that plain language description, show the flag's current state so the reviewer gets a real before and after. Use Get feature flag for the flag's per-environment configuration, and Get flag status across environments so a reviewer can see whether this flag is already live elsewhere. Present it as two columns, current state on the left and what it would become on the right.

Reviewers decide inline. Each request needs an Approve button and a Deny button, both of which take a comment, wired to Review approval request. Approving records the sign-off but does not ship the change. Shipping is a separate Apply button, enabled once a request is approved, wired to Apply approval request. Keep these as two distinct steps so a change can be approved ahead of time and pushed live when the team is ready. LaunchDarkly returns a conflict error if the flag was modified by someone else in the meantime, so if an apply fails that way, re-read the request and the flag, tell the reviewer what changed underneath them, and let them retry rather than silently failing.

Every decision posts to our team channel with Slack's Send a Message. Post as the bot and write the deciding reviewer's name into the message text, along with the flag, the environment, the plain language summary of the change, the decision, and the comment they left. App handlers run under the app owner's connection, so naming the reviewer in the body is what keeps attribution honest rather than making every decision look like it came from one person.

Decided requests move to a "Recently decided" tab rather than vanishing. That tab shows the same request detail plus who decided, what they decided, their comment, and when. Reviewers should be able to look back at recent history without leaving the app.

Add a "Risk check" button on every pending request that fires a background agent. The agent reads the pending change and works out the blast radius: which environment it touches, what share of traffic it affects, and which segments are involved. It calls List dependent feature flags to catch any flag using this one as a prerequisite, since those are the changes that break things unexpectedly. It pulls the flag's recent change history with List audit log entries to see whether this flag has been churning or recently rolled back. It calls Get code references statistics for flags to gauge the code footprint, so a flag referenced in fifty places reads as riskier than one referenced twice. It then writes a short risk note, a few sentences plus a plain low, medium, or high call, which gets stored against that approval request in the app and displayed on the card for the reviewer to read before deciding. Show a pending state on the button while the agent works and surface the note as soon as it lands.

Two things to handle gracefully. Approvals are a paid tier feature in LaunchDarkly, so say that plainly on the page rather than showing a mysteriously empty queue: if the account's plan does not include approvals, explain that the inbox needs a plan with change approvals enabled. Dependent flags and code reference statistics are also gated and depend on connected repositories, so when the risk check cannot get them, have it say which signals were unavailable and give its assessment from the rest instead of erroring out.

Let me set the LaunchDarkly project and the Slack channel for decision notices in one settings area, and let me adjust the 24 hour urgency threshold there too.