Glossary
Short, citeable definitions for the proprietary terms DevMesh uses across the site, the docs, and the product.
Vibecoding
- A prompt-driven way of building software. You describe what you want in plain English, and AI coding agents write, test and land the code while you steer. DevMesh is built for it: many agents side by side, each in its own worktree, all tracked in one window.
Worktree
- A separate git checkout of the same repository on its own branch. DevMesh gives every agent its own worktree, so agents running in parallel never edit the same files.
Agent
- A CLI coding agent such as Claude Code, Codex, OpenCode or Pi running inside DevMesh. Each agent has a mascot head in the sidebar showing whether it is running, idle or done.
Design Mode
- Element picking in DevMesh's built-in Chromium browser. Clicking an element sends its HTML, CSS and a cropped screenshot to your agent's prompt.
SSH worktree
- A worktree on a remote machine, reached over SSH. Files, git, terminals and agents run on the remote host, with auto-reconnect and port forwarding.
Diff annotation
- A comment left on a line of an agent's diff in DevMesh's review view. Annotations go back to the agent as follow-up instructions.
backlog.md
- The file-based source of truth for a DevMesh project's kanban. Plain markdown plus HTML-comment metadata (id, status, source). The hosted board reads from this file, so the repo always carries the canonical task list.
dm (CLI)
- The DevMesh command-line tool. Drives the kanban from the terminal: add tasks, push backlog.md, move cards, list open tickets in JSON for CI gates. Installable via npm install -g @devmesh/cli.
Group
- A shared label (passed via --group <label> on dm task add) that ties sibling tasks together visually on the board. Tasks sharing a group render with a deterministic colored left-border, making batches of work born from the same audit, prompt, or session obvious at a glance.
Repo binding
- Auto-attachment of a DevMesh task to a specific repository, driven by a .devmesh.json file at the repo root. Tasks created from inside a bound repo inherit the repoId automatically, so per-repo views on the kanban stay coherent.
Related: Parallel Worktrees
Related: Parallel Worktrees
Related: Design Mode
Related: SSH Worktrees
Related: Annotate AI Diffs