TOOLS.md — Coder
Infrastructure references, account details, and tool-specific patterns for this workspace.
Workspace
- Root:
~/.openclaw/workspaces/coder/ - Temp files:
/tmp/coder-*— always clean up when done
GitHub CLI (gh)
- Account:
- Auth: pre-configured via
gh auth loginbefore first use - Scope:
/*
PR Creation (Mandatory Pattern)
Never pass multiline markdown with --body "..." — shell escaping breaks it. Always use --body-file:
cat <<'EOF' > /tmp/pr_body.md
## Summary
- What changed and why
## Testing
- How it was verified
EOF
gh pr create --title "fix: ..." --body-file /tmp/pr_body.mdGit
- Branch naming:
fix/issue-<num>-<short-desc>orfeat/<short-desc> - Commits: conventional commits —
feat:,fix:,chore:,docs:,test:, etc. - Never commit directly to
main
⚠️ No Per-Task Clones
Never run git clone or gh repo clone to create a new directory for each task. Each repo gets one canonical clone; all tasks use worktrees off it.
The initial clone (when the canonical doesn't exist yet) is fine and expected — see the worktree pattern below.
Worktree Pattern (Mandatory)
Each repo has a single canonical clone in the workspace root. All tasks use worktrees off that clone — they share the git object store, support full parallelism, and avoid checkout conflicts.
REPO_NAME="my-repo"
CANONICAL="$HOME/.openclaw/workspaces/coder/$REPO_NAME"
TASK_ID="issue-42"
BRANCH="fix/$TASK_ID-short-desc"
WORKTREE="/tmp/${REPO_NAME}-wt-${TASK_ID}"
# One-time: clone the canonical if it doesn't exist yet
# Use --filter=blob:none for large repos (lazily fetches blobs, keeps full commit history)
if [ ! -d "$CANONICAL" ]; then
gh repo clone {{GH_ORG}}/$REPO_NAME "$CANONICAL"
fi
# Per-task: fetch latest, create isolated worktree on a new branch
git -C "$CANONICAL" fetch origin
git worktree add "$WORKTREE" -b "$BRANCH" origin/main
# Do all work in $WORKTREE
cd "$WORKTREE"
# ... implement, test, commit ...
# Push and open PR
git push -u origin "$BRANCH"
gh pr create --title "..." --body-file /tmp/pr_body.md
# Cleanup after PR is open
git worktree remove "$WORKTREE"cgc (CodeGraphContext)
cgc is a code graph analysis tool that indexes a codebase into a queryable graph. Use it during Phase 1 planning to understand blast radius before changing shared code. Assume it is already installed globally.
# Index the repo (run once from repo root, or after major changes)
cgc index .
# Find everything that depends on a module
cgc analyze deps "my-module" # or "@myorg/shared-package" for scoped packages
# Find all callers of a function
cgc analyze callers myFunction
# Find complex functions worth reviewing before changing
cgc analyze complexity --threshold 15 --limit 10When to use:
- During Phase 1 planning — understand what depends on the code you're about to change
- Before modifying shared packages in a monorepo — check blast radius
- When reviewing PRs that touch shared code
session_status
Used to switch models between workflow phases:
session_status(model="codex") # Phase 2 — implementation
session_status(model="opus") # Phase 1/3 — planning/review