Shrivu framed the pain point simply: exploring portal UI changes is trickier than it should be, especially when agents are writing code and moving fast. A GitHub PR can show hundreds of lines changed, but the reviewer still doesn’t know what the update looks like in practice.

The “default” workflow is familiar and expensive:

1. Pull the branch locally

2. Make sure the environment is set up (packages, tooling, versions, etc.)

3. Run the app, navigate to the right place, reproduce the UI state

4. Finally see the change… then repeat for the next iteration

That’s already annoying for engineers. For designers and other non-technical collaborators, it can be a non-starter. Shrivu even called out a concrete example: Miguel (design) has been closely partnered on making the portal more AI-friendly, and local setup makes every review cycle heavier than it needs to be.

Prompt to Demo Portal takes advantage of prior work integrating Modal and making NORA PR more powerful. The outcome is a new capability: the ability to review portal changes, or even initiate them, directly from Slack.

Instead of “read PR → run locally,” the workflow becomes:

1. Drop an input into a Slack channel (a PRD, a request, or even a wild theme idea).

2. Nora builds the portal change (or checks out the relevant branch).

3. The system generates a walkthrough artifact, most notably, a recorded demo video, so reviewers can immediately see what changed.

4. Iterate in-thread, asynchronously, without requiring everyone to run the code.

Shrivu emphasized that while the Slack surface is convenient for the demo, the bigger takeaway is the underlying capability: getting a lot of product-review leverage just by prompting.

In the demo, Miguel posts something like: “Take this PRD and create the proper artifacts.” The system then goes through a “show, not tell” flow where it captures screenshots, annotates and narrates what changed, and produces a walkthrough-style demo (with work underway to make it “production-quality video”).

That output is immediately useful for designers validating UI intent, PMs reviewing feature behavior, stakeholders giving feedback without waiting on a live walkthrough, and engineers moving faster because review cycles aren’t blocked on “can you run this locally?”

Shrivu pointed out a broader direction: this isn’t only about internal portal development. It’s a preview of how support and product feedback loops could work.

A customer asks for a feature, and we can build it quickly. And in the same loop, we can send back a video showing what it would look like. That makes the conversation concrete, faster, and more collaborative

It’s not just “we could do this,” it’s “we can show it.”

The biggest practical wins are straightforward:

• No local setup required for reviewers to understand a UI change

• Async review becomes real because the output is visual and shareable

• Design + non-technical stakeholders can participate without depending on engineers to run and screen-share

• Iteration cycles compress. The bottleneck becomes feedback quality, not environment setup

Shrivu framed this as a quick build and a capability demo, not necessarily “the final tool we’ll use in Slack forever.” But the direction is clear:

• harden the demo recording pipeline (higher quality, less finicky)

• embed this into other workflows, especially support flows where “show me what you mean” is the fastest path to alignment

• keep pushing the idea that sometimes the biggest product unlock is not new code; it’s finding the right prompt + workflow wrapper that makes existing systems dramatically more usable.