Repos and GitHub

Giving Mori a repo

Any of these works, in any wording:

• a link: https://github.com/owner/repo, a file or folder page inside it, the same on GitLab, Codeberg or Bitbucket, git@host:owner/repo.git, or the owner/repo shorthand, which means GitHub;
• a folder of code on your computer, pasted as a path;
• "this repo" in a thread bound to a project folder.

The Projects page also has From a repo: paste a link, pick where it goes, and Mori clones it and makes it a project.

A link that is about a repo rather than the repo itself (an issue, a pull request, a release, a commit, the wiki) is read as that page, not cloned.

What she does with it

What you want from a repo is yours to say, and Mori reads it from your words: study it and explain it, run it here, copy it closely, make one like it, or use part of it in something bigger. When it is genuinely unclear she asks one short question.

Whatever you want, the repo itself is what gets read, never GitHub's web page about it. When your message gives a repo, Mori reads it before her first model request, so the answer starts from the real code.

How she reads a repo

A link is cloned shallow into Mori's own work folder: one commit, no tags, no files over 5 MB, and no large file storage. A Stop ends the clone straight away. A folder on your computer is read where it is. Then, in one pass:

• the map: its languages, its entry points, every package of a monorepo, the module graph from its imports (the most imported files are the hubs, and the links between top folders are the architecture), a symbol index, its tests and their runner;
• its own instructions: AGENTS.md, CLAUDE.md and CONTRIBUTING files at any depth;
• the recipe: how to install, build, run and test it, from its own manifests, in order, with the folder each step runs in.

The result is a REPO card in the thread that the rest of the work builds on.

Links are checked before anything runs

A pasted link ends up as an argument to git clone, so it is read first and refused when it is not a plain remote:

• local paths, file links, and git transports that run commands;
• anything starting with a dash, which git would read as an option;
• spaces, quotes and shell characters, which no real git link contains;
• plain http, because the code would arrive unencrypted (the https link is the same repo).

Git itself always runs without a shell, so a link can never become a command.

Building on a repo

In a repository she has not seen this session, Mori starts from its map and its own instructions, and reads only what the job needs. The build and test commands come from the repo's files, so a Python, Rust, Go, C++ or Lua project is never tested with npm.

A big or risky change gets its own workspace: a git worktree with its own branch and folder, so nothing lands on your checkout by accident and parallel helpers never collide. See Workspaces and Coding and builds.

When she uses part of a repo in your project, she uses its code only as its licence allows, and says what she took.

Commits

• As you, never as a placeholder. Before any commit, Mori asks git who the commit would be written as. If that is a placeholder address such as your-email@example.com, the commit does not run and she tells you how to set your name and email, because a commit under a fake address is published under a name that belongs to nobody.
• Your work, not its dependencies. "Commit everything" stages your work and leaves out dependency and cache folders that git neither tracks nor ignores (a fresh node_modules, for example), then says what was left out and how to make that permanent.

Pull requests and CI

Mori opens a pull request from a fresh mori/ branch off the base, signed in as you through GitHub's own command line tool. She never commits on main. Asked again from the same thread, she updates the same pull request, and she can stack the next one on top.

After that, CI is watched and the thread wakes when a check fails: she reads the failing job's log and works on the fix in the same thread. She reads unresolved review comments (ignoring bots unless you name one) and finds the preview deploy link. The Pull requests page lists every pull request she opened.

Why no tool merges

Merging is a button on the Pull requests page, with a confirmation, so the last step is always yours. The guard sits on the capability, not on one tool: a merge, a force push or a push to a protected branch typed into the terminal is caught the same way as one asked for by name, so there is no back door through the shell.

Skills that come with a repo

A repo can carry its own skills in .agents or .claude folders. When a thread is bound to that repo, Mori sees their names and descriptions and reads one in full only when the job calls for it. See Skills.

Cloud and GitHub

When a thread moves to a cloud machine, the repo it works in travels with it, and your own ignore rules decide what comes back. Pushes and pull requests go through GitHub's own command line tool on your computer, signed in as you.