Git Delegation Management

Execute any git command on behalf of Workers without credentials by processing their git-request messages and managing workspace synchronization safely.

Security Scan

The skill's purpose (running delegated git ops) is plausible, but the runtime instructions expect access to host credentials, MinIO, and system scripts while declaring none of those requirements and instruct the Manager to run arbitrary worker-supplied git commands without validation — this is risky and inconsistent.

Purpose & Capability

The skill's stated purpose (execute git operations on behalf of Workers) is coherent in principle, but SKILL.md assumes access to host git credentials (e.g. /host-share/.gitconfig and SSH keys), MinIO client (mc), and task-coordination scripts under /opt/hiclaw — none of these are declared in the registry metadata (no required binaries, no config paths, no env vars). The skill should explicitly declare those dependencies and required host access if they are necessary.

Instruction Scope

Instructions tell the Manager to execute the git commands 'literally what to run' provided by Workers, with no whitelist, sandboxing, or validation. The flow also instructs mirroring from and to MinIO and calling host scripts (/opt/hiclaw/...) and relies on git behaving safely. Running arbitrary git operations on repositories controlled by Workers (or remote URLs they request) can lead to code execution (through hooks, submodules, smudge/clean filters, git-config includes), credential leakage, and exfiltration. The instructions give broad discretion and do not limit or validate potentially dangerous operations.

Install Mechanism

This is an instruction-only skill with no install spec (low install-time risk). However, the runtime assumes the presence of 'git' and 'mc' and of specific coordination scripts on the host; those are runtime dependencies that should have been declared. Absence of a formal install spec means those dependencies will be satisified implicitly by the host, which increases operational uncertainty.

Credentials

The SKILL.md expects access to host git credentials and MinIO configuration, but the registry metadata lists no required environment variables, no primary credential, and no required config paths. This mismatch is disproportionate: a skill that performs host-authenticated git and MinIO sync should explicitly request and justify the corresponding credentials and config paths. The implicit need for host-level secrets (SSH keys, credential helpers, MinIO credentials) is a red flag.

Persistence & Privilege

always is false (good), but model invocation is allowed (normal). Combined with the skill's ability to run arbitrary git commands using host credentials and to call system scripts, autonomous invocation increases blast radius: an agent could be asked (or tricked) into performing harmful operations without further user review. The skill does not define safeguards (approval steps, command restrictions, or whitelists).

What to consider before installing

Before installing or enabling this skill, verify and harden the execution environment: 1) Confirm the exact host files and credentials the skill needs (SSH keys, /host-share/.gitconfig, MinIO client config) and only grant the minimum required access. 2) Require the skill to declare required binaries (git, mc) and config paths and to enumerate any scripts it will call under /opt/hiclaw. 3) Do NOT allow the Manager to run arbitrary worker-supplied git commands unvalidated — insist on a safe policy (whitelist allowed commands, disallow network-pushed operations, restrict remotes, or require human approval for pushes and branch creation). 4) Run delegated operations in an isolated ephemeral environment (container or jailed workspace) that cannot access host secrets or unrelated files, and ensure git hooks and filters are disabled or sanitized. 5) Ensure MinIO credentials and mc usage are explicit and stored separately; audit and log all git operations and syncs. 6) If you cannot enforce these controls, treat the skill as too risky to enable. If you want the capability, request a revised skill that declares its dependencies, enforces command validation/whitelisting, and documents its security model.

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 git-request::

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 identifier
• workspace: 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}"

# Sync from MinIO
mc mirror "hiclaw/hiclaw-storage/shared/tasks/${task_id}/" \
  "/root/hiclaw-fs/shared/tasks/${task_id}/"

# Check for processing marker
bash /opt/hiclaw/agent/skills/task-coordination/scripts/check-processing-marker.sh "$task_id"
if [ $? -ne 0 ]; then
    # Respond with git-failed: explaining the conflict
    exit 1
fi

# Create processing marker
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"

# Execute each git command
git clone https://github.com/org/repo.git
git checkout -b feature-auth
# ... etc

# Log output for debugging

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

# Remove processing marker
bash /opt/hiclaw/agent/skills/task-coordination/scripts/remove-processing-marker.sh "$task_id"

# Sync to MinIO
mc mirror "/root/hiclaw-fs/shared/tasks/${task_id}/" \
  "hiclaw/hiclaw-storage/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 `bash /opt/hiclaw/agent/skills/file-sync/scripts/hiclaw-sync.sh` 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:

1. Read the error message and understand what went wrong
2. Try to fix it if it's a simple issue (e.g., set upstream, configure user locally)
3. Report to Worker if it requires their action (e.g., merge conflicts, rebasing decisions)
4. 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.

<!-- hiclaw-builtin-end -->