SherlockAn investigator, not a code generator
Sherlock treats every bug like a case: reproduce it, gather context, fix it, prove the fix, file the paperwork.
One comment starts the case
Sherlock lives where your bugs live. A maintainer comments /sherlock investigate on any GitHub issue, and the investigation is queued.
- Permissions are checked against the GitHub API — only users with write access or higher can trigger a run.
- Bot comments are ignored; installs are rate-limited so a noisy repo can't burn your budget.
- Sherlock replies on the issue with a queued status, then keeps its progress visible.
If it can't reproduce the bug, it stops
Sherlock boots your application inside a sandboxed container and drives it with a real browser, following the issue report until the failure is observed.
- The reproduction is stored as a deterministic script — the same steps can be replayed at any time.
- No reproduction, no patch. Sherlock reports back on the issue instead of guessing.
- Browser traces are captured so you can watch what it saw.
A map of the repo, built before the search starts
Graphify indexes files, functions, and the relationships between them into a queryable graph. Investigations walk the graph from symptom to cause instead of grepping and hoping.
- Focused context: only code reachable from the failure enters scope.
- Deterministic slice: the same issue maps to the same neighborhood.
- Shipped with the PR so reviewers see the reasoning surface.
The bug that was caught is the test that must pass
Verification is a replay, not a review. The exact reproduction that demonstrated the bug runs against the patched application. A model's opinion never decides the outcome.
PRs that pass carry the Verified badge. PRs that don't pass don't carry it — and Sherlock says so on the issue.
A reviewable PR with its evidence attached
Diff, investigation log, browser trace, graph context, and the verification result — everything a reviewer needs to say yes with confidence.