GitHub App setup

Once installed, the gittensory app reviews every pull request on the repos you select. Each review produces two surfaces: the Gittensory Gate check run (and the advisory Gittensory Context check), and a single review comment posted by gittensory[bot] that updates in place as the PR evolves. Everything on this page configures that review.

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 the review comment the gittensory app posts on each pull request. It is one sticky comment authored by gittensory[bot] that updates in place — the app edits the same comment instead of adding new ones. 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.

By default the comment is posted only to detected contributors (commentMode is detected_contributors_only). Set commentMode to all_prs to comment on every PR, or off to suppress the comment entirely. Operators who have rolled the deployment onto the unified review comment (see below) get the single in-place comment shape; otherwise the legacy multi-panel comment is used unchanged.

Checks

The gittensory app publishes its review as check runs. Gittensory Gate is the gate result; Gittensory Context is the advisory companion. Both are controlled per repo by checkRunMode (off / enabled), with checkRunDetailLevel choosing minimal, standard, or deep output.

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

The deterministic gate is the heart of the gittensory review. Its master switch is gateCheckMode (off / enabled); each dimension then refines an already-enabled gate with a tri-state mode — off (not evaluated), advisory (surfaced, never blocks), or block (can become a hard Gittensory Gate blocker). Blocking is always confirmed-contributor-gated: the mode chooses which deterministic checks are active, never who can be blocked.

• linkedIssueGateMode — linked-issue check. Default advisory.
• duplicatePrGateMode — duplicate / superseding PR detection. Default block.
• qualityGateMode + qualityGateMinScore — the PR-quality score gate. Default advisory; only blocks when set to block with a configured min score.
• slopGateMode + slopGateMinScore — the deterministic anti-slop signal. Default off; advisory surfaces the slop score and warnings, block also hard-blocks at or above the min score (engine default band 60).
• mergeReadinessGateMode — composite merge-readiness gate. Default off.
• manifestPolicyGateMode — makes the repo manifest's declared policy (blocked paths, required linked issue, test expectations) enforceable. Default off.
• aiReviewMode — AI review. Default off; advisory posts AI review notes only, block lets a dual-model high-confidence consensus defect become a blocker (confirmed contributors only).

The policy pack (gatePack) selects which rule set runs: gittensor (confirmed-contributor-gated, registry-aware) or oss-anti-slop (the deterministic rules against any author on any repo). Enable firstTimeContributorGrace to soften a would-be block to advisory for a genuine newcomer.

Configure as code (.gittensory.yml)

Every setting can be committed to .gittensory.yml at the repo root instead of, or layered over, the dashboard. Precedence is .gittensory.yml > repository settings > safe defaults; an unset field falls back to the next layer. It only chooses what Gittensory does — only confirmed Gittensor contributors are ever hard-blocked, regardless of config.

# Repository settings as code — any dashboard toggle:
settings:
  gateCheckMode: enabled        # the Gate on/off
  checkRunMode: enabled         # the advisory Context check on/off
  commentMode: detected_contributors_only
  publicSurface: comment_only

# Friendly gate alias (wins over settings: for gate fields):
gate:
  enabled: true                 # Gate on/off
  linkedIssue: advisory         # block | advisory | off
  duplicates: block
  readiness: { mode: advisory, minScore: 60 }

# Public review-panel content:
review:
  footer: { text: "Reviewed by our bot." }   # custom lead — the Gittensor register link is always appended
  note: "Run npm test before requesting review."
  fields: { relatedWork: false }              # show/hide individual panel rows

Maintainer-supplied footer and note text is dropped if it contains forbidden public language (reward, score, wallet, hotkey, payout, etc.); the Gittensor attribution and register link always remain on the footer.

The per-repo settings above choose what Gittensory does on each PR. The next section covers the deployment-wide capability switches that turn whole review features on or off.

Review capability flags (GITTENSORY_REVIEW_*)

Beyond per-repo settings, operators turn whole review capabilities on or off with the GITTENSORY_REVIEW_* worker environment variables. Every flag defaults to OFF: when a flag is off its code path is inert and the review behaves exactly as if the feature did not exist. "Truthy" is one of 1, true, yes, or on. You roll capabilities forward — and back — one flag, and one repo, at a time.

• GITTENSORY_REVIEW_REPOS — per-repo cutover allowlist. Comma-separated owner/repo names that may run the per-PR features. Add repos one at a time to roll forward; remove to roll back.
• GITTENSORY_REVIEW_SAFETY — safety scan: defangs untrusted PR title/body/diff (prompt-injection neutralization) before the reviewer sees it, and surfaces a secret_leak blocker for leaked secrets in the diff. Per-PR.
• GITTENSORY_REVIEW_GROUNDING — grounds the AI reviewer with the PR's finished CI status and the full post-change content of the changed files, so the model verifies its claims against reality. Per-PR.
• GITTENSORY_REVIEW_RAG — retrieval-augmented context: appends semantically related code/docs from the codebase vector index to the reviewer prompt. Per-PR; inert until a VECTORIZE index exists for the repo.
• GITTENSORY_REVIEW_REPUTATION — submitter-reputation spend control: downgrades a new / burst / low-reputation submitter to a deterministic-only review. Internal-only, never surfaced publicly. Per-PR.
• GITTENSORY_REVIEW_UNIFIED_COMMENT — renders the public PR comment as one in-place unified comment instead of the legacy multi-panel comment. Per-PR; flag-off keeps the legacy comment byte-identical.
• GITTENSORY_REVIEW_OPS — read-only observability: a cron anomaly scan over your own review-outcome data plus a bearer-gated stats aggregate. Global (not scoped by the repo allowlist).
• GITTENSORY_REVIEW_SELFTUNE — self-improvement loop that computes tuning recommendations from review outcomes, shadow-soaks any strictly-tightening recommendation, and can only ever tighten the gate. Global.
• GITTENSORY_REVIEW_CONTENT_LANE — routes content repos (curated lists, registries) through the dedicated content lane instead of the code gate. Global.
• GITTENSORY_REVIEW_DRAFT — public draft-submission flow (contributor draft → GitHub OAuth → fork PR). Global; also needs the draft secrets set.

A safe rollout for a per-PR feature is two flips: set the capability flag truthy, then add the repo to GITTENSORY_REVIEW_REPOS. Because both must hold, a capability can stay globally enabled while remaining dormant everywhere except the repos you have explicitly added.

# Roll grounding + the unified comment onto one repo:
GITTENSORY_REVIEW_GROUNDING="true"
GITTENSORY_REVIEW_UNIFIED_COMMENT="true"
GITTENSORY_REVIEW_REPOS="JSONbored/gittensory"

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.