GitHub App setup

Install

The hosted deployment uses the GitHub App slug gittensory. Start from the GitHub App install flow, then choose only the repositories you want Gittensory to see.

1. Open the install flow and pick the owning account.
2. Choose selected repositories instead of all repositories unless you are onboarding an org.
3. Approve Metadata: read, Pull requests: read, and Issues: write. Enable Checks: write when Context or Gate check runs are enabled.
4. Keep webhook events enabled for issues, issue_comment, pull_request, and repository.

First 10 minutes

1. Install the app on one test repository first.
2. Confirm the installation appears in the private API, then open its health record.

   GET /v1/installations
   GET /v1/installations/:id/health
   GET /v1/installations/:id/repair

   http
3. Check repo readiness before enabling public output.

   GET /v1/repos/:owner/:repo/registration-readiness

   http
4. Preview the exact public surface without posting to GitHub.

   POST /v1/repos/:owner/:repo/settings-preview
   # body: sample PR fields + desired comment/check/gate settings

   http
5. Leave Gittensory Context advisory while you tune copy and settings. Make Gittensory Gate required only after the repo explicitly enables blocking rules.

Default posture

Gittensory is advisory-first. Public comments, labels, the Context check, and the Gate check are controlled per repo. Missing issue links, non-Gittensor contributors, busy queues, and weak overlap signals do not block merge by default.

PR panel

The PR panel is one sticky bot comment that updates in place. It shows a public-safe readiness score, concrete signal evidence, and short actions for linked issues, related work, review load, validation evidence, open PR queue, contributor context, and Gate result.

Checks

Gittensory Context is advisory and should not be required in branch protection. Gittensory Gate is opt-in and can be made required after a repo owner chooses blocking rules.

Branch protection should require Gittensory Gate only after the repo has verified installation health, previewed the public panel, and configured at least one block rule. Do not require Gittensory Context; it is there to inform reviewers, not stop merges.

Gate modes

Each Gate rule supports off, advisory, or block. Linked issue, duplicate PR, and quality-score checks default to advisory. The quality rule only blocks when qualityGateMode is block and aqualityGateMinScore threshold is configured.

Dogfood mode

For repos like JSONbored/gittensory and awesome-claude, enable PR comments, labels, Context, and Gate together to test the full product surface. If another maintainer agent can merge quickly, configure that agent to wait for Gittensory Gate before merge or close.

Install diagnostics

After installing, verify your install health from the API. The readiness endpoint separates service health from data quality.

If the install route changes, check the deployed GITHUB_APP_SLUG before publishing setup copy. For the hosted app, the expected slug is gittensory.

New maintainers should continue with Maintainer workflow or the beta onboarding checklist after the health endpoint reports clean permissions and events.