For the complete documentation index, see llms.txt. This page is also available as Markdown.

GitHub

What this is

GitHub is a Hookshot™ integration that connects your GitHub organization or repository to Hookshot. GitHub commonly serves as a source of issue and repository activity and as a workflow input for triage, routing, and review.

When to use it

  • When GitHub events should start a Protege

  • When a Protege needs to read GitHub context or take an action tied to GitHub data

  • When you want to triage, route, or review GitHub issues and pull requests automatically

What you need first

  • Access to the GitHub organization, repository, or account you want to connect

  • Permission to approve the connection

  • A clear repo or project boundary for the automation

Steps

1. Connect GitHub

  1. Open Integrations.

  2. Select GitHub.

  3. Complete the connection flow.

  4. Confirm the connection is active.

2. Review Trigger Access

Use Trigger Access when GitHub events should start the Protege.

Examples:

  • New issue activity

  • Selected repository events

Confirm the trigger source points to the intended repo or project boundary.

3. Review Tool Access

Use Tool Access when the Protege should read GitHub context or take an action tied to GitHub data or results derived from it.

Examples:

  • Read issue context

  • Read pull request context

  • Support triage or routing workflows

  • Feed a downstream action in another system

If the Protege should only operate on one repo, keep the connection boundary as narrow as possible.

4. Review permissions

Review the GitHub consent screen and allow only what your workflow needs. In practice, Hookshot™ needs permission to:

  • Read the GitHub objects that should activate the workflow

  • Access enough repository context for the Protege to make the intended decision

If the Protege should only operate on one repo or one team workflow, keep the connection boundary as narrow as possible.

How to verify

  • Confirm GitHub is connected

  • Confirm the intended trigger source is live

  • Trigger a safe test event in the intended repo boundary

  • Confirm the event appears in Event Feed

  • Confirm the corresponding run appears in Audit

Common failures

  • Connecting the wrong repo or account

  • Treating a repo-level workflow like an org-wide workflow

  • Forgetting to validate the exact event type that should activate the Protege

  • Event Feed shows the event but the Protege is skipped — review the Protege description and readiness

Next step

Last updated

Was this helpful?