From a visitor who got stuckto a merged pull request.

The same chat widget that answers your customers can record their session in the browser. The recording stays on the visitor's device and is uploaded only when something happens: a JavaScript error, a failed API call, a rage click, an action that failed, or the visitor opening a conversation. A session where nothing goes wrong never leaves the browser.

• It records the page structure, clicks, navigation and scrolling, not a screen video. Canvas and 3D viewers are captured as frames.
• Every input field is masked. Add starko-mask to hide an element's text, or starko-no-capture to leave it out entirely.
• Recordings are deleted after 7 days, or after 30 when they belong to a conversation or a ticket.
• The upload triggers are set on Starko's side, so they change without a redeploy of your site.

When the visitor writes, Starko AI replies from your knowledge base on the channel they used: the web widget, WhatsApp, email, Instagram or Slack. What it cannot settle goes to your team with the conversation, the customer record and the recording in one thread. Questions it could not answer are tracked as knowledge gaps, so the help center gets written where customers actually look.

• The support side, inbox, AI answers, ticketing and knowledge base, is free.
• Every channel lands in the same inbox, so a WhatsApp complaint and a widget recording can point at the same problem.
• See channels and the support inbox.

When the conversation settles, Starko rebuilds the recording in a short-lived sandbox, screenshots the moments around the errors and the trigger, and resolves what each click actually hit. That becomes a timeline a model can read: pages, clicks with their targets, masked typing, idle gaps, errors, and the moment the chat opened. A classifier reads it next to the conversation, because the visitor's own words say what they were trying to do.

• The verdict is one of five: Smooth, Hesitation, Confusion, Dead end or Inconclusive. Inconclusive is a valid answer, preferred over a confident guess.
• Each piece of evidence cites a [mm:ss] moment that exists in the timeline, so a person can jump straight to it.
• Clips with under 10 seconds of activity or fewer than 50 events are skipped, not guessed at.
• Recordings without a conversation, started by an error or a rage click, are read too, with a stricter bar, since intent has to come from behaviour.
• The conversation is treated as data. Instructions a visitor types into the chat are never followed.

A recording is filed on its own only when the verdict is Confusion or Dead end at 70% confidence or more, or when the visitor described the problem themselves (60% and up). Before filing, Starko checks the open recommendations from the last 90 days. If one already covers the same thing, the recording is added to it as a sighting. Ten confused visitors become one recommendation with ten sightings, not ten tickets.

• Tickets in a project linked to a repository, from any channel, are classified as a bug, a feature request, a docs gap or a question.
• A bug report that is missing what a fix needs gets an internal note listing exactly what is missing.
• Every Monday a digest groups the week's recordings into themes for the team.
• A Hesitation, or a verdict under the confidence bar, stays on the conversation, where a person can still file it with one click.

Recommendations wait on Home and the Improvements page, written for whoever owns the product, not only for engineers: bug or improvement, Small, Medium or Large, what Starko understood, what fixing it means, and a credit estimate. Accepting shows the checks, the credit cap and your balance afterwards before anything starts. Declining asks for a reason, which stays on record so later recommendations learn from it.

• A project can opt into auto-dispatch for small bug fixes. It is off by default and runs within a monthly budget, one live run per project, three automated attempts per ticket.
• Mention @starko in an internal comment on any ticket to start a run by hand.
• Or decide from Claude, Cursor or VS Code through the Starko MCP server.

An accepted recommendation becomes a run in an isolated sandbox with your repository and your real toolchain: Node, Docker Compose services, Playwright and a browser. Starko prepared that environment itself when the project was connected. It installed dependencies, started the app and proved it ran with a screenshot, asking you only for the secrets it cannot know. The agent gets the ticket, the conversation and a digest of the recording, then works to a fixed contract.

1. 1Reproduce first, with a probe that fails.
2. 2Make the smallest change that fixes it.
3. 3Verify: the probe passes, and the tests and typecheck run.
4. 4For a UI change, take before and after screenshots.
5. 5Open a draft pull request: Problem, Reproduction, Fix, Verification, Risk, Out of scope.

When the pull request opens, a second agent reviews it with the diff, the evidence, CI and the original classification. It rates overall risk plus side effects, compatibility and performance, lists its concerns and names any evidence that is missing. A revise verdict sends the run back with those notes. A red check suite does the same with the failing output. A GitHub review that requests changes, or mentions @starko, is copied into the ticket and resumes the same run.

• Automated revisions are capped per pull request, so a run cannot loop on its own.
• Only owners, members and collaborators on the repository can steer a run from GitHub.
• The command log comes from the sandbox session itself, not from the agent's summary of what it did.

The pull request opens inside Starko with an Evidence tab: what was reproduced, the commands that ran, before and after screenshots, the reviewer's verdict and the checks. Merge from that panel or on GitHub. Either way the ticket closes, the merge is counted once, and that merged pull request is what Starko bills for.

• A pull request closed without merging costs nothing, and becomes an evaluation case Starko learns from.
• If a later push reverts a merged fix, the run is marked reverted and credited back.
• The ledger shows every run's trigger, outcome, CI state and cost, with merge rate, time to merge and cost per merged pull request.