Skyelight: Powering up your feedback loops
Skyelight turns comments pinned on live pages into threads a team can discuss and a coding agent can act on. Building Skyelight has completely transformed the way we work through cycles with our clients.
If you’ve read our journal entry about building rapid prototypes, you probably know how obsessive we are about getting answers early. As we brought this process into more of our client projects (and internal ones too), it quickly became clear that we needed an easy way to keep idea threads, critical feedback, and issues in one place.
It also uncovered a huge unlock for our us as a team and as a business. These threads shed light on important decisions, concessions, hard rules, and impactful ideas. What’s usually spread across Slack, Google Docs, and email can be organized and fed right into where we work most these days: our coding agents.
Skyelight’s elevator pitch
In March of this year (2026), we started building Skyelight. At its core, Skyelight turns any live webpage into a shared workspace between you, your customers, your clients, and your agents.
Teams can add pins to any public URL. Maybe someone wants to reference some inspiration or build a library of examples for a project. But what makes Skyelight extra powerful is that on projects that are yours, pins capture far more than a regular browser DOM makes available.
If you’re familiar with a venogram, it’s a medical procedure where an iodine-based dye is injected into a vein through an IV so doctors can see the veins clearly on an X-ray. Think of Skyelight as the dye for your site in the browser, and the agent as the doctor!
When someone pins a comment to an element, we capture all the critical details an agent needs to understand where things are. In some cases, that saves a ton of inference with a grep-free session.
Feedback loops
The best feedback loop looks like an argument. Someone sees it differently. You defend. They counter. You bend a little. So do they. The outcome is inevitably stronger than what either of you would have made alone.
At strideUX, we believe this back and forth is the single most valuable tool when building technology products, and it’s even more important in the age of agentic design. The most powerful frontier models in the world are light-years away from human-level intuition and discernment. They make assumptions and prescribe solutions that often aren’t grounded in the reality we operate in with our customers and clients.
Skyelight turns a traditional surface into a place where these important conversations can happen, and where the agent gets guidance on what to do next. As users pin feedback to a project, those comments create agent context in two ways:
Above | The intent and overall classification |
|---|---|
Below | The structural map for an agent to follow |
The agent then uses this context to surface decisions, investigate bugs, plan out ideas, or build the solution. Not based on an arbitrary vision from the model, but on the laws created by the feedback loop.
Above: what the argument is about
Everything here runs through the Skyelight MCP server. Any agent that speaks MCP can plug straight into the conversation. Gone are the days of copying comments or dropping endless screenshots into a chat window.
Before an agent touches anything, it needs to know what people actually want and what it all means.
Every thread starts with a single comment, but that rarely tells the whole story. Someone says the button is confusing. Someone else replies that the button’s fine, it’s the label. A third person says neither, it’s in the wrong spot. The first comment is a hunch. The replies are where the team actually figures it out. The agent reads all of it, so it hears the pushback and not just the opening claim.
Then there’s what’s already been settled. Once the team lands on a decision, it becomes a rule in the project context. Nobody argues it again. Not the team, and not the agent.
Job | Tool | What it does |
|---|---|---|
Gather |
| Hosts a prototype or registers a live app so people can pin on it |
Gather |
| Opens a new thread on a URL |
Gather |
| Checks whether something was already reported |
Gather |
| Folds duplicates into one thread |
Understand |
| Lists the workspaces the agent can reach, and its role |
Understand |
| Lists projects, newest activity first |
Understand |
| Pulls outstanding threads, each with its hand-off |
Understand |
| Finds threads by text, replies included |
Understand |
| Returns the full work order for one thread |
Understand |
| Shows what changed since the agent last looked |
Understand |
| Maps feedback to the file and line that rendered it |
Act |
| Replies on the thread with what was found or changed |
Act |
| Moves a thread to open, deferred or resolved |
Act |
| Hands a thread to a person |
Act |
| Looks up who can be assigned or mentioned |
Remember |
| Pulls quoted material for a review or hand-off doc |
Remember |
| Pulls threads settled after discussion, plus the rules so far |
Remember |
| Adds a cited rule to the project context |
Below: the highway system
When someone drops a pin, Skyelight stamps the moment in time. The agent sees the exact element, how it’s built, and where it lives in the code. What’s even more exciting is that by giving the agent this stamp data directly, we consistently see token usage drop. The agent doesn’t have to endlessly grep through the codebase to find its sea legs.
Grep is a command-line utility that searches files or output for lines matching a specific pattern.
What’s captured | Why it matters to the agent |
|---|---|
Page URL | Knows exactly which page and state the feedback came from |
Element HTML | Sees the markup of what was clicked, not a description of it |
CSS | Knows how the element is styled and what’s driving the look |
Component | Knows which component rendered it, not just the DOM node |
Source file and line | Goes straight to the code, no hunting through the repo |
Element selector | Pinpoints the exact element, even when similar ones exist on the page |
Accessibility markers | Sees roles, labels and ARIA attributes, so fixes don’t break screen readers or keyboard use |
Screenshot | Sees what the person saw at the moment they pinned |
Viewport and device | Knows if it’s a mobile issue, a desktop issue, or both |
Author and timestamp | Knows who said it and when, so newer context wins |
It works in the other direction too. Before the agent edits a file, it can check what people have already said about it. That alone kills a whole category of “fixed one thing, broke the thing everyone liked.”
Closing the loop
The agent doesn’t take the feedback and disappear. It reports back on the same thread with what it found or changed. It marks the thread resolved or parks it for later. And when something needs a human call, it hands it to the right person.
When the project wraps, the whole record is surfaced and saved. The decisions, the rules, the reasoning behind them. Our vision is for Skyelight to eventually help fill in important parts of the coveted “Company Brain.” We’re working on some really interesting things there too, but more on that in a future journal entry.
Keep arguing
We didn’t set out to build another feedback tool. We set out to stop losing the good stuff. The pushback buried in a reply. The decision someone made on a call that never made it into a doc. The “no, not like that” that saves a week of rework.
Agents are fast, and they’re only getting faster. But speed without direction just gets you to the wrong place sooner. What they’re missing isn’t horsepower. It’s the context only people can give them. Skyelight puts that context right where the work happens, above and below every pin.
The argument still belongs to the humans. Skyelight just makes sure the agent was in the room for it.
So pin something. Argue about it. Then hand your agent the dye.