Skip to main content

Integration

Notes App With GitHub Integration: Check Your Notes Against Your Code

Scribelet's GitHub integration does not sync your notes into a repository. It connects a repository through a GitHub App with read-only code search, so verification can check what a note claims (an endpoint, a flag, a command) against the actual code and propose a diff you accept or dismiss.

Updated 2026-10-27

Setup

  1. Check you have the right access

    You need to be an owner or admin of the Scribelet desk, and have push access (or equivalent) on the GitHub repository so you can install the app or accept an existing installation. On GitHub Enterprise Server, the standard code search API must be available.

  2. Start the connection from Desk Settings

    Open Desk Settings from the sidebar, scroll to Search Connectors and tap Connect GitHub Repository.

  3. Install the GitHub App the first time

    If this is your first GitHub connector on this account, tap First time? Install the GitHub App first. GitHub asks which repositories to grant access to; pick one or more and confirm. If the app is already installed, the Connect GitHub Repository button goes straight to authorization.

  4. Pick the installation and repository

    Back in Scribelet, the GitHub callback screen asks for the installation (your personal account or an organization) and then the repository. Tap Connect Repository. Scribelet creates the connector and runs a quick test query.

  5. Trigger indexing if the test finds nothing

    GitHub's Code Search API only returns results for indexed repositories, and new, small or previously private repos can lag by a few minutes. If the test reports zero results and shows Trigger Indexing on GitHub, tap it, wait a minute or two, then tap Test again in Desk Settings. If it still finds nothing, push a small commit to the default branch and retry.

  6. Opt each note in

    Open a note, tap the kebab menu (three dots) and choose Settings. In Search Connectors, tap + next to the GitHub connector. From then on, verification runs on that note include GitHub code search results alongside its other sources.

4 examples

What you can ask it to do

Prompts and workflows that work once the connection is live.

1.API reference for an internal service

When it fits: Use this for a reference note other teams read instead of the code, where a renamed header or changed limit silently breaks their integration.

API reference for an internal serviceExample 1

Ledger API v2 reference

Owner: payments platform (Mara Okafor). Last reviewed 2026-10-12. Repo: acme/ledger-service.

Create a transfer

POST /v2/transfers

  • Required header: Idempotency-Key (UUID, kept 24 hours)
  • Body: from_account, to_account, amount_minor, currency
  • Returns 201 with the transfer, or 409 if the key was reused with a different body

Limits

  • 120 requests per minute per API key, enforced in RateLimiter
  • Amounts above 50,000.00 USD go to manual review

What verification checks

With the connector linked, verification can search acme/ledger-service for Idempotency-Key, RateLimiter and /v2/transfers. If the handler now reads X-Idempotency-Key, or the limiter constant says 60, it proposes a diff with the code snippet as the source.

2.Runbook with exact commands

When it fits: Use this for an on-call runbook, where a command that no longer exists is discovered at 3 a.m. by the person least able to work around it.

Runbook with exact commandsExample 2

Runbook: rebuild the search index

Service: acme/storefront (Rails). On-call owner: Theo Brandt. Updated 2026-09-30.

When to run

Search returns stale products for more than 15 minutes after a catalog import.

Steps

  1. Put search in read-only: bin/rails search:freeze
  2. Rebuild: bin/rails search:reindex BATCH_SIZE=500
  3. Swap the alias: set SEARCH_INDEX_ALIAS to the new index name and restart the web pods
  4. Unfreeze: bin/rails search:thaw
  5. Spot check three products from the import in the storefront search

Rollback

Point SEARCH_INDEX_ALIAS back to the previous index and restart.

What verification checks

Each command and variable is a searchable identifier. If search:freeze was renamed in a rake file last month, or BATCH_SIZE was replaced by a config setting, a code search finds it and verification suggests the corrected step before the next incident.

3.Architecture decision record

When it fits: Use this for a decision record that states how the system works today, so you notice when the code moves away from the decision without anyone updating it.

Architecture decision recordExample 3

ADR 014: Deduplicate scheduled jobs with Postgres advisory locks

Status: accepted, 2026-09-14. Deciders: Priya Nair, Sam Lindqvist. Repo: acme/workflow-engine.

Context

Two scheduler replicas fired the nightly export twice on 2026-09-02, sending 4,180 duplicate emails.

Decision

Every scheduled job acquires pg_try_advisory_lock in jobs/base.py before running and skips if the lock is held. No Redis dependency for locking.

Consequences

  • One Postgres connection held per running job
  • Jobs must be idempotent anyway; the lock prevents overlap, not retries

What verification checks

The decision names a function and a file. If a newer worker added a Redis lock in jobs/locking.py, verification can surface the snippet and propose updating the status or the decision text, so the record matches what runs.

4.Release notes before they go out

When it fits: Use this for release notes drafted from memory or a ticket list, where a feature described as shipped is still behind a flag or a default changed at the last minute.

Release notes before they go outExample 4

Release notes: Field app 3.8.0 (2026-11-04)

Repo: acme/field-app. Drafted by Lucia Fernández, reviewed by support.

New

  • Offline sync for job sheets, on for all users (flag offline_sync_v2)
  • Photo uploads retry up to 5 times on poor connections

Changed

  • Session timeout raised from 30 to 60 minutes
  • Minimum iOS version is now 17

Fixed

  • Signature pad no longer clears when the screen rotates

What verification checks

Verification can search for offline_sync_v2, the retry count and the session timeout constant. If the flag still defaults to off or the timeout is still 30 in the code, the suggestion arrives before customers read a promise the build does not keep.

This is not a git-synced notebook

Most "notes app with GitHub integration" searches lead to apps that store Markdown files in a Git repository and push and pull on a schedule. That is a storage choice: your notes get version history and live next to your code.

Scribelet's GitHub integration solves a different problem. Notes about code go stale because the code keeps moving. The endpoint gets a new header, a rake task is renamed, a flag that the release notes call "on for everyone" still defaults to off. Nobody edits the note, because nobody notices. The connector gives Scribelet's verification read-only search over a repository you choose, so a note's claims can be checked against the code itself.

If you want both, they combine: keep notes in Scribelet, export to Markdown when you want files in a repo, and let the connector check the notes that describe code.

What happens during verification

Verification reads a note, works out which claims are factual, and searches for evidence. With the GitHub connector linked to the note, that search includes the connected repository's code alongside the web and any other sources the note uses. When the evidence disagrees with the note, you get a proposed change with its sources and a diff, and you apply or dismiss it.

The search goes through GitHub's Code Search API and returns snippets, a few per verification run. That shapes what it is good at. Specific, named things are easy to check: a header name, a CLI flag, a constant, a file path, an environment variable. Broad claims about behavior spread across many files ("retries are idempotent everywhere") are harder to confirm from a handful of snippets, so write the specifics into the note when you can.

Which notes to connect

The connector is added once per desk and then linked note by note, so you choose where it is worth running. Good candidates share one trait: they make statements a reader will act on without opening the code.

  • API references that other teams integrate against.
  • Runbooks with exact commands, variables and file paths.
  • Architecture decisions that say how the system works now, not only why it was chosen.
  • Release notes drafted before the release, from tickets and memory.
  • Onboarding and setup docs that list scripts, ports and config keys.

Meeting notes, brainstorms and journals rarely benefit. There is nothing in the repository to check them against.

Permissions and what Scribelet keeps

The connection uses a GitHub App, not a personal access token. You approve specific repositories, and Scribelet receives short-lived, scoped read access to their code search. It cannot write to repositories, issues, pull requests or wikis, it cannot see private repositories you did not grant to the installation, and it does not clone anything. Access tokens are generated on demand and expire within an hour. The desk configuration stores the installation ID, the repository owner and the repository name, nothing else.

Disconnecting

Remove the connector from Desk Settings > Search Connectors with the trash icon, and it disappears from every note that linked it. Deleting it in Scribelet does not uninstall the GitHub App; to revoke access on GitHub's side, open github.com Settings > Applications > Installed GitHub Apps and narrow the repository list or uninstall the app.

Troubleshooting

  • Test returns zero results and no indexing link appears. The probe query may not match your code. Link the connector to a note, run verification and see whether real queries return results.
  • Authorization lands on an error page. The OAuth state may have expired. Start again from Connect GitHub Repository.
  • The installation picker is empty. The GitHub App is not installed on any account you can access. Use the First time? install link first.

For coding agents that should read and write these same notes, see the Cursor and Claude Code integrations.

Tips

  • Write claims with exact identifiers

    Code search matches text. A note that says SEARCH_INDEX_ALIAS or POST /v2/transfers gives verification something to find; "the alias variable" or "the transfer endpoint" does not. Put names, flags, paths and commands in backticks exactly as they appear in the code.

  • Link only the notes that describe code

    The connector is added once per desk, but each note opts in from its own Settings. Link API references, runbooks, ADRs and release notes. Leave meeting notes and journals unlinked; there is nothing in the repository to check them against.

  • Name the repository in the note

    A line such as Repo: acme/ledger-service at the top tells readers which codebase the note describes and keeps the note honest when a desk has notes about several services.

  • Grant the GitHub App only the repos you need

    When GitHub asks which repositories the app may access, pick the ones your notes describe. You can change that list later under github.com Settings > Applications > Installed GitHub Apps.

  • Use background checks for living documents

    On Pro, background verification re-checks notes on a schedule, so a runbook linked to the connector is compared with the code again periodically, not only when someone remembers to run a check.

In the app

How to do this in Scribelet

  1. Desk Settings > Search Connectors lists the GitHub connector with a Test action, and a trash icon that removes it from the desk and from every note that linked it.

  2. A note's Settings show which connectors it uses; tap + to link the GitHub connector to a runbook or API reference.

  3. When verification finds a mismatch, it proposes a diff with its sources. You accept it or dismiss it; nothing changes in the note until you do.

  4. Pair the connector with the MCP server when you also want a coding agent to read and update the same notes.

Start with the quick start if you are new to Scribelet.

Frequently asked questions

Can I use GitHub for notes?

Yes. Some apps store Markdown notes in a Git repository and sync over Git, which gives you version history and a plain-file copy. Scribelet works differently: notes live in Scribelet, encrypted at rest, and you can export everything to Markdown whenever you want a copy in a repo. Its GitHub connector reads your code to check your notes; it does not store notes in GitHub.

Does Scribelet sync my notes to a GitHub repository?

No. The GitHub App has read-only code search access and cannot write to repositories, issues, pull requests or wikis. If you want notes in Git, export them to Markdown and commit the files yourself.

What can Scribelet see in my repository?

Only code search results for the repositories you granted to the installation. It does not clone the repository; it retrieves per-query snippets, up to a few results per verification run. Access tokens are generated on demand and expire within an hour, and Scribelet stores only the installation ID, repository owner and repository name in the desk configuration. See the GitHub connector guide.

Why does the connector test return zero results?

Usually because GitHub has not indexed the repository yet. Use the Trigger Indexing on GitHub link, wait a minute or two and test again. If no indexing link appears, the generic probe query may simply not match your code; link the connector to a note, run verification and check whether real queries return results.

Do I need a personal access token?

No. The connection goes through a GitHub App: you approve specific repositories, and Scribelet gets short-lived, scoped read access to their code search. There is no token to create, paste or rotate.

How do I disconnect a repository?

Tap the trash icon next to the connector in Desk Settings > Search Connectors; it is removed from every note that linked it. To revoke GitHub's side too, go to github.com Settings > Applications > Installed GitHub Apps and change the Scribelet app's repository list or uninstall it.

Find out which of your docs no longer match the code

Connect a repository, link your runbooks and API references, and let verification compare them with the code. Every change comes to you as a diff to accept or dismiss.

Connect a repository
or get the app
Download on theApp Store

Free plan, no credit card. See pricing

Guide

Note Taking App for Developers: Markdown, MCP and Notes Checked Against Your Code

Developer notes fail in a specific way: they are right on the day they are written and quietly wrong six months later. This page says which tool fits which developer, what belongs in the repo instead, and a setup where notes are Markdown, your coding agent can read and write them over MCP, and runbooks get checked against the actual code.

Integration

Cursor + Scribelet: A Notes Integration for Your Coding Agent

Scribelet runs a hosted MCP server at `https://api.scribelet.app/mcp`. Add it to Cursor's `mcp.json`, approve the desks you want on Scribelet's consent screen, and Cursor's agent can search, read, create and update your notes. The same notes are on the web and your phone.

Integration

Claude Code + Scribelet: Give Your Coding Agent a Notes MCP Server

Scribelet exposes a hosted MCP server at `https://api.scribelet.app/mcp`. One `claude mcp add` command, an OAuth consent screen where you pick the desks, and Claude Code can search your notes, follow their links, read your memories and write new notes. Nothing to run locally.

Docs

Github connector

From the Scribelet docs

Docs

Ai verification

From the Scribelet docs

Engineering

Runbook Template

A runbook is the page someone follows at 3 a.m. with no context. This template gives every step a literal command and the output to expect, and adds the two fields most templates skip: when the procedure was last verified, and what change would make it wrong.

We use cookies for analytics to improve your experience. Learn more