| name | git-delegation-management |
| description | Execute git operations on behalf of Workers who don't have git credentials. Use when a Worker sends a git-request: message to clone, push, pull, commit, rebase, or perform any git operation. |
Git Delegation Management
This skill enables the Manager to execute any git operation on behalf of Workers. Workers cannot access git credentials, so they delegate all git operations to the Manager.
Prerequisites
The Manager has access to:
- Host's
.gitconfig via /host-share/.gitconfig (symlinked to /root/.gitconfig)
- Git credentials (SSH keys, credential helpers) configured on the host
This allows git operations to use the correct author name, email, and authentication.
Handling git-request: Messages
When a Worker sends a message containing a properly formatted git-request: block (with workspace: and operations: fields), execute the requested operations.
task-{task-id} git-request:
workspace: /root/hiclaw-fs/shared/tasks/{task-id}/workspace/{repo-name}
operations:
- git clone https://github.com/org/repo.git
- git checkout -b feature-auth
- git add .
- git commit -m "feat: add authentication"
- git push origin feature-auth
---CONTEXT---
{description of what they're trying to accomplish}
---END---
Extract:
task-id: Task identifierworkspace: Path to work in (for clone: parent directory; for other ops: repo directory)operations: List of git commands to execute (literally what to run)context: (Optional) What the Worker is trying to accomplish
Execution Flow
1. Sync and Check Processing Marker
task_id="task-YYYYMMDD-HHMMSS"
workspace="/root/hiclaw-fs/shared/tasks/${task_id}/workspace/{repo-name}"
mc mirror "${AGENTTEAMS_STORAGE_PREFIX}/shared/tasks/${task_id}/" \
"/root/hiclaw-fs/shared/tasks/${task_id}/"
bash /opt/hiclaw/agent/skills/task-coordination/scripts/check-processing-marker.sh "$task_id"
if [ $? -ne 0 ]; then
exit 1
fi
bash /opt/hiclaw/agent/skills/task-coordination/scripts/create-processing-marker.sh "$task_id" "manager" 15
2. Execute Git Commands
Navigate to the workspace and execute the git commands:
cd "$workspace"
git clone https://github.com/org/repo.git
git checkout -b feature-auth
You know how to use git. Execute the commands the Worker requests. If something goes wrong (merge conflict, authentication failure, etc.), handle it appropriately.
3. Cleanup and Respond
bash /opt/hiclaw/agent/skills/task-coordination/scripts/remove-processing-marker.sh "$task_id"
mc mirror "/root/hiclaw-fs/shared/tasks/${task_id}/" \
"${AGENTTEAMS_STORAGE_PREFIX}/shared/tasks/${task_id}/" --overwrite
On success — send to Worker:
@{worker}:DOMAIN task-{task-id} git-result:
Git operations completed successfully.
{Summary of what was done - commits, pushes, branches created, etc.}
Run `hiclaw-sync` to sync.
On failure — send to Worker:
@{worker}:DOMAIN task-{task-id} git-failed:
Git operation failed: {error message}
{Suggestion for how to fix it, if applicable}
What Operations Can Be Delegated
Any git operation, including but not limited to:
| Category | Commands |
|---|
| Repository | git clone, git init |
| Branches | git branch, git checkout, git switch |
| Remote | git remote, git fetch, git pull, git push |
| Commits | git add, git commit, git reset, git revert |
| History | git log, git show, git diff |
| Rebase | git rebase, git rebase -i |
| Cherry-pick | git cherry-pick |
| Merge | git merge |
| Stash | git stash |
| Tags | git tag |
| Submodules | git submodule |
| Config | git config (local to repo) |
If git can do it, the Worker can delegate it.
Error Handling
When git operations fail:
- Read the error message and understand what went wrong
- Try to fix it if it's a simple issue (e.g., set upstream, configure user locally)
- Report to Worker if it requires their action (e.g., merge conflicts, rebasing decisions)
- Escalate to admin if it's a credential or permission issue
Common issues:
- Merge conflicts → Ask Worker to resolve locally
- Authentication failure → Check
/host-share/.gitconfig and credential helper
- Branch divergence → Worker may need to pull/rebase first
Integration with Task Coordination
Always use the .processing marker to prevent conflicts when both Worker and Manager might modify the workspace.
Gotchas
- Wait for the actual
git-request: block — if a Worker says "Let me prepare the git-request" or "I'll delegate git operations", that is a preview, not a request. Do NOT execute any git operations until you receive a message with the structured workspace: + operations: fields.
- Execute git-request immediately when received — when a message contains
git-request: with workspace: and operations: fields, you MUST execute the git commands yourself and reply with git-result:. Workers cannot run git operations — that's why they delegated to you. Never "wait for the Worker to complete" after receiving a git-request; the Worker is waiting for YOUR git-result.
- Duplicate git-request after you already executed — if you already completed the git operations for a task and the Worker sends a
git-request: for the same operations, reply with git-result: confirming the operations were already completed. Do not re-execute or re-verify the repo state.
- Ignore superseded requests — if a Worker sends multiple
git-request: messages for the same task before you respond, only execute the LAST one (it is the most complete). Earlier requests were likely incomplete or had wrong paths.
- Never delete or overwrite the remote repo — the remote URL (bare repo or GitHub) is shared across phases and Workers. Never
rm -rf a remote path, never git init --bare over an existing repo.
- git-result is not task completion — after sending
git-result:, the Worker still needs to verify the outcome and report completion (e.g., PHASE_DONE). Do NOT treat a successful git-result as the Worker's task completion signal. Wait for the Worker's explicit completion report before advancing to the next phase.
