GitHub

If you write code, you can connect GitHub and then ask Pepper about your repositories, issues and pull requests in the same plain language you use for everything else. Connect it under Settings → Connectors — GitHub is in the Dev group there; one click opens GitHub's own sign-in screen (see Connectors).

Everything below covers the repositories you granted when you installed Pepper's GitHub App — you pick the repos on the install screen, and you can change the set any time at GitHub → Settings → Installations.

What you can ask

• Your repositories. "What repos do I have?", "list my repositories", "do I have anything called pepper-cli?" Pepper reads them from GitHub itself rather than guessing or searching the web.
• What's on your plate. "What's assigned to me?", "what needs my review?", "what's on my GitHub plate?" — issues assigned to you, pull requests waiting on your review, and PRs assigned to you, across the repos you connected.
• The status of one thing. "Did PR #123 land?", "what's the status of the login issue?", "is my PR merged yet?", "how many open issues are there?"
• What shipped. "What merged this week in pepper?", "give me a dev update" — a digest of pull requests merged in a period, what's still open, and the open issues alongside them.
• Making sense of a backlog. "Group my open issues into themes", "what's stale?", "what should I work on?"
• Reading the detail. Pepper can open an individual issue or pull request and read its description, comments, review threads, commits and changed files when answering a question about it.

The GitHub app — your queue, without asking

Asking "what's on my plate?" works, but you shouldn't have to ask. In the web chat there's a GitHub app that keeps that queue in front of you: open it from the grid button next to the message box, or just say "show me my GitHub queue". It has two sections — Waiting on you (reviews you've been asked for) and Assigned to you (issues and PRs with your name on them) — with the longest-waiting items first, each linking out to GitHub. The launcher panel shows the counts on its card, so "is anything waiting?" is a glance rather than a question.

It keeps itself up to date in the background, roughly once an hour, and says when it last checked. There's a Refresh button if you want it now.

If you get a morning brief, the same queue shows up there as a single line — the counts and the item that's been waiting longest — so you see it without opening anything. It's read from what the app last checked rather than fetched fresh, and if that check is too old to trust, the brief says it couldn't check GitHub instead of showing you a stale queue as though it were current.

• Snooze what you're deliberately not doing yet. Any row can be snoozed — three days by default. A snoozed item stays on the page, dimmed and marked, but drops out of the counts and won't be nudged about. This is what stops a review you've consciously deferred from shouting at you every morning.

• Turn a row into a to-do. Each row has a → todo button that puts it on your to-do list, titled with the repo, number and title and linking back to GitHub. Once it's on your list the button becomes Added ↗, a link to that to-do, and it stays one when you reload. Clicking it twice won't make two — you get the one you already had. Nothing is added automatically; it's there for the times you want the item somewhere other than this page. See Todos.

• Tick a row off when you're done with it. Each row has a checkbox that takes the item off your plate for good — out of the counts, out of the nudge, out of the morning brief, and out of the queue. Unlike a snooze, which is "not now" and comes back, this one sticks: a later check finding the item again won't put it back. It returns only if GitHub gives you a genuinely new reason to look, like a fresh review request. Ticked rows collect under Done at the bottom of the page, where you can untick one if you changed your mind.

• An item Pepper has stopped seeing says so rather than vanishing. GitHub's search occasionally stops returning something that's still open — the same query, minutes apart, with nothing about the item changed. Pepper no longer takes that as "it's finished": the row stays on your queue for a couple of days, marked unconfirmed and labelled "last confirmed 3 days ago", so you can see it's being held rather than freshly checked. If it really is finished, tick it off; if the search recovers, the label clears on its own. The one thing that would be worse than showing you a stale row is quietly deleting a live one, and this is the side that error falls on.

• Draft pull requests are dimmed and never counted as waiting on you, because they aren't yet.

• The app's settings (on the page itself) hold a few things: how many days count as stale (two by default), how long an item Pepper has stopped seeing is held before it drops off (also two days, and a separate setting — changing how quickly things count as stale shouldn't quietly change what disappears), which repos are yours to review, and the daily nudge below.

  "Repos that are yours to review" means the ones where every open PR is effectively waiting on you even when nobody formally requests a review — Pepper can't work that out reliably from GitHub, so you tell it. There's a checkbox, "My own repositories are mine to review", that's on by default and covers everything under your own account, and a box below it for anything else. Entries there can be a single repo (someone/their-project) or a whole account with a * (some-org/*); a partial name like some-org/pep* isn't supported. In a repo you've marked this way, issues other people filed count too — not just pull requests.

• See what you actually granted. The app's settings show an Access block listing what your GitHub install can reach: each account, and either "all repositories" or the named list, with a link out to manage it. This is the difference between "you're all caught up" and "nothing is granted yet" — when Pepper can see that no repositories are shared with it, the app says so plainly and points you at the fix instead of quietly showing an empty, cheerful queue.

The daily nudge

Pepper can send you one message a day about reviews that have gone stale — "PR #212 has been waiting on your review for 3 days" — on whichever channel it normally messages you. It's off until you turn it on, in the app's settings, and it's deliberately quiet when it is on: one message a day at most, batching every newly-stale item rather than one message per PR, and each item is only mentioned once rather than every day. Snoozed items, ticked-off items and drafts are skipped.

What it can change

Pepper takes GitHub actions you explicitly ask for, and only those:

• File an issue. "File an issue in pepper that the calendar duplicate-check is missing all-day events." Pepper writes it up and creates it in the repo you name.
• Comment, label, and similar. Ask directly and Pepper will do it.

Writing code isn't the job: Pepper's GitHub routines are built to read, file issues, and comment — not to open or merge pull requests, push files, or create branches — so none of that is something it volunteers or plans around, and it isn't a supported, reliable way to get code changes made. And it won't repeat a write it isn't sure about — if a result comes back ambiguous, Pepper checks by reading rather than posting a second time.

In a channel

A channel's owner can connect the room to GitHub from the room's info page, choosing which repositories it covers. In an email or group-text thread, which has no owner, anyone in the thread can connect it, and anyone in the room can disconnect it again; the room is told who did. Connecting is not the same as switching reading on: Pepper's reading of connected repositories is rolling out gradually and may not be available in your channel yet, so if Pepper says it can't read GitHub there, that is why. Where it is available, anyone in the channel can ask Pepper about an issue or pull request in those repositories, for example "what does #123 say?", "what's open on the API repo?" or "find the login crash issue". Pepper reads them, body text included.

Changes work differently. If you have connected your own GitHub account (Settings → Connectors), you can ask Pepper in the channel to comment on an issue or pull request, add or remove an existing label, close or reopen it, or request a review, and it does so as you: it shows on GitHub as your own action, with your own permissions, and only in the repositories the channel connected. Without your own connection Pepper tells you to connect one and does nothing; it never makes the change through the channel's connection. It can't merge, create issues or touch other repositories from a channel (a channel set up to file bug reports, below, is the one exception), and someone who isn't signed up to Pepper can read but not change anything.

An owner can also limit a connected repository to one label from the same page. The channel then sees only the issues carrying that label, and the pull requests that close them. Anything else in that repository gets no preview, and if you ask Pepper about it, it says the item isn't visible to this channel and tells you nothing else about it. Pepper's changes follow the same limit: it won't comment on, label, close or request a review of something the channel can't see. Previews posted before a label was set stay where they are.

A channel's owner (or anyone in an email or group-text thread) can also let Pepper file bug reports for the room, for people who have no access to the repository, such as a beta-testers channel. Where that is switched on, you tell Pepper about a problem and it files a GitHub issue for you as the Vycari app, with your name in the text ("Reported by Dana in Pepper Beta Testers"), and it tells you it will before it does. It first looks for a similar open issue the channel can see and adds your report there instead if it finds one; if the only similar issue is one the channel can't see, it tells you the problem may already be reported and files only if you still want it. It can add to an issue the channel reported, but it can't close, label or reopen anything — and in a channel set up this way, the changes-as-you described above aren't offered either, even if you've connected your own GitHub account. It files at most ten issues a day per channel, and you need a Pepper account to use it: someone reading through a linked address is asked to have a member with an account report it, or to sign up.

What to know before you ask: Pepper reads through the channel's connection, not through your own GitHub account. Everyone in the channel can see what it reads, including people who couldn't open that repository on GitHub, so only connect repositories you are happy to share with the whole channel. Pepper only looks in the repositories the channel connected, and it stops the moment an owner disconnects one. If GitHub itself takes access away (the app is uninstalled or suspended, or a repository is dropped from it), Pepper stops the same way, removes the previews it posted, and posts a line in the channel saying which repositories it can no longer see. When a channel is deleted, its GitHub connection ends with it. When a list or search can't cover everything it checked, it says which repositories or how many items it covered.

One account at a time

One GitHub account connects at a time. If none is connected, Pepper says so and points you at settings rather than guessing.

Good to know

• "Not found" usually means "not granted." If Pepper says it can't see a repo, PR or issue you know exists, the repository almost certainly isn't in your install's repo set. The Access block in the GitHub app's settings shows exactly what is shared, so you can check rather than guess; add what's missing at GitHub → Settings → Installations. For an organization's repos, the App has to be installed on the org — an org admin approves that install.
• An organization can block Pepper outright, and it says so. Separately from which repos you granted, an organization can restrict which apps its members may authorize at all. Until an org admin approves Pepper there, a search that touches that org's repos doesn't come back short — it fails. You approve it at GitHub → Settings → Applications → Pepper → Organization access, where you can request approval if you're not an admin. When this happens mid-answer, Pepper tells you which part of the check failed and why, rather than handing you the half it could see as though it were the whole list — a plate that quietly lost its issues looks exactly like a quiet day.
• Counts on large repos are careful, not clever. For "how many open issues", Pepper reports a real total where GitHub gives it one, and says "at least N" when it's only seen the first page — rather than eyeballing a long list.
• Related skills. Several of Pepper's routines use GitHub when it's connected: Find todos sweeps your assignments and review requests for action items and, the other direction, checks your existing to-dos against what's actually closed, and Get to know me reads it as part of building your profile. See Skills.