GitHub

Your customers file issues and your product is already written down, in code. Squad reads new issues as feedback on their own, reads a repository into your knowledge base so it knows what you have built, and an agent can start when an issue opens or a pull request merges, read either one, and write back an issue or a comment.

​

Connect

That repository choice is the whole of Squad’s access. To change it later, manage the Squad installation in your GitHub settings rather than reconnecting in Squad.

​

Disconnect

Click Manage on the GitHub card, scroll to Danger Zone at the bottom of the page, and click Disconnect. Triggers stop, agents lose the GitHub tools, and the card drops out of Connected back into Discover. The reverse direction works too. Uninstalling the Squad app from GitHub disconnects the integration here, with the same drop back into Discover, a plain Connect button and no other warning. Click it to install again. If Connect fails with an error before GitHub’s install screen opens, Squad’s own GitHub credentials are misconfigured. Contact support.

​

Getting issues into your feedback

Switch on the GitHub issues workflow from the By Squad tab on the Agents page. An issue in the repositories you scope it to is captured with its comment thread, turned into signals, and logged whether it captured, skipped or failed. No agent is involved. Capture happens when an issue is opened and when it is reopened. So a three-year-old issue joins the moment someone reopens it, comment thread and all. Comments alone do not bring one in. Leave the repository list empty for every repository the install covers. Pull requests bring in nothing. They are things an agent reads and writes on demand.

​

Reading a repository into your knowledge base

Switch on the Repo scan workflow and pick one repository. Squad reads it and writes up what the product does, as knowledge documents filed alongside everything else you know: a document per capability, plus a product overview, a glossary and what the product integrates with. The documents are written in product language rather than engineering language. Squad records which file and commit each part was written from, which is what lets it spot the parts a later change has made wrong. It scans once, when you install it. One repository per scan, so a workspace with three repositories runs three, each named and paused on its own. After that it keeps up. When a pull request merges into the repository’s default branch, Squad compares what changed against the files your documents were written from and flags the parts that are now suspect. Rewriting them happens overnight, or now if you click Refresh. Only the flagged parts are touched, so a merge that changed nothing any document cited costs nothing and lands in the history as a skip. The workflow page carries a Freshness row. It reads Up to date, or names how many documents may be out of date, and Refresh appears in the header when there is something to do. Rename the repository on GitHub and none of this breaks. Freshness is tracked by GitHub’s own repository id rather than by owner/repo, so the scan follows the rename instead of reporting everything as current from then on. Delete one of those files and the next refresh clears the citation rather than leaving it flagged. Your paragraph stays. The document stops being counted as out of date, instead of sitting there asking for work nobody can do. A merge into a branch other than the default one leaves the documents alone, because code that has not shipped should not change what the documents say your product does. The Pull request merged trigger is a separate thing and fires on merges into any branch, so an agent watching a release branch still runs.

​

Triggers

• Issue opened. An issue is opened in an installed repository.
• Pull request merged. A pull request is merged in an installed repository, into any branch. A merge into a release branch or a feature branch starts an agent just as a merge into main does.

Both fire across every repository in the installation. Closed issues, opened pull requests and review comments are not triggers.

​

Tools

​

A worked example

Build an agent triggered on Issue opened. It reads the issue, checks the description against recent signals to see whether customers have hit the same thing, and comments with how many customers, how recently, and which insight it belongs to. Engineering gets the demand context on the issue itself, before anyone picks it up.

​

Limits

Squad reads issues, pull requests, and repository files during a scan or a refresh. Agents read issues and pull requests only: there is no tool that reads code on demand, so what Squad knows about your codebase is what the last scan or refresh wrote down. The two triggers are the only GitHub events available to an agent. Repository access is set in the GitHub install, not in Squad. The issues workflow starts from the moment you switch it on and nothing before that is backfilled in bulk. An older issue still comes in when someone reopens it. Discussions and releases have no workflow. A repo scan corrects what changed. It does not notice what is new. Staleness is worked out from the files your documents were already written from, so a capability added in a package that did not exist when the scan ran has nothing pointing at it and no merge will flag it. Use Scan the whole repository again, in the workflow’s overflow menu, after a release that added a substantial new area. That one asks you to confirm before it starts, because a full re-read costs what the first scan cost and the page looks identical while it works. While a scan or a refresh is running, both actions are disabled, so a second click cannot queue a second run.