Repositories · Genosyn Docs

What a Repository is

Every Repository is a plain git repository. Two fields decide how it behaves, and you set both when you create it:

Find them under Repositories in the section menu. Nothing here is limited to engineers, and nothing here requires a git host, an account on one, or coding tools switched on.

Create a repository

  1. Open Repositories from the section menu, choose Add repository, give it a name, and choose whether it is local — created here and never pushed anywhere — or a clone of a repository that already exists.
  2. For a remote repository, paste the clone URL — https://github.com/acme/web.git or git@github.com:acme/web.git — and pick an authentication mode. Set the default branch and, optionally, a committer identity; left blank, commits are committed as Genosyn.
  3. Open the repository. For a remote one, Test connection confirms Genosyn can reach it and detects the default branch, using the stored token or SSH key, else a pinned or sole Connection for that server, else anonymous access.

A local repository is created with git init on the default branch you chose, plus one empty commit, so there is a revision to branch from and diff against before you write your first file. It has no remote and uses no authentication — until you connect one.

Connect a local repository to a git host

A repository that started life inside Genosyn can be given a real remote later, and its existing history is pushed into it rather than re-created. Nobody pastes a personal access token for this: the company authenticated GitHub once under Settings → Integrations, and connecting reuses that Connection.

  1. Pick one of the company's connected GitHub or Forgejo / Gitea Connections — each option names its server and the account it authenticates as — then give the repository a name there, optionally an organisation to own it, and choose private (the default) or public.
  2. Genosyn creates it through that server's API — empty, so the first push is a clean fast-forward — and pushes the history into it. Every branch goes across except the AI work-session ones under genosyn/: unreviewed AI work must not reach a remote through a button that says nothing about AI.

The other route is to paste the clone URL of an empty repository you made yourself, anywhere, and let Genosyn push into that. An HTTPS URL on a server the company has connected authenticates through that Connection; for any other host you can supply an HTTPS token or an SSH key in the same step, stored encrypted exactly as on a cloned repository. A remote that already has commits is refused with an explanation rather than force-pushed. Afterwards push, pull, and refresh behave exactly as they do for a repository that was cloned. Connecting is owner or admin only, for the same reason pushing is, and it is written to the audit log.

The Overview: what the AI has been doing

Opening a repository lands on its Overview, and the subject of that page is the work rather than the settings. It opens with one sentence about the state of AI work here — who is working right now, how many sessions are waiting for you to decide, or that nothing has run yet — and the button that starts the next one.

Under it are four numbers: what is running, what is waiting for you, how many sessions you have accepted out of everything ever asked for, and the lines those accepted sessions actually put into the repository. Only accepted work counts toward the last two. A branch nobody merged changed nothing here, and counting it would measure how much the employees typed rather than how much of it was any good.

Then the sessions themselves, in three bands that hide when they are empty.

Who works here closes the page: the AI Employees you granted access, each with what it has actually done in this repository rather than only the fact that it may. A repository nobody has been granted says so, and links to the page that fixes it.

The repository's own settings — default branch, sign-in, what an employee may run, and the connection check for a remote — are still here, one disclosure down under Repository details. A README at the root is rendered above them.

Browse and edit files

The Files page shows the working tree of a checkout Genosyn keeps on the server. The tree is read from disk rather than from git, so a file you just created appears before you have committed it. Symlinks and the .git directory are never listed, one directory shows at most 2,000 entries, and .gitignore is respected — ignored entries are hidden, with a toggle that brings them back dimmed.

Open a file to edit it in place, with syntax highlighting. You can create, rename, move, and delete files and folders; a new empty folder gets a .gitkeep so it survives a reload, and a README at the root is rendered on the Overview page. Files above 1 MB are not rendered at all; files above 256 KB open read-only, as do binary files and any file opened at an older revision. Search finds text anywhere in the checkout, including files nobody has committed yet. The changed-files list comes from git status; discarding changes is scoped to the paths you pick — there is no discard-everything button on a checkout the whole company shares.

Commit, branch, and history

Commit everything that changed or only the paths you select, with a message. The commit is attributed to you: git log shows the Member's name and email as the author, not the server. Commits are also recorded in the company audit log.

Hand work to an AI Employee

A work session is a conversation with an AI Employee about one piece of work in a repository, and the reviewable result of it. Grant access first: open a repository's AI access page and add the employees that should be able to work on it. Any granted employee can be picked for a session, and it needs a connected AI Model to run.

The AI work page is a searchable session inbox, grouped by what needs attention so running or ready-to-review work does not disappear into finished work. Each session has its own URL, so you can send a colleague straight to the work you want them to review. Rename a session from its header when the instruction it was opened with stops describing it, and archive one you are finished with. On a narrow window the inbox becomes a compact switcher above the open session. For the short version — what is running, what is waiting for you, and what has been accepted — the Overview summarises the same sessions.

On Home, Repository AI work brings together sessions needing attention across the company's repositories: Ready to review, Pull request open, No changes made, and Failed. Open a session from the card to read its Activity, review Changes, or ask the employee for another pass. Choose Throw away on the row to remove its local branch and working copy without opening the session; Genosyn asks you to confirm first, keeps the session in Repository history, and leaves any remote branch or pull request open. Use Show more to reach the rest of a longer queue. Archived sessions stay out of the card, and it disappears when nothing needs attention.

Start with a useful brief

The quick-start surface keeps the employee picker and brief together. Suggested briefs give you a concrete starting point; choose one to adapt it, or write your own in plain language. An unfinished text brief is saved for this repository until the session starts. Paste a screenshot into the brief, drag files onto it, or choose Attach files or paste an image. Review the image previews and remove anything you do not want to send. Wait for uploads to finish, then start the session. The same controls are available when asking for another pass, and sent attachments stay alongside the brief in Activity. Unsent attachments must be selected again after a page refresh. See image formats and limits.

  1. Pick the AI employee by name, choose a suggested brief if it helps, and describe the outcome. If the employee has multiple assigned models, AI Model lists them all and selects its connected default, or another connected model if needed. Disconnected models are shown but cannot be selected. With one assigned model, there is no picker. Your choice applies to this session and its follow-ups without changing the employee's active model.
  2. Choose Effort to control how much work the selected AI Model puts into each response. This control appears for models that support it, including when the employee has only one model, and lists only that model's supported choices. Higher effort can take more time and tokens. Model default uses the AI Model's normal setting. The effort you choose stays with the session for every follow-up and appears in its header. Changing the employee or AI Model resets the choice to Model default. Custom endpoints and models without known effort support use their normal setting.
  3. Genosyn fetches from the remote and starts the session on the repository's default branch as it stands there — see Where a session starts below — in a git worktree of its own, on a fresh branch under genosyn/. Two sessions never collide.
  4. Genosyn reads the root contributor guide into the employee's briefing and records that it loaded it in Activity. It recognizes AGENTS.md, agent.md, and other capitalization variants, with CLAUDE.md as a fallback. See Contributor guides.
  5. The employee works through tools Genosyn runs on its behalf, and gets no filesystem access of its own. It can list the files and find them by name pattern, search their contents, read a file with line numbers, change one by exact replacement of text it copied from a read, create or delete a file, check its working copy's status and diff, keep a visible step list of its plan, and commit. Where your installation has the isolation for it, it can also run commands in its working copy — your tests, your linter, your build — so it verifies its own work before you read the diff. What it may run is yours to decide; see Commands.
  6. It commits its work and writes a short report of what it changed, what it left alone, and what it could not verify. Anything it left uncommitted when the turn ends — because it hit its turn limit, was stopped, or failed — is committed for it as a checkpoint named as such, so nothing it wrote is lost and everything is in the diff you review.
  7. Follow the work in Activity. If it is not right yet, ask for changes in the composer — the same employee picks up in the same working copy, on the same branch, and commits the revision on top.
  8. Open Changes for the file-by-file diff and the review actions. When it is right, accept the work, send it on, or open a pull request for it.

Activity shows each brief, and under it a live feed of how the employee is going about it: every tool call as one line — Read src/router.ts, Ran npm test → Exit 1 — with a spinner until its result lands, a red tint when it failed, and a chevron that opens the detail: the exact edit as removed and added text, the command and what it printed, the file that was read. The employee's narration appears between the calls as it thinks, and its step list is pinned at the top with n of m done. A finished turn folds the feed to one line — 14 tool calls · 3 files edited · 2 commands run — above the report, and you can open it again whenever you want to check how a change came to be.

While a turn runs, a Stop button sits in the session header. Stopping ends the turn where it is: whatever the employee had committed stays on the branch, anything it had edited and not yet committed becomes a checkpoint commit, and the session accepts another instruction — so a stop is a chance to redirect, not a discard. The stopped turn is marked as such in Activity, with whatever report it managed to write. A turn that reaches its limit of model turns before finishing is kept the same way, with a note saying so.

Changes is the review surface. It lists the changed files with their path, change type, and line counts; clicking one opens its diff, while Expand all opens every file, and a change small enough to read at a glance opens itself. The checkpoint list shows how the work built up, while the file list always reviews everything the session branch contains. Merge, push, and pull request actions live here rather than in the transcript. Throw away is available here too, as well as directly on the Home attention list, and only actions that apply to the current state are shown. If a request fails, the affected surface keeps the rest of the session visible and offers Retry.

The states of a session are:

Those are the session's states. Each turn inside it has one of its own — running, ok, failed, or stopped when a Member used the Stop button — and a stopped turn lands the session on ready or empty depending on whether it had committed anything, so the session stays open for another pass.

Publishing merges the session's branch into whatever branch the shared checkout is on. The worktree shares the repository's object store, so the commits are already present. For a remote repository you can push in the same step. Merging refuses to run while the shared checkout has uncommitted changes of its own, and a merge that would conflict is aborted rather than left half-applied. Only published and discarded end a session; everything else still accepts another instruction.

Clearing the inbox

Archive a finished session to file it away: the inbox gets shorter and nothing else changes. The branch, the commits, the transcript, and the session's status are all left exactly as they were, and its URL keeps working — which is what makes archiving different from throwing the work away.

Where a session starts

Work starts from the repository's default branch, brought up to date first. Genosyn fetches from the remote before every session and takes the trunk from origin/ rather than from the shared checkout, so an employee is never handed a copy of the code from weeks ago. Where it can be done without costing you anything, the local default branch is fast-forwarded to match. Three things are deliberately left alone: local commits you have not pushed, which are the trunk this installation actually has, so the session starts from them; a default branch that has diverged from the remote, because reconciling that is a decision, not a refresh — use Pull when you have decided; and your uncommitted edits, always — if the trunk cannot fast-forward without touching them, it is left behind instead, and the session still starts from the remote's tip.

A session already under way keeps the base it started with. Asking for changes continues on the same branch rather than moving the ground under a diff you are in the middle of reading.

Contributor guides

Keep your conventions, setup steps, and verification commands in AGENTS.md at the repository root. Genosyn automatically includes it in every work session's briefing, including follow-ups, and in ordinary chats and Routines after it prepares the employee's granted checkouts. Activity shows when a work session loads its root guide.

Names are matched without regard to capitalization: AGENTS.md takes precedence over AGENT.md, then CLAUDE.md. Lowercase names such as agents.md and agent.md work too. The first readable, nonempty guide in that order is used per directory. Guides in subdirectories apply only to that directory and its descendants. Work-session file reads and directory listings include the applicable guides, from the root down; deeper guidance takes precedence within its scope. In ordinary chats and Routines, employees are instructed to read nested guides before editing those directories.

Large guides include continuation instructions so the employee can read the remaining text before making changes. Guidance controls repository conventions and verification scope, including instructions to run only targeted tests. It cannot change the Member's request, company Policies, or the employee's access. A guide is read as instructions for the employee; its Markdown is never executed as a script.

Commands

An employee that can only write files has to hand you work it hopes is right. One that can run your tests hands you work it has checked. On the repository's Settings page, under Commands, you choose which it is:

A pattern is a command with an optional trailing * that matches the rest of it, so npm run * allows every npm script while npm test allows only itself. Every part of a chained command is checked separately — npm test && curl example.com is refused for the second half — and the constructs that would hide what actually runs, such as $(…) and redirection, are refused rather than guessed at. Lines beginning with # are comments.

Commands can run in a subdirectory of the session's working copy. The employee supplies that directory separately from the command, so npm run lint in App meets the same command policy as it does at the root. Every call starts in its own directory; changing directories in one call does not affect the next.