Prism

One-click fix for PRs. Request edits directly in a sandbox of your codebase and have an AI agent write the code and push changes instantly.

Comment

Inspiration

Code review is disconnected from the actual user experience. Reviewers either run code locally, wait for CI deployments, or rely on screenshots. Even when previews exist, suggesting UI changes means context-switching to an IDE, making precise edits, and creating commits manually. We wanted to bring the review experience into the browser: see the app, point at what to change, and have it committed back to the PR—no local setup required.

What it does

Prism is a GitHub App that automatically spins up live preview environments for pull requests using Daytona sandboxes. When you open a PR, the app creates a sandbox with your branch, posts a preview URL in a comment, and reviewers get a live app with React-Grab enabled. They click any element, describe the change (e.g., "make this button blue"), hit Apply, and OpenCode.ai edits the source and commits to the PR branch. The preview updates in real time via HMR, and the new commit shows up on the PR—all without leaving the browser.

How we built it

We built it as a 4-developer full-stack team in a 4-hour sprint. The stack is Daytona.io, React-Grab, OpenCode.ai, a GitHub App, and Next.js.

  • GitHub App (Probot/Octokit): Listens for pull_request.opened and pull_request.synchronize, calls the Daytona API to create a workspace, and posts the preview URL in a PR comment. We store workspace ID by PR for cleanup on close/merge.
  • Daytona sandbox: Workspace config clones the PR branch, runs npm install and the dev server, and exposes preview URLs for the app (port 3000) and the API bridge (port 4000). OpenCode runs inside the sandbox.
  • React-Grab: Integrated into the Next.js app in DEV only. A floating panel shows the selected element, source file/line, and a change input; the Apply button sends the request to our bridge.
  • OpenCode bridge: A DEV-only Next.js API route /api/opencode receives { file, line, change }, calls the OpenCode TypeScript SDK to edit the file, then stages, commits with [PR Preview] {description}, and pushes to the PR branch. The UI gets back success and commit SHA for feedback.

We agreed on API contracts up front (Daytona createWorkspace, callback with preview URL, POST /api/opencode), then built in parallel and integrated in the last hour.

Challenges we ran into

  • Daytona workspace startup time: Sandboxes can take a while. We added a "spinning up" status in the PR comment and considered pre-warming a workspace so the first preview feels faster.
  • OpenCode edit accuracy: Natural-language edits aren’t always pixel-perfect. We improved this by sending very specific prompts with exact file path and line context; for the demo we accepted "good enough" and focused on the flow.
  • React-Grab source mapping: Sometimes the selected element didn’t map to the right file/line. We tested with simple components first and kept a fallback for manual file input if needed.
  • Git push permissions: Pushing from the sandbox required proper GitHub auth. We used the GitHub App installation token and validated the auth flow early so commits could land on the PR branch reliably.

Accomplishments that we're proud of

  • End-to-end flow in one sprint: From PR open → preview comment → click element → describe change → Apply → commit on the PR and HMR update in the preview.
  • Clear handoffs: Clean interfaces between the GitHub App, Daytona, React-Grab, and the OpenCode bridge made parallel work and integration straightforward.
  • Demo-ready MVP: Single repo, Next.js only, text/style changes and single-element edits—scoped so we could demo the full loop without overreaching.
  • Documented architecture: We had a shared PRD and system diagram so everyone knew how the pieces connected and we could debug and demo with confidence.

What we learned

  • Contract-first integration: Defining the APIs (Daytona createWorkspace, preview URL callback, /api/opencode request/response) before coding let us integrate quickly in the last hour.
  • Scoping for the time box: Focusing on one framework (Next.js) and simple edits (text/style, single element) kept the 4-hour sprint achievable and the demo reliable.
  • Risks as checklist: Turning risks (startup time, OpenCode accuracy, React-Grab mapping, git auth) into explicit mitigations helped us avoid last-minute surprises.

What's next for Prism

  • Multi-repo support: Support more than one repo per installation and make repo/branch selection configurable.
  • Beyond Next.js: Extend to other frameworks (Vite, Remix, etc.) with the same preview + apply flow.
  • Richer edits: Support complex refactors (moving components, adding files) and multi-element changes in one apply.
  • Auth and isolation: Multi-user support and proper sandbox isolation so teams can use it in production.
  • Change preview before commit: Let reviewers see a diff or preview of the change before committing, with optional undo/redo.
  • Polish: Rate limiting and debouncing for rapid successive applies, and better loading/error states in the React-Grab UI.

Built With

Share this project:

Updates