Docs / Set up your org

GitHub integration

Each service can be connected to a GitHub repository so REEZN can ground its analysis and canvases in your actual code, naming the concepts that already exist instead of reasoning in the abstract.

The connection is set per service, on the service itself: a repository in org/name form plus an optional read-only token. Both are optional, and both are admin-only, since services live in project settings, which only an org admin can change.

Connecting a repository

You connect a repo wherever you edit a service: in the new-project form when you first add the service, or later from Project settings → Services. Each service carries two fields for this:

Repository: The repo in org/name form, for example billing-team/billing-api. The field is prefixed with github.com/, so you enter only the owner and repo name, not the full URL. Optional.
GitHub token: A read-only personal access token granting access to that repo. The field is masked as you type. Optional for a public repository; required for a private one, since REEZN can’t read a private repo without it.

Open the service, during project creation or later in Project settings → Services.
In the Repository field, enter the repo as org/name (it is prefixed with github.com/, so leave out that part and the rest of the URL).
If the repo is private, add a read-only GitHub token that grants access to it. For a public repo you can leave the token blank.
Save the service. From then on, that repo is read whenever an analysis or canvas is generated for the service.

Repository and token are both optional, and they’re set independently per service, so one service in a project can be connected while another isn’t. A service with no repo still generates plans normally; it just won’t have your existing code as context.

What gets read, and when

The repo is read at generation time, not when you save the service. When a feature’s analysis or canvas is generated, REEZN reads the connected repo of each service the feature touches, working from the default branch, and explores the parts of the codebase relevant to the feature at hand rather than treating every repository the same way.

That understanding is carried into the same generation that already has your definition, norms, and safeguards in hand, for both the analysis and each service’s canvas. A connected repo genuinely shapes the plan; it is not a field that is merely stored and ignored.

REEZN reads your code to plan against it and nothing more. It does not copy your repository into REEZN, and a read-only token is all it needs.

What the code context does for your plans

With a repo connected, the analysis can identify the domain concepts that already exist in your codebase, and the canvas can model real entities, components, and dependencies by their actual names, so the plan extends what you’ve built instead of describing something generic. Without a repo, generation falls back to reasoning from your definition, norms, and safeguards alone.

If a repo can’t be read (a wrong name, a private repo with no token or an invalid one, or GitHub being unreachable), REEZN doesn’t fail the feature. It quietly skips that repo’s context and generates from everything else, so a misconfigured connection degrades gracefully rather than blocking the workflow.

Why this exists

This token is read-only by design: to plan against your code, REEZN only ever needs to read it. Writing to a repository happens solely through implementation on the Business plan, which is opt-in and takes its own separate write-scoped token, so nothing you connect for planning can ever push a commit. Grounding the plan in your real codebase is what keeps new work fitting the conventions and concepts you already have rather than cutting against them, but it is strictly optional, so a team can adopt REEZN without wiring up repo access first and add it where it pays off. Grant the least access the token needs, and nothing more.