Features / Capture & fix
Tore for GitHubAI investigations
It reads your code, not just the ticket
Connect your repository and Tore works from the code as it is right now, the file that threw, the commit that last touched those lines, the callers around it. Not a snapshot it memorized months ago, and not a guess from the ticket text.
TRIAGEIs this worth opening at all?
Without it
The expensive part is not the fix, it is finding the cause
The afternoon goes before you have had a thought
Read the ticket. Find the file. Read the commit that touched it. Read the three callers. Check what shipped on Tuesday. Only then do you start actually thinking about the bug, and it is now 4pm.
The AI is confidently describing code you deleted
You paste a stack trace into a chat window and get a fluent answer about a function signature you changed two months ago. It reads well. It is about a repository that no longer exists.
A conclusion you cannot check is worth nothing
“The bug is probably in the payment retry logic” is not a finding, it is a hunch with good grammar. You still have to go and look, so you have saved nothing and now you are also arguing with a machine.
How it works
Connect the repository through a GitHub app you install
Read-only on contents. You choose which repositories it can see, and you can revoke the install in one click. Nothing on your repository is written until a change is opened for your approval.
It reads the code as it is right now
The file that threw, the commit that last touched those lines, the callers around it, at the commit being investigated. The bytes it reads are checked against the hash they claim to come from, so it is not reasoning about a version it half remembers.
What that includes
- The file that threw
- the callers around it
- at the commit being investigated
It works in visible stages, not one black box
Triage, then gathering context, then investigating, then a proposal. Each stage records what it pulled: the release, the mapping file, the surrounding commits, the affected devices or sessions, the stack frames it resolved.
What that includes
- the mapping file
- the surrounding commits
- the affected devices or sessions
- the stack frames it resolved
It shows you what it looked at, not just what it decided
The evidence sits next to the conclusion. The resolved stack trace with real file and line numbers, the payload it reproduced against, the diff it is proposing, and the reasoning that connects them.
What that includes
- line numbers
- the payload it reproduced against
- the diff it is proposing
- the reasoning that connects them
Dangerous ground escalates instead of proposing
Authentication, billing, database migrations, secrets, and tenant isolation are a locked registry. A path that lands in one of them stops and goes to a person, and a path it cannot classify at all also stops.
What that includes
- Authentication
- database migrations
- secrets
What it means for you
You start at the diagnosis instead of the search.
The repetitive part, find the file, read the history, understand the shape, is done before anyone interrupts you. What lands on your desk is a decision, not a scavenger hunt.
You can check its work in about a minute
Because it lists what it read, disagreeing with it is fast. You look at the same three artifacts it looked at and either accept the finding or see immediately where it went wrong.
Your code stays yours
It is read to answer one question, at one commit, and is not retained to train a model, ours or anyone else’s.
The honest limit: It investigates what is in the repository. When the real cause is outside the code (a config value, a queue backing up, a vendor having a bad hour), it can show you the evidence and narrow the ground, but it will not hand you a line to fix, because there is not one.