Docs

How Sherlock works

From installing the GitHub App to reviewing your first verified pull request.

Quickstart

Install the Sherlock GitHub App on the repositories you want covered. Installation takes about a minute and requires no code changes, CI configuration, or SDK.

1. Install the GitHub App → select repositories

2. Open any bug issue

3. Comment /sherlock investigate

4. Review the PR when it arrives

Requirement: your app needs a way to run in a container — a Dockerfile or a standard build. Sherlock detects common setups automatically; anything unusual can be configured per repo.

Triggering an investigation

Sherlock listens for the exact comment /sherlock investigate on an issue. When it sees one, it verifies the commenter's repository role against the GitHub API — write, maintain, or admin is required. Bot users are ignored. Webhook payload permissions are never trusted; the role is always resolved through an installation-authenticated API call.

Accepted commands are queued as jobs and processed by isolated workers, so a burst of triggers never blocks GitHub webhook handling. Sherlock replies on the issue when the investigation is queued, and again with results.

The pipeline

Every investigation moves through five stages:

reproduce — boot the app in a sandbox, drive a real browser, record a replayable script that demonstrates the failure

map — query the Graphify repo graph for files, functions, and relationships reachable from the failure

patch — draft a minimal change against the mapped code paths

verify — rebuild with the patch and replay the saved reproduction in a fresh sandbox

deliver — open a PR with the diff and all artifacts attached

The stages are strictly ordered: a patch is never drafted before a reproduction exists, and the Verified badge is never applied unless the replay passed.

Artifacts

Every run produces an inspectable evidence set:

investigation.logtimestamped record of every stage, decision, and command

reproduction scriptthe deterministic browser script that triggers the bug

trace.zipbrowser traces from reproduction and verification runs

graph-context.jsonthe Graphify slice the investigation worked from

pull requestthe patch, linked to the issue, with the verification result

Outcomes

An investigation ends in one of three states, all reported on the issue:

verified pr — the replay passed against the patched build; PR carries the Verified badge

draft pr — a plausible patch exists but verification didn't pass; shipped as a draft, clearly labeled

no reproduction — the bug couldn't be reproduced; you get the attempt log and what was tried

Sherlock never dresses up an unverified fix as a verified one. The badge is backed by an execution result you can re-run.

Limits & controls

Installations have configurable rate limits on concurrent and daily investigations. Repository access is controlled entirely through the GitHub App installation — uninstalling revokes everything instantly. For self-hosted workers, quotas, network policy, and image allowlists are under your control. See Security for the full model.

Book a demo Product overview