Code, git and pull requests

Scan a repo or project folder for hardcoded keys, tokens and passwords with Mori's own pinned gitleaks, read only (nothing in the folder is changed or run, secrets are redacted). Every code or security review runs it first, on the folder it reviews, and merges every finding into the review.

Orient in an unfamiliar project in ONE call: its own instructions file (AGENTS.md / CLAUDE.md / CONTRIBUTING.md), how it builds and tests (package.json scripts and package manager, Makefile, pyproject, Cargo, go.mod), and its top-level layout with file counts, plus the REPO card repo_understand saved for it. Call this FIRST when asked to work in a repo you have not seen this session.

Git status: branch, plus changed, staged and untracked files. Use before committing.

Git diff of unstaged (or staged) changes. Review edits before committing.

Stage everything and commit. Use after finishing a unit of work.

Recent commits, one line each.

List branches, local and remote.

Switch branch, or create one with create="true".

Start a git repository in a folder.

Publish the work as a pull request: makes a fresh mori/<slug> branch off the base (never commits on main), commits everything, pushes, and opens the PR with gh. Called again from the same thread it reuses the branch and updates the same PR. CI is then watched and this thread woken if it fails. It cannot merge.

Open the NEXT pull request in a stack: a fresh mori/<slug> branch based on the previous PR's branch, not on main, committed, pushed and opened with that branch as its base.

The pull requests Mori opened on this repo: number, state, branch, CI state, unread comments, owning thread, URL.

CI checks on a PR (gh pr checks): each job with pass/FAIL/running and its link. Defaults to this thread's open PR.

Read the FAILING job log of a PR (gh run view --log-failed) so you can fix the cause. Returns the failing jobs and the log tail. Fix, verify locally, then pr_open again with the same title to push.

Unresolved review threads and human comments on a PR. Bot comments are ignored unless allow_bots names them; a bot named once is remembered on that PR, so the watch wakes this thread for it too.

The preview deployment URL for a PR: a Vercel/Netlify link posted in a PR comment first, then the deploy check's details URL, then a dashboard. Says so when there is none.

Make an isolated git-worktree WORKSPACE for a big or risky code job, its own branch + directory, so changes never clobber the main checkout (and parallel subagents don't collide). Afterward, shell/git/relative-file tools default to it. Use before a large refactor or an experiment.

List the isolated git-worktree workspaces and which one is active.

Switch into a workspace (by id, name, or branch), shell/git/relative-file tools then default to its directory.

Leave the current workspace, tools go back to their normal working directories.

Merge a workspace's branch back into its base (commits pending work first, then a no-ff merge). Set delete_after='true' to remove the worktree once merged.

Remove one of THIS thread's workspaces (worktree directory; the branch is kept). It refuses another thread's, and refuses one with uncommitted changes: merge it, or ask the person. force='true' only when the person said to throw that work away; the folder then goes to the Trash.

Create a new named project folder

START HERE for a web APP (state, routing, a dashboard, anything with a build step): a Vite + React + Tailwind v4 project built for its subject; it picks the direction (layout, type, ground, motion) and returns it; then write that layout in src/App.tsx. A static page (landing page, menu, one-pager with no app logic) is hand-built instead.

Create a simple HTML project with index.html, style.css, and script.js

Create a simple Node.js project with package.json and src/index.js

Show the user what you built in the Mori Preview window. Pass a project folder or an .html file to render it live, or a localhost URL to show a running dev server. ALWAYS call this right after building a web project.

LOOK at a page you built in the Mori Preview window (never the desktop): url = a dev server, path = a static .html or its folder, neither = the preview already open. section = one viewport-high close-up (1 = top); sections = several close-ups in ONE look ("1-4", "2,5" or "all", up to 4). It reports the page's console errors and warnings too. Use it, not take_screenshot, to check a build.

READ a page you built as a person with a screen reader meets it: the Mori Preview's controls, lists, headings, live regions and text, with states (focused, checked, value) and a ref (e52) for each element preview_act can use. url = a dev server, path = a static .html or its folder; neither = the preview already open. within = one part (a ref, or role "name"). Text only; preview_screenshot is the look.

TRY what you built in the Mori Preview (never the desktop; no permission needed): one call runs every journey of a check pass, one step per line, each journey opening with a journey "name" line that opens the call's page fresh, with storage and cookies cleared (a failed step ends only its own journey; a plain reload stays inside it), and returns each step's result, what changed, the page's console since, and a verdict. A failed expect is a bug to fix, then run the same steps again. Steps: click T | type T "x" | fill T "x" | press Enter | press Space on T | press ArrowRight x2 | drag T to T via pointer | drag T to T via keyboard | scroll down | resize 390x844 | reload | journey "name" | screenshot | screenshot section 2 | wait for "x" | expect "x" | expect no "x" | expect "x" in T | expect focused T | expect T checked | expect T value "x" | expect T has 3 items | expect announce "x" | expect console clean | expect storage "key" contains "x". T = a ref (e52), "text", role "name" (button "Add", list "Done"), or #css. Acts only on a file or a dev server you started.

Start a project's dev server (vite/next/expo) and leave it RUNNING in the background. Returns the pid and the local URL once it prints one. Check it with open_preview or http_request against that URL, and READ its output after changes with dev_server_logs. Stop it with stop_dev_server.

Stop a running dev server by pid, or by a fragment of its command/folder. Omit to stop all.

List the dev servers you currently have running (pid, command, uptime).

Read the recent output of a dev server you started, or one that CRASHED (its last output stays readable). start_dev_server returns after ~3.5s, so compile errors, module-not-found on first load, port conflicts and crashes all happen AFTER it reports success. Call this after making changes or whenever the preview looks wrong, and fix what the log actually says.

Prove a test suite can actually FAIL. Breaks the subject file one change at a time and re-runs the tests: a change no test notices is behaviour nothing is checking. Use after writing tests, before saying they pass, and when a suite has been green for a long time. This is the only check that distinguishes 'the code works' from 'the tests agree with the code'.

Read the newest crash or error logs and summarize them: kind "native" (a C/C++ program, by its file name), "java" (hs_err logs in a folder), "minecraft" (a server or dev client folder: crash-reports, latest.log), "roblox" (Roblox Studio's logs), "godot" or "unreal" (a project folder). A command that crashes already reports its fresh crash report; use this for a game the person ran themselves or an older crash.

Open Visual Studio Code

Open a new VS Code window

Open a folder/project in VS Code (opens the folder AND reveals its main file)

Create a new project with HTML/CSS/JS files and open it in VS Code. A complete workflow shortcut, creates files, opens VS Code, opens the main file.

Create a file with content and open it in VS Code immediately.

Change several files in ONE call, all or nothing: a V4A patch (*** Begin Patch, then *** Update File: path with @@ hunks of lines starting with a space for context, - to remove and + to add, *** Add File: path with every line starting with +, *** Delete File: path, *** Move to: newpath under an update, then *** End Patch) or a unified diff (--- a/path, +++ b/path, @@ -12,3 +12,4 @@). Every file is checked first (it must have been read, every hunk must land in exactly one place), then each change is written through edit_file, create_file or delete_file. If any file fails, nothing is changed, and a write that is refused puts back the files already written. Use it for a refactor across files; use edit_file for one change in one file.

Go to definition: where a name used in a file is defined, from the language server (TypeScript/JavaScript, Python, Go, Rust), else the symbol index. Give the file and either line and column, or the symbol name (with its line when it appears more than once).

Hover: the type, signature and doc comment of a symbol at a position, from the language server.

Find references: every place a symbol is used across the project, the definition marked, from the language server (else a whole-word search). Same position arguments as code_definition.

Rename a symbol everywhere it is the same symbol (not every word that looks like it), across files. The first call is a DRY RUN listing every edit; call again with apply "true" to write them all as one batch, each file checkpointed (undo_changes takes it back).

Symbols: a file's outline (classes, functions, methods, types with their lines), or with a query, the project's symbols whose name matches it (workspace symbols).

Mori checkpoints a whole folder before the first change of each turn, shell changes included. With no n: the folder's checkpoints, newest first. With n: what changed in the folder since checkpoint n, as a diff. Reads only; the person rolls back with /rollback.

Is a PR really done? Reads the REQUIRED checks of its base branch (branch protection and rulesets, not every check) and says which required check is pending, failed, skipped or neutral. A PR is done only when every required check passed. Call it before saying a PR, or the work it carries, is done.

UNDERSTAND A REPO all the way through, from a git link (cloned shallow into Mori's own folder, never read off GitHub's web page) or a folder on this computer. Builds its map (languages, entry points, build and run commands from its manifests, monorepo packages, the module graph from its imports and its hubs, a symbol index, its tests), reads the important files in order within a budget, and returns and saves a REPO card: what it is, how it runs (the run recipe, in order), its architecture and where things are. Use it whenever the person gives a repo or asks to understand, explain, run or build on one.

Settle a merge that conflicts, hunk by hunk, as a neutral arbiter, instead of giving up on it. First call with the workspace (or repo, ours and theirs): the merge is made in a temporary worktree, never your checkout, and you get every conflicting hunk with ours, base and theirs, both branches' intents and diffs, and a plan id. Then call again with the plan id and decisions for EVERY hunk (ours, theirs, both, base, or custom text, each with a reason). It writes them, checks no conflict marker is left, runs git diff --check and the project's own check, and only then moves the base branch to the merge. Every decision is reported.

Run a short JavaScript program that calls Mori's file, search and git tools itself, so a long chain of calls (read 40 files, grep them, count, compare, then edit a few) is ONE step instead of 40. Inside the script: `await tools.read_file({ path })`, `await tools.search_files({ path, pattern })`, `await tools.edit_file({ path, old_string, new_string })` and the rest of the allowed list, each returning the tool's text; `print(...)` (or console.log) is the ONLY thing you get back, so print what you need. Top-level await works. The script keeps its state for this conversation: anything you put on `keep` (or globalThis) is still there in your next run_tool_script call. Allowed: reads (read_file, read_any, list_files, get_file_info, read_pdf, query_csv, git_status, git_diff, git_log, list_changes), searches (search_files, find_files, repo_map, search_history, search_sessions) and writes (edit_file, create_file, write_file, append_to_file, apply_patch, create_folder). A write asks exactly as it would if you called it yourself. Shell commands, the network, messages, money and the computer are not reachable from a script. Limits: 30 seconds by default (timeout_seconds up to 120), 120 tool calls per turn; a script that runs past its time is stopped and its saved state is cleared, and the result says so.

Show a folder's own git changes in one read, untracked files included (git_diff leaves those out): scope "working" (not staged yet), "staged", or "all" (everything against the last commit, the default). A long diff keeps its head and tail and saves the rest to a file you can read.

Whether a repo or folder is trusted. A clone is not trusted until the person says so: Mori type-checks it with its own servers (no build scripts, proc macros or the repo's own binaries) and installs skip install scripts. trust "yes" works only when the person's own message said to trust it.

Prove a project really runs: detect how it is installed, built, tested and started (from its own files; the person's .mori/environment.json wins), run each step, start it, wait until its address ANSWERS (not just prints), then stop it. Use it before saying an app works. The last line is VERIFY PASSED or VERIFY FAILED at <step>, with that step's output.