GitHub

GitHub gives Atisbo operational context — it tracks what engineering is shipping, so you can line up customer evidence against changes that actually went out.

GitHub is the one source your agent cannot connect for you. Its setup installs a webhook inside your repository, which is a change to your repo rather than a permission you grant, so it has its own steps below.

Prerequisites

• Admin access to the repository (needed to create webhooks)
• The repository must be on GitHub — not GitLab, Bitbucket, or a self-hosted alternative

Setup

Step 1 — Start in Atisbo

1. Go to Settings → Sources
2. Find the GitHub card and click Connect

Step 2 — Configure the repository

1. Enter the repository as owner/repo (for example: my-company/my-app)
2. Optionally filter by branch (for example: main, develop) — leave it empty to watch all of them
3. Choose which events to watch:
   • Pull requests — PRs merged to main/master
   • Releases — published versions
   • Deployments — deploys to production
   • Deployment status — the result of a deploy, success or failure
   • Pushes — commits (optional; recorded as context only, they never create signals)
4. Turn on auto-detect launches if you want Atisbo to suggest when a Solution has shipped
5. Click Next

Step 3 — Register the webhook in GitHub

1. Atisbo shows two values to copy:
   • A webhook URL
   • A verification secret, shown exactly once — save it now
2. In GitHub, go to your repository → Settings → Webhooks → Add webhook
3. Payload URL: paste the Atisbo URL
4. Content type: application/json
5. Secret: paste the verification secret
6. Under "Which events would you like to trigger this webhook?", choose Let me select individual events and tick:
   • Pull requests
   • Releases
   • Deployments
   • Deployment statuses
   • (optionally) Pushes
7. Click Add webhook

Step 4 — Verify

Push a commit or open a PR. Activity should appear in Atisbo within seconds.

What Atisbo captures

GitHub event	What Atisbo does
PR merged to main/master	Creates a signal with the PR title, description and linked issues
Release published	Creates a signal and looks for related Solutions on the Backlog
Successful deploy to production	Creates a signal and triggers launch detection
Deploy to staging/QA	Recorded as context only — no signal, since users cannot see it yet
Push (any branch)	Recorded as context only — too high volume to be evidence

Automatic launch detection

When Atisbo sees a successful production deploy:

1. It looks for Solutions currently in progress on your Backlog
2. If the deploy's title or description matches one, a banner asks whether it shipped
3. Confirm, and Atisbo marks the Solution as launched and records the date
4. Later, you record what actually happened — success, partial, miss, or unexpected

That closes the loop: customer problem → decision → shipped → measured.

Best practices

• Name PRs and releases clearly. "Fix checkout button on mobile Safari" beats "fix bug #4532" — Atisbo matches deploys to Backlog items by their text
• Publish releases in GitHub when you ship something meaningful; Atisbo picks them up automatically
• Connect the product repo, not every repo. Infrastructure and CI repositories generate volume without product meaning
• Remember what this evidence proves. A deploy tells you what changed, not what anyone needed. It corroborates a problem you already have evidence for; it is not evidence of demand on its own