Git Integration
Dynamo includes built-in git tools — no shelling out for everyday operations. (They do use your installed git — and the git_lfs_* tools all need git lfs. The gh_* tools are a further exception: every one of them needs the GitHub CLI (gh) installed and authenticated. Without it they say so and point you at the install page, rather than failing obscurely.)
Available Tools
| Tool | Description |
|---|---|
git_status | Working tree status (staged, unstaged, untracked) |
git_diff | View changes (staged, unstaged, or between refs) |
git_log | Browse commit history |
git_add | Stage files |
git_unstage | Unstage files |
git_commit | Create commits with messages |
git_push | Push commits (auto-detects upstream) |
GitHub, through the gh CLI — pull requests, CI runs, and issues:
| Tool | Description |
|---|---|
gh_pr_create | Create a pull request for the current branch |
gh_pr_list | List pull requests, filtered by state, head or base branch, author, label, or a search |
gh_pr_view | View one PR: author, state, review decision, review verdicts, CI check rollup |
gh_pr_diff | Fetch a PR's unified diff, or just its changed-file list |
gh_pr_comment | Post a comment on a PR |
gh_pr_review | Submit a review — approve, request changes, or comment |
gh_run_list | List GitHub Actions runs, filtered by branch, workflow, status or event |
gh_run_view | View one run: status, conclusion, per-job results, and the failed steps' logs |
gh_issue_create | Open a new issue |
gh_issue_list | List issues, filtered by state, label, author or assignee |
gh_issue_view | View one issue: state, labels, assignees, body, and its comments |
gh_issue_comment | Post a comment on an issue |
The CI check rollup in gh_pr_view needs your GitHub token's "Checks: Read" permission. Without it, that one line says the rollup was denied and the rest of the PR still comes back. When a PR has no checks yet, it says none are reported instead of staying silent. gh_run_list and gh_run_view read Actions, a separate permission, and answer CI status either way.
Git LFS, for repos that use it:
| Tool | Description |
|---|---|
git_lfs_status | LFS tracking status |
git_lfs_ls_files | List LFS-tracked files |
git_lfs_track | Store a file pattern with LFS |
git_lfs_pull | Fetch LFS objects |
git_lfs_push | Push LFS objects |
git_lfs_locks | List file locks |
git_lfs_lock | Lock a file |
git_lfs_unlock | Unlock a file |
How It Works
Dynamo understands your git context automatically:
- Knows which branch you're on
- Sees staged and unstaged changes
- Reads commit history for context
- Can create well-formatted commits and PRs
- Can read a PR's diff and its review feedback, and reply to it
- Can see why a CI run went red — down to the failing step and its log
Permission levels: reads (git_status, git_diff, git_log, every gh_* list/view/diff tool, the LFS query tools) are safe and run automatically; writes (git_add, git_commit, ordinary pushes, the LFS transfer and lock tools, and the GitHub tools that post something — gh_pr_create, gh_pr_comment, gh_pr_review, gh_issue_create, gh_issue_comment) are write and prompt once per model. When a GitHub write asks, the prompt names what is about to be posted: the title of a new pull request or issue, or the opening of a comment or review. When the text is longer than the prompt shows, → reveals the rest. For gh_pr_review, the approve-or-request-changes verdict comes first, because that is the decision you are approving. Some pushes escalate to dangerous and ask every time: git_push to a protected branch (the default branch, a permissions.protected_branches pattern, or a branch GitHub protects), with a force flag, deleting a branch, or to a remote this repo doesn't have — and git_lfs_unlock --force. "Allow every" is never offered on a dangerous call, and an earlier grant on the same tool never covers one. Auto Mode approves them. A force-push to a protected branch is different: it is blocked outright, even in Auto Mode, unless you set permissions.allow_force_push_protected: true in dynamo.yaml, which makes it ask every time.