Appearance
Ask Lore in a pull request
The GitHub App's bot identity is @buildwithlore[bot]. Lore also recognizes the literal @lore alias in subscribed comment events. Use the bot identity to avoid mentioning an unrelated GitHub user. There is no separate GitHub “app mention” event: Lore receives ordinary PR conversation and review-comment webhooks.
| Comment | Response |
|---|---|
@buildwithlore[bot] why does this client use this library? | Supported rationale and tradeoffs with source links. |
@buildwithlore[bot] on a changed line | Explanation of the selected diff at its recorded revision, with outdated lines identified. |
@buildwithlore[bot] in the main PR conversation | PR purpose, significant changes, affected components, and historical context. |
@buildwithlore[bot] retrospective | Draft covering what happened, contributing factors, fix, lessons, and missing evidence. |
You must be a repository collaborator. Bot comments, quoted mentions, and code examples do not trigger answers. Lore rechecks the requesting comment and repository visibility before publishing. Editing the request updates its answer; deleting the requesting comment removes Lore's answer. Webhook retries reuse the existing reply.
Answers use evidence from the PR's repository. They do not reveal private dependencies, personal Linear connections, or Sentry content to the PR audience. Unsupported claims must be labeled as inferences, and unknown incident impact or chronology stays unknown.
An answer consumes one workspace invocation. No manual knowledge review is required.
For operators: enable issue_comment and pull_request_review_comment webhook events, with Pull requests read and write, in addition to repository ingestion permissions. AI synthesis uses the worker's configured Anthropic key only when workspace AI classification is enabled; otherwise Lore returns source excerpts with an explicit synthesis-unavailable notice. Failures retry up to four attempts; failed requests remain in github_reply_jobs for diagnosis.